ControlLogix L-55 Scan Problem

Join Date
Jul 2007
Location
Kiruna
Posts
600
Gentlemen,

I have been called in to make a few modifications to a program created by another vendor. The controller is an AB L-55 Version 16.

The first thing to note is the Main task scan time is extremely high at approx 300ms. There is also an additional periodic task set at 100mS.

Basically I need a 500ms pulse and with this i want to increment a register which i will you to adjust a speed reference .

The problem is my program is not "catching" all the pulses. For a minute i would expect to get the Timer.DN bit 120 times but in fact i only get it 30 times.

Can anyone make sense of this?
 
Can you put your code in the 100ms periodic task with a 5 count counter? Let it's DN bit to increment the register and reset the counter.

Edit - actually don't use a 'counter' (you won't have the transition to trigger it). Just increment a local tag. When it gets to '5' do the incrementing as mentioned above then clear the tag.
 
Last edited:
I am curious Bernie why you suggest 100ms as the periodic rate and incrementing a tag then checking for a "5". Why not a periodic rate of 500ms?

Also, you can use a counter but just add an unlatch of the .CU.

OG
 
OK Guys,

Thanks for your help on other ways of getting there.I want to figure out why my way wont work. Can you explain why it wont work the way I have it?

My understanding is at 300msec scan time the program will jump to the periodic task 3 times during a full scan, therefore my entire scan should be 100ms + period task + 100ms + Periodic Task + 100ms ---Scan complete.

Im not sure how long Periodic task takes to process but i'm guessing max 50mS.
 
Got it Bernie. I was thinking new task instead of using the existing. Makes sense now!

Morphius you can right click on your periodic task and select Properties and then the Monitor tab to view the scan time of your Periodic Task.

OG
 
The Periodic task is taking part of the "interval time". So if your interval is 100ms and the Periodic task itself takes say 70ms then when it completes it will return to the Continuous task for 30ms before the interrupt occurs again.

You mention a timer. Where is the timer located and what are you setting for a preset?

OG
 
Look at this example.

On Scan A the timer would finish and "Go_Do_Something"

On Scan B the timer would reset

On Scan C the timer would restart.

If your scan time is 300ms that is where you are losing your accuracy. It is around 600ms from when the timer finishes until it restarts. So for every 500ms you are off by 600ms!

Timer.JPG
 
This would be more accurate. But it would still be 300ms from the end of Scan A until restarting on Scan B.

The periodic task will give you the accuracy a timer cannot.

* disclaimer * I would usually arrange this differently. Typically I would put the reset above the timer triggered by the Done bit. That would give me one full scan to use the .DN bit.

OG

Timer2.JPG
 
I did my own little test here.

I created a continuous task that was around 300ms for scan time and a periodic task running every 500ms that took about 50ms.

I set up a timer and counter in the continuous task (as in post #8). The timer was set for 500ms. I added a counter to the periodic task. Then I added logic to start the timing/counting process for one minute.

After one minute the continuous task timer/counter combination had counted 41 counts. in that same time the periodic task counter was at 120.

After rearranging and using the timer done bit to trigger a RES and putting that above the TON (similar to post #9) the results where a little different. I got 55 counts in this configuration. However if it had been truly accurate I should have gotten 120.

OG
 
Last edited:
Have you tried the - as suggested by others - that instead of resetting the timer in the 300ms task just subtracting 500 from the accumulated value? While the trigger-to-trigger time would not be constant the overall count of timeouts should be consistent with the 500ms task.
 
You are having problems because you are using a Timer to generate your pulse. The Timer has to be scanned in one of the tasks, and each of them seem to have what I would consider to be long scan times. This will lead to timer overrun, because by the time you scan it, it will inevitably have gone past it's preset - hence time "lost". Then there is the issue of needing another scan to restart it, as has been pointed out. Just keep in the back of your mind that a Timer is NOT a Timer, but simply an instruction that looks at elapsed time since it was scanned, and adds a value to its accumulator.

The answer is to put a 500mS Periodic Task in, and do all you need to do in the task itself, i.e. don't try and generate a pulse to be used in either of the other tasks.

And for me, having a 100mS Periodic Task that takes 50mS to execute is wrong, there is too much in there. What is in the task that needs triggering every 100mS ?
 
Here's what I think is going on in your ControlLogix.

0ms
interrupt continuous task and run periodic task.

50ms
Start continuous task. (this time is shared with overhead tasks - split determined by your overhead time slice setting)

100ms
interrupt continuous task and run periodic task.

150ms
Continue continuous task.

200ms
interrupt continuous task and run periodic task.

250ms
Continue continuous task.

300ms
interrupt continuous task and run periodic task.

350ms
Continue continuous task.

400ms
interrupt continuous task and run periodic task.

450ms
Continue continuous task.

600ms
interrupt continuous task and run periodic task.

650ms
Continue continuous task (this is the ealiest you can expect the continuous task to have made one loop, more likely it takes at least one more pass)

As you can see, about the best you can reasonably hope for is that your timer in the continuous task gets checked once every 700ms or so. The important thing here is the timer instruction is not an interrupt. It only gets checked for completion when it executes.

In this senario, I would expect this behavior:
scan A timer enabled
scan B timer expired (and overrun by a significant amount)
scan C timer reset (not 100% sure this takes it's own scan)

repeat

Expected cycle time = 3 X 700ms = 2.1 sec

Expected counts in 1 minute 28 - 29.

I think that lines up pretty close with your observations.
 
Last edited:
Surprized at the software rev level

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.
 
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.

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?
 

Similar Topics

Hi everyone: I have a doubt about postscan in RSLogix 5k, for example in help file for OTE instruction, says that in Postscan The rung...
Replies
2
Views
1,190
Hi Gents, I am here with an 1756-L73 with a partner 1756-L7SP. This is for an hydraulic press machine, with an very critical scan. I need your...
Replies
2
Views
2,937
My new friend Ron Beaufort got me thinking about the issues with using OTL's in regards to a power cycle. While you can use a first scan bit...
Replies
10
Views
4,637
Hi Guys, Quick Question... Is there a method or instruction to purposely delay the scan time of a ControlLogix processor? We're looking at...
Replies
12
Views
4,042
Let's say... A_DINT = 100 In some subroutine: rung 1 : A_DINT = A_DINT + 1 rung 2 : A_DINT = A_DINT + 2 rung 3 : A_DINT = A_DINT + 3 After a...
Replies
2
Views
1,417
Back
Top Bottom