Studio5000 I/O Buffer

Bbarnett

Member
Join Date
Jul 2013
Location
United States
Posts
77
Is it good practice to buffer all I/O, including local and safety I/O?

How do you buffer? Create a routine that maps out bit for bit to a UDT bit? Maybe create a bunch of alias tags?
 
We nomally make our first routine “Input Buffer” and our last routine “Output Buffer”
Just to make it clear for the customer what is going on when they access the program for machine maintenance and troubleshooting.
We normally make alias tags called “Slot 1 Local Buffered Input” “Slot 2 Buffered Output” and so on then we use the CPS instruction and normally do 1 slot per rung and on remote we nust use the adapter name and add buffered like “node 1 slot 5 Buffered” on flex io or other renote I/O platforms.
 
It's certainly a common enough practice. And it has certain advantages to doing so. The reasons for needing to do so are over-hyped, IMO. While it's true that I/O updates are asynchronous to scan, and in theory that means that a contact on one rung could evaluate differently than a contact on a different rung, it is actually pretty rare where that would make a difference in how the logic solves.

Yes, if you have a UDT / AOI that turns all the I/O into a set of objects, then having one location where there is a 1:1 mapping of the real-world I/O tag to the UDT/AIO element.

Then again, if you have AOIs, and if a required input / output is the real-world address, then simply putting in that address in the AOI block serves the same purpose, and eliminates the need for any mapping routine.

The key advantages to mapping routines are these:

- The I/O address is used in only one place in the code. Thus, if that channel on the I/O card dies and the wires need to landed on a different point, there is only one place in the code that needs to be changed.

- Some programmers like to write simulation logic, and then have a "simulation mapping" routine that parallels the "real mapping" one. They can thus disable the real I/O and switch to simulation easily. Personally, I just have the simulation logic map to the real I/O point and inhibit the I/O scanning. But that does, admittedly, violate the "use the address only once in the code" rule. Every programmer has his/her own style; this is part of mine.

Too often I've seen programs have a collection of "Buffer tags" that get mapped to, and then those buffer tags write to a UDT/AOI tag. Each buffer tag winds up only being used twice in the code, once as a coil, once as a contact. Pretty pointless, IMO, and adds an extra layer of abstraction when trying to trace something back to the I/O point. But they were "required to buffer the I/O", so that's what they did.
 
Last edited:
- The I/O address is used in only one place in the code. Thus, if that channel on the I/O card dies and the wires need to landed on a different point, there is only one place in the code that needs to be changed.

This is really the biggest benefit of having an I/O mapping routine in my opinion. Being able to change the I/O address in one place and knowing the rest of the code will work as intended is great.

As an aside, I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).
 
As an aside, I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).

For Sparky's sake, I leave it the h/w I/O address. I have on, occasion, aliased that tag to a tag that describes it by the device.
 
Thank you all, this is helpful.

While it's true that I/O updates are asynchronous to scan, and in theory that means that a contact on one rung could evaluate differently than a contact on a different rung, it is actually pretty rare where that would make a difference in how the logic solves.

Aardwizz,
In an asynchronous scan, if I have a sensor with an integer value, and I use a COP instead of a CPS, then it's possible that during the input bits being read, the value could change and result in some bogus value, correct?
 
For Sparky's sake, I leave it the h/w I/O address. I have on, occasion, aliased that tag to a tag that describes it by the device.

That's a good point, obviously you can always use the tag description for the hardware description, but I was just curious what people's opinions on best practices were. Similar to when you convert a PLC-5 program to Logix and it creates tags with the original I/O address (I_00_Bit1 etc), it's nice to have that correlation with the physical I/O.
 
This is really the biggest benefit of having an I/O mapping routine in my opinion. Being able to change the I/O address in one place and knowing the rest of the code will work as intended is great.

As an aside, I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).

I'll usually have memory bits named similarly to the address but create a comment with something much more descriptive to a human. I even create UDTs to get the .I. and the .O. structure. See attached snippets for what I mean.

Snippet.png Snippet2.png snippet3.png
 
