Programming methods

[Steve Bailey]

Isn't there any way in the ControlLogix programming to update the IO at the beginning or end of scan?

That's the issue. In ControlLogix the I/O service is performed asynchronously with the logic solution. Mapping the I/O to internal variables in a timed subroutine is a typical technique to make a ControLogix program service the I/O like a traditional PLC CPU.

 

[TurpoUrpo]

Could someone point any benefit of async IO. I cant think of any.

 

[Steve Bailey]

Could someone point any benefit of async IO. I cant think of any.

Bragging rights in the spec wars? You can claim a faster scan time if you don't include I/O service.

Seriously, I can't come up with any advantages either.

 

[williamlove]

Is aliasing a built in mapping technique?

I wish someone knowledgeable from Rockwell would weigh in with a factual non-opinionated explanation of why ControlLogix went to asynchronous I/O scanning. Perhaps a separate microprocessor handles that task. I will create a tech support case with them and tell you what they say.

We still use SLC and PLC5 a lot, so I go months without using ControlLogix. But I have to ask this: Doesn’t the aliasing feature negate the need for mapping from the standpoint of structuring/organizing things? (Let’s leave the scan issue out of this and focus on the purported advantages of mapping to achieve good organization.)

Or put another way, since I always use aliasing, have I been “mapping” all along? We use aliasing because it’s a no-brainer advantage…you can change the I/O or even figure it out later without messing with me, the programmer. Sounds like mapping.

But with aliasing its more “built in” than a mapping scheme like I’ve seen in SLCs. It would be hard for a maint tech to overlook it or not understand it or just use a raw address.

I structure the I/O aliases in ways that I can refer to the tag names conveniently. For example I may name my ControlLogix outputs for station lights this way: StationLight01, StationLight02, ….StationLight20. Then in code, or in HMI parameters, or even in ControlLogix structured text, I can do something like this: (I will hasten to add most of my code is ladder but 25% is not.)

VBATagName = “StationLight” & StationIndexNumber.Value 
SuccessfulStart = boolFunctionStationOn(VBATagName)

Is that why some of you map? Is alliasing the same thing as "mapping"? (Forget about the scan issue, we’ve beat that one to death).

 

[Paullys50]

I wish someone knowledgeable from Rockwell would weigh in with a factual non-opinionated explanation of why ControlLogix went to asynchronous I/O scanning. Perhaps a separate microprocessor handles that task. I will create a tech support case with them and tell you what they say. ....

Page 89 of 1756-UM001L-EN-P tells you out right that there are two processors, one for Program Logic, Memory and Comms referred to as the "Logix CPU" the second "Backplane CPU" handles IO data, Messages, Produced Consumed tags. It also says they are independent, which one would assume that this means they are not "syncing" logic and IO data....hence the asynchronous nature of the IO. It is a function of the hardware architecture that the Logix platform uses.

Aliasing is simply giving the root tag some other reference name, mainly for organizational purposes. Mapping is done for the specific purposes to enhance/ease functionality of the program (which have been discussed at length already).

 

[DamianInRochester]

I wish someone knowledgeable from Rockwell would weigh in with a factual non-opinionated explanation of why ControlLogix went to asynchronous I/O scanning. Perhaps a separate microprocessor handles that task. I will create a tech support case with them and tell you what they say.

We still use SLC and PLC5 a lot, so I go months without using ControlLogix. But I have to ask this: Doesn’t the aliasing feature negate the need for mapping from the standpoint of structuring/organizing things? (Let’s leave the scan issue out of this and focus on the purported advantages of mapping to achieve good organization.)

Or put another way, since I always use aliasing, have I been “mapping” all along? We use aliasing because it’s a no-brainer advantage…you can change the I/O or even figure it out later without messing with me, the programmer. Sounds like mapping.

But with aliasing its more “built in” than a mapping scheme like I’ve seen in SLCs. It would be hard for a maint tech to overlook it or not understand it or just use a raw address.

I structure the I/O aliases in ways that I can refer to the tag names conveniently. For example I may name my ControlLogix outputs for station lights this way: StationLight01, StationLight02, ….StationLight20. Then in code, or in HMI parameters, or even in ControlLogix structured text, I can do something like this: (I will hasten to add most of my code is ladder but 25% is not.)

