Compactlogix Scan Time

[dave 1]

I'm using a 1769-L32E cpu with a rackful of regular I/O and in my program I want to read the actual scantime from the start of one scan to the start of the next, for example. I am using GSV PROGRAM MainProgram LastScanTime to copy the scantime in microseconds into my register "scantime_us". It sort of works but gives me an error of about 40%. If I measure the actual scantime by having a register increment by one on each scan and see how long it takes to count to 30,000 it gives me about 4mS average scantime. The above GSV instruction only reports 2.4mS however. I assume this is to do with overhead like I/O scanning and comms. timeslice setting (currently set to 20%). Is there another simple way I can get the average actual scantime with reasonable accuracy, please?

[BobLfoot 301]

Dave - I think we need to agree on terminology and a wiser guru than I {aka Ken Roach} will probably correct what I am about to say somewhat, but here goes. Scan Time in the old PLC 5 days was the amount of time it takes the CPU to go from the top of the first ladder file to the bottom of the last. This changed drastically in the ControlLogix, Compactlogix era with the introduction of the Periodic Task and heavy use of interrupts. Assuming that you have no periodic tasks and no motion instructions interrupting the scan then the difference between your calcualted 4ms and the measured 2.4 ms is the fact that you are considering overhead processing as part of the scan and it is not part of scan time in Allen bradley's way of measuring it. Yiou might get an equally useful measurement by recording the clock value at rung 0 and again at rung end and doing the math between them. Not sure which clock register to grab with a GSV. Also remember adding your GSV introduces scan time. "The mere act of observing the behavior changes the behavior" as wise man once said.

[dave 1]

Hi Bob - Yes my definitions could have been more lucid. The scantime I am interested in is the total interval between rung 0 in the main task and the next rung 0 in the main task. So this interval includes the time to carry out all ladder logic, update the I/O, plus any comms. and general cpu 'housekeeping' (in other words, logic + overhead). Using GSV to get LastScanTime seems to give me the time to do the ladder logic but not the rest of it. Your suggestion to use the real-time clock might work, grabbing the value each time we pass rung 0 and calculating the change. However, I would like to know the scan-time in microseconds, or at least fairly accurately, so may have to do this measurement over several scans and work out the average or something. I'd hoped there might be some secret way to get overall scantime straight into a register in microseconds. I can't think of any useful reason for knowing time spent in a given task apart from watchdogs for 'hung' programs. Thanks for the ideas.

[Guest]

Dave ... regarding your statement: no offense intended, but do you realize that with this platform, updating the I/O does NOT occur on each and every scan? ... specifically, you could have many "fast" scans WITHOUT updating the I/O – and then have one scan which would be much "slower" due to the I/O update ... and the "extra" time required to update the I/O can be substantial ... if I understand what you're trying to accomplish, all of this is certain to affect any method that you use in your scantime calculations ... suggestion: why don't you tell us WHY you need the value that you're trying to determine? ... maybe someone can come up with an idea that will be helpful ...

[TConnolly 13]

Consider using the Logix 5000 Task Monitor under the tools menu in RSLoigx5000. It will give you a lot more information about your tasks and what is using processor resources and how much. If you really need to know how long it is between start of rung 0 to next start of rung 0 then use a periodic task. Don't be afraid of using one in lieu of the continuous task. Some programs actually can actually gain a speed benefit by deleting the main continuous task and running everything in a periodic task. The same program that takes four mS to run in a continuous task might execute is less than 1mS in a periodic task since it is not subject to interruption to the degree the continuous task is. If your program can be taken offline you might want to play around with it. Check the task monitor to see how fast your continuous task is. Now change the task to a periodic task with a similar period. You should see in the task monitor that the program is executing faster now and CPU has gone down. Now increase the task rate for the task. You should be able to get more scans per second for the program that way.

[dave 1]

I do a lot of work in heat treatment, forging and drawing/insertion applications. Over a long period of time I have evolved several bespoke software 'modules' to do specific tasks and they work extremely well in Siemens and Logix500 systems. The blocks are for things like 2nd order digital filters, adaptive derivative functions for impulse/bounce response, precision timing of burner flame and exhaust accumulation, so on and so forth. Unlike the standard PID blocks and similar algorithms built into many plc's, these update on every program scan and need to know the elapsed time interval since last scan to work properly. Essentially they are working at the bandwidth limit of a typical plc but compare favourably with other people's custom hardware and so easy to moitor and adjust. On migrating into Logix5000, i find it all works OK but I'm seeing wrong response rates due to false scantime measurement. I can put in a juggle factor to roughly correct it and it's almost good enough but I'd like it as good as it is on the older kit.

[OkiePC 14]

Then, I would agree with Alaric, to just put those routines in a periodic task and then you'll know exactly how much scan time has elapsed. If they need to update only once per whole PLC scan, then make the main program periodic as Alaric suggested. Then, your delta-T becomes a fixed number from one scan to the next.

[TimWilborne 108]

