Read and Write to Local IO Tags Within a FOR Loop

So, I'm almost certain there is no great answer to this question, but I thought I would poll the masses for expert opinion...

I'm running a valve monitor using a FOR loop. I have an AutoValve UDT, and in it are BOOL's like IsOpen, IsClosed, Energize, Deenergize, and Request. A have an instance of this UDT for every valve (XV_1000, XV_1001, etc.), and each instance is aliased to a member of a comprehensive Valve array. The FOR loop steps an Index DINT and calls the Valve_Monitor routine. Inside the routine, a ValveBuffer is set equal to Valve[Index]. Logic is executed and either Energize or Deenergize is enabled. The Energize and Deenergize should then trigger a signal to be sent to the actual field device.

I'm using FlexIO in my control panel. I've built the I/O configuration and Local IO tags were generated which link to the actual input and output signals coming off the cards. As far as I know, these Local IO tags, the individual Valve array member tags, and the tags within my AutoValve UDT's all can not be assigned aliases.

What I want to know is this: is there any way to read and write to the Local IO tags within my Valve_Monitor? A way to indirectly reference the Local IO tags so that each valve passed into the buffer could write to its own specific Local IO tag?

Do you see my problem? Every new valve passed into the buffer has its own IO address that has to be written to or read from. And not just for valves, for motors and analog devices also. If I use a loop, there is no way to dynamically reference the Local IO tags because I can't alias them from an array and I can't alias them to an array either. Without hard-coding a massive list of conditional statements and using an address tag in the UDT to match the incoming valve to a specific Local IO tag, I don't know what else could work.

I've had a lot of trouble trying to cross the boundary from PLC code to field device. If there is a way to indirectly reference a tag (as in use a String tag to store the Local IO tagname, place that String tag into some instruction, and have the instruction reference the value of the String tag) or if you can think of any other solution to my problem, please help me out! I would really appreciate it and could save people a lot of time.

Thanks in advance!

Bill

what plc brand are we talking about?? it seems like rslogix 5000 isn´t it ??

Sorry, yes RSLogix 5000

I use a similar method for controlling all kinds of devices. I would add an element to your UDT called Output, Feedback0, and Feedback1. Then I would have a mapping routine where I populated and read this data into my UDT. This gives you and the end user a clean location to map new I/O. I can think of a few tricky little gimmicks to map your I/O all which are more of a gimmick than a feature in my opinion.

I would consider putting this in a function or an AOI if your platform supports it. I have caught a certain amount of flack in the past for using FOR loops or Jump/Label loops to solve large arrays. Many end users do not like having to look at the data table to troubleshoot the logic. It really all depends on who the end user is and what their comfort level and personal preference level is. I would prefer the logic out in the open in a loop just like you have coded myself. I find that I am in the minority on this though.

RSL

I did that exactly the other day with no problem, in my case i was reading a barcode from a box and with the barcode I get the index from inside my routine, with the index a get other operations. In your case you set the index from outside your routine and the run it until you get what you want. is that the case ???

@RSL
It's funny you say you are the minority because I am in the same boat! I agree with everything, the end user's are usually less experienced and want a straight forward view of the execution, but the Loops are so much cleaner! The AOI was my second choice only because it still requires me to write out 160 instances of the instruction. I was trying to see if anyone had found a way around it haha.

I did think of one possible solution to read and write using the FOR loop, but it involves a complex matching system. I would call a Read_Write routine from the loop and pass an Address UDT to it. The Address would hold the device type and numeric codes for the Output and Input1,Input2 addresses. Like 230 for Rack 2 Slot 3 Point 0. Then have a large bank of EQU blocks that read or right to the specific Local IO tags.

I guess at that point I might as well just make an AOI, but I've also been using Excel macros to automate my rung command construction. So maybe I'll save some time


@widelto
Yes, that's it! That's what I'm doing, and it works great. There just seems to be the necessary added step of transforming your loop logic into actual output commands.

I´m with RSL, consider AOI as an option.

Many years ago I wrote a highly efficient valve control routine in an AB PLC2/30.
I wrote it all with file logic rather than bit logic so that the routine could process multiples of 16 valves at a time. It was extremely fast and low in memory use.
The IO addresses were arranged to support this (but even if they had not been it would have been easy to map them.)
No need for loops!