VBATagName = “StationLight” & StationIndexNumber.Value 
SuccessfulStart = boolFunctionStationOn(VBATagName)

Is that why some of you map? Is alliasing the same thing as "mapping"? (Forget about the scan issue, we’ve beat that one to death).

I think one thing to keep in mind is that not all manufacturers support aliasing. In my case, I ususally try to use methods that are generic enough that they will function the same way no matter whos equipment I use. Thus, i tend not to use the aliasing much.

I do agree though that as long as your program has good organization that is ultimately the more important aspect. Mapping in and of itself doesn't necessarily mean that things are well organized. It is more so I think that the people who take the time to do it "on average" are the ones who also take the time to do other things properly as well.

For digital inputs, I may also use the buffering to add debouce timers, or alter the NC/NO aspect of the signal. That way these things don't clutter up the actuall sequence.

I find the buffering tends to be more handy in regards to the outputs than the inputs. I usually have at least two sets of of buffered bits (one for manual and one for auto). Thus, if I have a valve to extend a knife cylinder I will have and Auto bit called "A_Out_Knife_Extend" and a manual bit called "M_Out_Knife_Extend". I then interlock these with perhaps an Auto mode contact or manual mode contact. I keep things really symetric so that it does not take me long to build the buffer (a lot of quick copy and paste)

If I have a double solenoid valve, or something similar, I will also interlock them in the buffer as well so that both coils can't be on at the same time. To me all of this stuff works well in the buffer routine because it helps remove the clutter from the main program stream.

I may also add more branches to each buffer net for various modes. (ie. If I have a semi-auto mode that is running a sequence in manual mode).

I think also because I am big on "sequeced" or "quasi-state machine" programming the whole buffering concept tends fit well with it.

The buffering or mapping helps me separate a lot of the mundane clutter, debounces, interlocks, active level swaps, and modal stuff out of the actual sequence program so that the guy debugging it can just focus on the meat and potatoes without distractions.

 

[tommy23t]

I wanted to thank all who responded, a lively exchange. It seems the camp is split on this, as I suspected. I can see merits to both sides, I like the idea of mapping for using routines in similar programs, a time saver for sure. That being said I don't think I will adopt the strategy all the time but may when the project warrants it. I think what some do not realize is that we all use different plcs for whatever reason; this is not an AB forum. RSLogix is really nice, I use it when I have to (hardware$$), and it lends itself easily to organization, i.e. files, use of subroutines, ect. Other plcs that I have used are not so. Again, I am a ladder guy, small machine builder and have not delved into Controllogix or the like. I use many AD and Mitsubishi units, and that programming is not so easily organizable (is that a word?). The subroutines are still part of the main program when it comes to viewing/ finding things. With the Mitsubishi and I believe DirectSoft, I have used interrupts in the past for time critical events. I do not think these would be valid with mapping, as the state would change where the map occurred, say the beginning of the program (I assume).
Anyway, thanks for the replies, an interesting read. As to what my friend will do in the OP, I will leave it to him.
-tommy23t

 

[Paul351W]

In my small number of Controllogix projects I have done, I only map the analog input data. I had a test that was using an analog value to divide by, so I had a GEQ 0 and a EQU 0 statement so there wouldn't be a divide by 0 error when the data went to 0. I noticed random spikes in the calculated value, and discovered it was because the data was updating after my GEQ/EQU statement and dividing by 0.

After that I started buffering all analog input data that I might do calculations with, and the issue hasn't reappeared.

 

[Stephen3776]

Personally I map, because I like to be certain of when an input changes and for UDDT's. Mapping the IO to UDDT's helps ensures every valve IO is named the same. Thus the ZSO for Valve A from Local:5:I.Data.2 appears as ValveA.ZSO in the process logic and not Local:5:I.Data.2. That way there is some chance of figuring out what is going on if you do not have all the discriptors.
There is nothing difcicult about find the real-world input, just Cntrl-F, find all and click on the OTE. In addition, I sub-routine my mapping into appropriate groups (discrete in, discrete out, analog in, analog out).