CLX Input value changing mid rung?

[Ken Roach]

One of the major reasons for the asynchronous architecture of ControlLogix is badly underused; the Event Task.

When I have done projects with the fast analog modules, I used the module's connection update to trigger the Event Task that processes the analog inputs and makes decisions based on their values.

As long as that Task doesn't take longer to execute than the RPI of the analog module (it gets nowhere close) then I have synchronous input data arrival and logic processing.

 

[PLCRookie]

yes, that's exactly what it's capable of doing ...

the picture below illustrates one of the lab experiments that I occasionally run through to convince disbelievers ...

basically we set up another/separate PLC to toggle a relay ON and OFF about once per second – and let it clunk-clunk-clunk away all night ... when we come back in the next morning the ADD will show about 30 to 50 occurrences where the bit/box status of the real-world field device (the relay's contacts) made a change from ONE to ZERO right between the execution of the XIC and the execution of the XIO ...

note that the number you'll get will be random – but making the relay cycle faster will "load the dice" and increase the odds that you'll see some "midway-between-the-rung" changes ...

Ron,

Nice way of showing the concept.....another reason I am bummed that I will not be able to get to the boot camp.....at least until I move on.....hopefully.

 

[mellis]

Map IO in ControlLogix. Once you do it and understand the benefits, you won't go back. It "fixes" some perceived problems especially for those used to PLC5 and SLC. I came from the PLC5 world and am well aware of the differences. I voiced some of the same complaints in the early days. However, now that I understand the ControlLogix better, I don't really see them as problems anymore.

Here is how I typically do IO mapping in ControlLogix. For example, if you have a timed task for PID control, you want the associated IO mapped in that task. First, you copy all the analog inputs from the IO address to a tag. I like to use a UDT so that all data associated with that signal is part of the same tag. If you like, you can scale the analog input at the same time (use a CPT instead of a COP). Next you execute the PID instructions. Finally, you copy the PID outputs to the approriate IO address. Scale at the same time if you like.

For the continuous task, I map inputs at the beginning of the task and outputs and the end.

Performing the IO mapping in separate programs or routines depends on how complex your program layout is.

The benefits of this approach are:

Software development is entirely independant of IO assignments. You just don't care if they get revised several times while you are writing code, they need to be right for comissioning, but you can ignore them until then.

Simulation code is easy. You "turn off" the IO mapping routines and "turn on" simulation routines that drive the same tags. This can be as simple as a open/closed valve to a real process model.

By the way, I consider produce/consume tags to be IO and treat them the same way.

 

[Paul351W]

One of the major reasons for the asynchronous architecture of ControlLogix is badly underused; the Event Task.

When I have done projects with the fast analog modules, I used the module's connection update to trigger the Event Task that processes the analog inputs and makes decisions based on their values.

As long as that Task doesn't take longer to execute than the RPI of the analog module (it gets nowhere close) then I have synchronous input data arrival and logic processing.

I am doing pressure control on 4 circuits simultaneously, with flow compensation and the system can also control to torque, so I have one routine that uses data from multiple cards. It takes longer to go through the routine than the RPI on the cards, so I think buffering makes the most sense for me on this current setup.

I will have to look into event tasking if I ever get any free time

 

[TConnolly]

Paul, does that one routine that takes longer to go through happen to be in the continuous task? The CT always takes a long time to scan because it gets interrupted by EVERYTHING. I have seen cases were simply converting the CT to a periodic task reaps big improvements, eg, a CT might take 20mS to scan, but converting it to a periodic task with a 10mS period effectively doubles the performance and at the same time decreases processor loading. AB has a pretty dramatic demonstration that they do with training on the task monitor that shows how a few very small changes can speed up the program in big ways. Also, if your loop is slower than your process is updating then you're upside down, making process control more difficult than it should be.

 

[Paul351W]

I have a "Hydraulic Control" timed task set at 2.5 or 2.75ms, I don't recall at the moment. That contains the pressure PIDE's, the torque PIDE's, some calculations, feed forward curves, etc. It is set to the highest priority in the project as well. The continuous task has the non-time critical code in it like the mode control for the PIDE's.

The loop is running faster than the system can react, but we are playing some phasing tricks with the commands so we wanted it as fast as possible, and to run at a constant rate for repeatability.

 

[danny.michael]

Simulation code is easy. You "turn off" the IO mapping routines and "turn on" simulation routines that drive the same tags. This can be as simple as a open/closed valve to a real process model.

Be careful doing this. I always write simulation code to read and write real I/O tags. This assures that you catch any errors in mapping, and errors in scaling for analogs. You can disable the I/O modules so your sim code can write to them directly.

 

[mellis]

Be careful doing this. I always write simulation code to read and write real I/O tags. This assures that you catch any errors in mapping, and errors in scaling for analogs. You can disable the I/O modules so your sim code can write to them directly.

As I said, the real IO assignments are not an issue until commissioning. Then every IO point is verified including scaling. Until you have real devices to work with, there is no point in testing it. Do it once, when it counts.