That's too funny, your possible "trick" for the addressing is EXACTLY the kind of thing I was thinking of and was calling a "gimmick".

The AOI is the only way I have been able to standardize functions while still allowing the end users a clear view of the execution.

If RA would get off of their butt's and get some firmware that allowed an online edit of an AOI then we would actually have something really useful. The required download to tweak an AOI is really painful in a running system.

Good luck with your project.

RSL

@FancisL

Yeah that is true, but if I wrote it using word level instructions or FAL's my customers would kick me to the curb!

There are lots of elegant clean ways to write code, almost none of which are embraced at the "plant level". It is unfair to expect the "firefighters" to understand code written like that. At least that is what they tell me.

RSL

As I mentioned I was using an AB2/30 - this was in the mid 80's.
Yes I had to teach the site people about AB advanced instructions, not only because of the valve drivers but many other things (state based control via Sequencers etc) however the client actually really like it in the end.
These days I would hope to be able to create a Class for valve drivers and then create instances of that class for each valve.

RSL said:

That's too funny, your possible "trick" for the addressing is EXACTLY the kind of thing I was thinking of and was calling a "gimmick".

The AOI is the only way I have been able to standardize functions while still allowing the end users a clear view of the execution.

If RA would get off of their butt's and get some firmware that allowed an online edit of an AOI then we would actually have something really useful. The required download to tweak an AOI is really painful in a running system.

Good luck with your project.

RSL

Click to expand...

The whole point of the AOI is that it is an instruction YOU create and use in your code, just as if you had used a pre-defined instruction RA provided.

It is intended that when AOIs are used in a project they are complete, functional, and fully tested. I would suggest that if you feel that you have to "tweak" them, then you did not make them properly in the first place.

IMHO, there is absolutely no place for AOIs being editable while online, one false move and you can cause all sorts of havoc. Think of the safety issues.....

I'm with daba on this one. On-line edits of an AOI in a running system with would require simultaneous replacement of code blocks in multiple locations. If the overall size of the AOI changes, that could shuffle almost the entire program memory. Do this while not causing a problem? Maybe not impossible, but much risk for a small benefit.

On a related topic. I sure would like to be able to do limited edits to UDTs online. Like change the descriptions of the elements. No running code issues there. But no luck fixing a typo in a UDT member description without a download it seems. It would be nice to change the member names as well. After all, the running code doesn't really use the member names or the descriptions.

I will agree that editing every attribute of an AOI online might be virtually impossible or highly complex. However it only makes since that the same "rules" would apply as any other UDT. If it is referenced you CAN'T change it. All AOI's are nothing more than routines with parameters passed into them. They are compiled as routines.

If you have ever edited code called by a FOR instruction you have edited something just as powerful as an AOI. I do not buy into the notion that editing the code in "function" will cause the universe to implode. I hear all too often how many horrible things could happen if you edit this or that. That is what programmers do, we have to decide what can and can't be edited in a running process safely. I do not think that decision has anything to do with editing an AOI on the fly.

I am trying not to sound too harsh but, the AOI was a solution to a problem that did not exist. I could already write functions AND edit them. The AOI was more about marketing and "hiding" code that end users could not understand or did not need to understand.

The whole point of the AOI is that it is an instruction YOU create and use in your code, just as if you had used a pre-defined instruction RA provided.

The whole point is to put in a pretty bubble gum like wrapper so nobody has to see any indirect addressing.

It is intended that when AOIs are used in a project they are complete, functional, and fully tested. I would suggest that if you feel that you have to "tweak" them, then you did not make them properly in the first place.

Really, no comment.....


Sorry if I offended anyone. It has been a long day.
RSL

I've done what you are asking about. Let me warn you, if its something that Bubba on maintenance needs to follow and understand then I suggest a different course of action. I'm speaking from experience.

That said, I suggest that instead of writing to an IO point within your loop that your UDT contains a .OUT element. Treat that as your output for all logic. Then somewhere outside the loop you use

XIC XV1000.OUT OTE Local:X.O.DATA.X

to write to the physical output. This has an advantage of buffering the IO.


If this is a question of programming large numbers of very similar rungs then look at this thread http://www.plctalk.net/qanda/showthread.php?t=53235 for a short cut to create huge numbers of similar rungs in a very short period of time using MS Excel.