ControlLogix L-55 Scan Problem

[rdrast]

Just another thought now for you. If I create a 500mSec Periodic Task and sucessfully get a 500mSec Pulse. I need to pass this into a number of AOIs in MainTask. Will this work correct?

Not with the task times you are showing. At 300ms on the cyclical task, you are only going to have your pulse present in it 3/5 of the time.

What exactly are you trying to time? It may make more sense here just to do a GSV every scan (GSV TASK TaskName RATE Destination), and accumulate the microseconds in your cyclical task as a 'timer'.

Still, a 300ms scan time of the cyclical task? that seems completely absurd. You might want to talk to the user about taking advantage of Rockwell's trade-up program, and move to a 60 series processor, something sounds just plain wrong there.

 

[Andybr]

Am I the only one who has not heard of running a rev16 program in an L55 processor? I thought that AB recommended moving to a newer hardware platform for this rev? Are you using some specific function of version 16? If not, you might be able to speed up your scan times by dropping the software level down to say 13, or even 10.

Russ.
We have V16 installed and running on quite a number of L55's. The only problem I have seen is with the bug in the PID block which throws up an error if you try to apply changes without viewing the loop update time. As far as I am aware this happens whichever processor you are using.
Andybr

 

[MorphuisOGrady]

Not with the task times you are showing. At 300ms on the cyclical task, you are only going to have your pulse present in it 3/5 of the time.

What exactly are you trying to time? It may make more sense here just to do a GSV every scan (GSV TASK TaskName RATE Destination), and accumulate the microseconds in your cyclical task as a 'timer'.

Still, a 300ms scan time of the cyclical task? that seems completely absurd. You might want to talk to the user about taking advantage of Rockwell's trade-up program, and move to a 60 series processor, something sounds just plain wrong there.

I agree 300msec scan is absurd. There are some complex ST routines iterating etc causing the heavy scan times.

Moving to a 60 series controller would not be an option, there are about 15 controllers running similiar type code (all with high scan times)

 

[rdrast]

I agree 300msec scan is absurd. There are some complex ST routines iterating etc causing the heavy scan times.

Moving to a 60 series controller would not be an option, there are about 15 controllers running similiar type code (all with high scan times)

Here's a question, do they all need to be executed every single scan? I often set up a DINT, load it with a 1, and multiply by 2 every scan, then use the bits to trigger routines sequentially, one (or more) per scan. On the last bit used, I reload a 1 into the DINT and let it recycle. (lazy shift register)

 

[John M]

Hi Gents,

Thanks very much for all your input on this. Like I said I didnt write this code. The periodic task appears to be just Messaging to VSDs, E3 Plus devices and Power Monitors. I think I will move this code into the Main Task. At least I will know my definite Scan time.

Yes Its V16 in an L-55. Lots of AOIs for control modules, Pumps, Valves, AI, AO etc.

Just another thought now for you. If I create a 500mSec Periodic Task and sucessfully get a 500mSec Pulse. I need to pass this into a number of AOIs in MainTask. Will this work correct?

Just a comment - you can't get a 500mSec Pulse from a 500mSec Periodic Task. That Task can only update at 500mSec intervals. You would need a task that executed at least twice that fast to get a pulse. Even that likely won't work as the execution of your code in the continous task is not deterministic. Even if you do it in your 100mSec task the pulse may only be on for part of your Continous task so your results would be inconsistent.
I realize that you didn't write the program either but it is typical of most programmers that they don't understand the scan and program execution of ControlLogix or they would put most of their code in Periodic tasks. They are more predictable and have higher priority than the continous task. They also help to improve communications time to HMI/SCADA as well as more reliable redundancy.
I would be inclined to put everything into periodic tasks if possible but that would require stopping the PLC and re-testing the program.