Last edited:
To this day, I don't understand why AB doesn't just automatically buffer everything for you. Siemens buffers everything (you can even pick which OB/task it gets buffered with, although that's usually overkill), and then lets you have immediate access for the rare occasions you want the super duper most up to date value. It's an idea that's been out there for years, and doesn't seem like it should be THAT hard to implement, even it it isn't a completely minor change.

Not trying to start a flame war, Siemens has plenty of warts, but it seems like a feature that would be hailed as a huge time saver, and utilized by the whole customer base. Then again, it probably wouldn't sell additional units, so i guess I just answered my own question?
 
This is really the biggest benefit of having an I/O mapping routine in my opinion. Being able to change the I/O address in one place and knowing the rest of the code will work as intended is great.

As an aside, I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).


My vote is to use a descriptive Tag and not a tag named for the channel. If you use a channel tag name, (ie. Input_0_1) and then down the road you change to use a different channel, you either have to go through and replace ever instance of Input_0_1, or worse yet you leave the tag as Input_0_1 but it is tied to a different channel! In which case why even go through the effort of buffering?
 
I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).

If you create an alias called FCV_Limit_Sw_Closed for, say, Local:3.I:Data.1 and that point dies and you want to now wire it Local:4.I.Data.13, your alias (which cannot be altered online) will still point to the old card, which defeats the purpose of creating the alias.

OTOH, having an alias Input_03_01 (please zero pad things, or _10 will be between _1 and _2, which is annoying) as an alias to Local:3.I.Data.1 doesn't add any value. The alias tag and the real-world tag are redundant.

So don't bother with aliases in your mapping. DO add descriptions (tag names and descriptive name) to the I/O addresses, so you can tell what's on that card when looking at it in the data table.

In an asynchronous scan, if I have a sensor with an integer value, and I use a COP instead of a CPS, then it's possible that during the input bits being read, the value could change and result in some bogus value, correct?

Theoretically, yes. That's why CPS was invented. Especially annoying when there is a small change in the bit pattern: 1000000 going to 0111111 or vice versa. The value only changed by 1. But if the I/O update hit at the exact microsecond that it was reading bit 6, the resulting value could be 0000000 or 11111111, essentially halving or doubling the real value, instead of showing it as virtually unchanged.

This is capable of triggering all sorts of alarms and thus shutdowns when there was never a real issue.

Of course, this only applies to analog I/O, where the bits are interpreted as a unit. If you were merely copying all the .Data bits in a discrete card to some buffering DInt, whether one bit was or was not set on the same scan as another hardly matters.

If it really does, then get an SOE module which will REALLY tell you which input was on first.
 
Last edited:
I use input and output mapping routines in just about every program, in ladder, organized to match the physical IO, in order. Every IO point is there, if it assigned or not, which makes it easy to look at a particular input/output device, and find available unused points for the constant changes.


The mapping is always directly from the base tag to an appropriately named and described one.
 
+1
I just think it makes life so much easier. I'm the only one that see's my code but in another 10 years I plan on being at the house all day so someone else will have to take over. Trying to make their life easier. 🍺


I use input and output mapping routines in just about every program, in ladder, organized to match the physical IO, in order. Every IO point is there, if it assigned or not, which makes it easy to look at a particular input/output device, and find available unused points for the constant changes.


The mapping is always directly from the base tag to an appropriately named and described one.
 
Thanks everyone for the replies. Sounds like the vast majority buffer inputs of an input card and outputs of an output card. But, here's another nitpicky quesiton:

How many of you buffer the inputs (echo) of the output card? How many of you actually use this echo feature?
 

Similar Topics

Hi Hope you all are doing well. Iam working on a project with some AOI. I also hate no online edits... lol. My problem occurs when I use a UDT...
Replies
1
Views
42
I am not sure if this is possible but if there is a way, you guys would be the ones to know. I am currently working on a project where we are...
Replies
7
Views
185
Hi all. I'm having issues adding an ethernet module to my project in Studio500 v34. The device is a Fredericks Televac EthernetIP MX gateway which...
Replies
8
Views
260
The day of week program started changing day of week 2 hours early. It changes at 10 P.M. instead of 12A.M. Just started this year.
Replies
22
Views
2,570
Hello All, need one help , looking for a example which can help me to write following code in Studio 5000 ladder logic. I have 2 String...
Replies
14
Views
4,244
Back
Top Bottom