I agree with Paul and Alaric. Move those to a periodic task. This was a problem I had adapting to at first with the Controllogix systems. You should put your time critical code in periodic task which seems wrong since it is periodic which if you are like me means you associate that with on occasional task. But periodic could be every ms. The key to understanding this is putting the task priority into the equation. Your time critical task should have the highest priority, this way it can interrupt less critical task and your main continuous task. Maybe someone has a good whitepaper on this.

[BobLfoot 301]

Let me add one thing to waht Paul, Alaric and Twcontrols have all said. Tasks like you describe which need to happen on a fixed time interval are an excellent candidate for perioidic in the Control Logix Platform. One caveat about the perioedic task though is that a smaller period is not necessarily better. Watch the properties tab on the tree of you tasks when running and watch for task overlap. If you get tasks overlapping then theya re not running at the advertised period and all bets can be off. Changing one task from 30ms to 15ms period may cause several 5ms tasks to start overlapping. It's involved why this happens and you'll leanr it if you play a little. Just trust me and don't overlap tasks if at all possible.

[Guest]

Greetings to all ... I hate to throw anything else into this stewpot, but there seems to be one more potential issue that hasn't been discussed ... the COMPACT-logix does NOT work the same way as the CONTROL-logix when it comes to processing its I/O ... the difference in operation MIGHT have an "adverse" effect on what you guys are trying to accomplish in this thread ... suggested reading from the: CompactLogix Controllers User Manual Publication 1769-UM011F-EN-P January 2007 http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1769-um011_-en-p.pdf I recommend starting on page 67 at the paragraph "Specify Task Priorities" – then continue on through the top section of page 69 ... the figure below (random excerpts) sums up some of the most important information to focus on ... note that in the chart on page 68, the value "7" specified as the "Priority Level" for the Dedicated I/O task is a misprint ... that should be a value of "6" ... many of the older manuals for the CompactLogix mistakenly reported the priority as seven ... the "piano-keys" chart at the bottom of page 68 should be especially interesting in the context of this particular thread ... also note that the flow chart shown on page 61 is bogus ... this is a Copy-and-Paste from the CONTROL-logix manual ... they basically just changed the name at the top to COMPACT-logix and assumed that the I/O operation is the same ... specific examples of bogusness: there is no Change Of State in CompactLogix – and local outputs do not get updated at the end of every task ... I wish I had more time to play – but I thought that you guys might want to consider some of this ... it could well have an effect on what you're trying to accomplish ... as far as I know, these issues have never been discussed in any depth on the forums ... if you know of any discussions that I've missed, please bring them to my attention ... I've been researching and experimenting with these concepts for a while ... good luck with your project ...

[Steve G 1]

I know this may be a little off topic but I have a system I am currently working on and started to mess with the tasks. My starting scan time was 24 ms for the main task, when I changed the task to a periodic task it took the scan time from 24 to 15 ms. I set the time for the task at 15 ms and a priority of 1. Is this Ok to do or does it do something funky to the system. The PLC is a L62 and I am using redundancy on the system.

[Steve G 1]

Well I guess I sort for answered my own question. As I looked at the Task Monitor as soon as I downloaded the new program it took the CPU usage from 15% to 70%.

[BobLfoot 301]

Steve G - As I said above watch for task overlap. Remember that when the task was continuous that it got interrupted. As a periodic with priority 1 it disrupts all others. So it may well scan faster. My personal preference is to set the period tio 2X the avg task scan time or 1ms greater than the max scan time whichever is larger. In your case I'd put the period at 30ms. But that's just an opinion.

[Steve G 1]

Thanks for the reply, as I changed the program I first set the scan time for 5 ms and as you stated above I got a lot of task overlaps so I set the time to 15ms and reset the task overlap counter and it stayed at 0 overlaps. I fully agree with you that you should not have any overlaps in the program; my only concern with this is the CPU usage stays at 70%. It appears that by setting your main task as a periodic task you use a whole lot more of the processors resources. Have you also found this to be true? I guess there is one other thing I should mention, in the new version there is no task that runs continuously. Edited 8 Jul 2011 by Steve G

[TimWilborne 108]

Why not just put your time critical code in your fast task?

[Steve G 1]

I do not believe I will use this method of putting my continuous task into a periodic. I saw this post and while my project is on hold I thought I would mess around with it and see what would happen if I tried to decrees my scan time by putting it in a periodic tack and telling it to run faster then it currently is. My project currently uses task that are periodic and yes the code I need to run faster is in a fast task and the code I need to run at a specific time has been put into another task. Edited 8 Jul 2011 by Steve G

[dave 1]

Many thanks to everyone for their contributions here. I have learned a few facts and tricks which will be very useful. I have been browsing around in the background and discovered this simple little gem for measuring actual average scan time (see attachment). It only updates every 1000 scans, but gives a quite accurate average value which is adequate for my routines to use. The next step is to make a true rolling average by getting the total time for the last 1000 scans on EVERY scan. Using this avoids any need to prioritise tasks; as I said above, it doesn't matter what the scan time is, or if it is varying a lot, as long as I know what it is. Thanks again! Logix_scan_eval.pdf Edited 9 Jul 2011 by dave

[Scott9176 0]

Dave, I wanted to see the program Logix_scan_eval.pdf file that you mentioned, but their isn't an attachment in your post. Could you please repost it? Thank you!