Sign in to follow this  
Followers 0
Guest

COMPACT-Logix – Secrets of the Scan Cycle

17 posts in this topic

Greetings to all ... this is just a quick study on a simple problem that can be particularly hard to troubleshoot ... with a COMPACT-Logix system, the Task Priorities can degrade our I/O Signals ... suppose that we have a COMPACT-Logix system (specifically, NOT a CONTROL-Logix system) which is giving problems ... this is a high-speed application, and from time-to-time it appears that our digital input and/or output signals are intermittently "missing a beat" ... for examples: (1) random parts moving down our high-speed conveyor line are "skipped" and don't get counted ... (2) our high-speed labeling machine intermittently "skips" a random box – and so our serial numbers get out of sequence ... (3) input pulses from our flow meter occasionally get "skipped" – so our accumulated measurements of transferred material are sometimes inaccurate ... (4) an air-jet which is supposed to reject out-of-spec parts sometimes "misfires" ... bad parts don't always get rejected ... and sometimes the jet stays on too long and rejects a few good parts along with a bad one ... (5) and so on ... click the link below for a quick little soundtrack to demonstrate what I'm talking about ... (aside: my wife calls this little experiment "the cricket" for obvious reasons) ... CompactLogix_Priority_7_to_5.wav the track lasts for a total of twenty seconds ... during the first ten seconds you'll hear a piezo beeper give an annoying but REGULARLY-SPACED series of chirps ... ten seconds into the track a short tone will sound ... at that point the patterns of chirps will suddenly become DEGRADED ... the degraded signal demonstrates that the output signal is NOT being properly handled by the COMPACT-logix system ... here's what's going on ... a COMPACT-Logix controller is sending a pulse train to the piezo beeper through a DC output module ... the "pulse" logic is running in a periodic task which has a PRIORITY setting of 1 ... this lowest possible number gives the task the highest possible priority ... another periodic task has been set up to execute a "scantime hog" for demonstration purposes ... during the first half of the soundtrack, the priority for this task is set for 7 ... when the tone sounds to mark the halfway point of the track, we manually shift the priority of this "scantime hog" task to a new setting of 5 ... at first glance it might seem that the change in the priority setting is somehow affecting the operation of the "pulser" task ... that is NOT where the problem lies ... this particular problem is much more subtle than that ... here's the secret handshake: the COMPACT-Logix platform uses a "Dedicated I/O Task" to transfer its I/O signals between the processor's data tables and the system's I/O modules ... AND ... the "Dedicated I/O Task" always has a priority of 6 ... so ... as soon as we changed the priority of the "scantime hog" task to a setting of 5, that task now OUTRANKS the processor's I/O task ... oops! ... keep in mind that the logic located in the "pulser" task is still faithfully chugging right along – never missing a beat ... remember it has a priority of 1 – so the "scantime hog" doesn't affect the "pulser" logic at all ... specifically, the one/zero status of the beeper's bit/box is still being changed correctly – just like before ... but ... sometimes (intermittently) when the "I/O task" tries to transfer the one/zero status of the bit/box over to the output module, the "off" or "on" signal can't get through ... now doesn't this sound like a "fun" little problem to troubleshoot? ... what would an untrained technician/programmer/engineer be suspecting when faced with this sort of INTERMITTENT problem? ... a loose connection? ... a defective sensor? ... an intermittently bad input or output module? ... something else? ... and how about this wrinkle? ... the "Logix5000 Task Monitor Tool" doesn't show (or even mention) this mysterious "Dedicated I/O Task" ... (screen shot attached) ... so anyone trying to track down this type of problem isn't going to find much help by using that particular tool ... anyway ... I hope that I've proved my point ... and just for completeness – here is a soundtrack of the "cricket" being driven by a CONTROL-Logix system rather than by a COMPACT-Logix ... ControlLogix_Priority_7_to_5.wav once again the track lasts for a total of twenty seconds ... during the first ten seconds the beeper gives a REGULARLY-SPACED series of chirps ... then when the "half-way" tone sounds, we manually shift the priority of the "scantime hog" task from a setting of 7 - to a new setting of 5 ... but in this particular experiment, the patterns of chirps do NOT become degraded ... the reason is that the larger CONTROL-Logix system does not rely on the same "Dedicated I/O Task" that the smaller COMPACT-Logix system uses ... in simplest terms, the CONTROL-Logix system and the COMPACT-Logix system are NOT the same "under-the-hood" ... this sometimes critical fact is often overlooked ... personally I think that's because the same RSLogix-5000 software is used to program both of the hardware platforms – so people just seem to assume that the "works" must be the same – just in different-sized packages ... well, that's all I've got time for right now – but I know for a fact that this particular "gotcha!" has been a troubleshooting nightmare for some unsuspecting souls – so I thought that I'd pass this along for the general good of the forum community ... I'm also including a few attachments – just in case anyone is interested in pursuing this line of experiments in the future ... Beeper_CPX.pdf Edited by Ron Beaufort
1 person likes this

Share this post


Link to post
Share on other sites
Good Stuff. Thanks

Share this post


Link to post
Share on other sites
Fantastic info. Thanks for sharing.

Share this post


Link to post
Share on other sites
let me see if I get this straight....if you do something in logic, faster than the io can actually be administered it doesn't work? i have only one word for what, on its face, seems to be bad programming practices and little or no engineering.......duh?

Share this post


Link to post
Share on other sites
from rswolf ... no, somehow you've misunderstood ... NOTHING in the logic was "faster than the I/O" would handle ... listening to the first ten seconds of the demonstration WAV files that I posted will absolutely prove that concept ... specifically, when the pulse signals became degraded, NOTHING in the logic was changed – and NOTHING in the logic became rescheduled – and NOTHING about the RPI (Requested Packet Interval) for the I/O was changed either ... in fact ... the ONLY change was that the Dedicated I/O task was suddenly "outranked" by the program logic – when the PRIORITY of the "scantime hog" task was changed from 7 to 5 ... so ... it was NOT (as you implied) that the logic was suddenly made "faster" than the I/O ... indeed, ALL of the "speeds" stayed precisely the same throughout the demonstrations ... instead only one task PRIORITY was changed – and that's what degraded the performance of the I/O signals ... the major thrust of the thread is that many programmers habitually set their tasks for the HIGHEST possible priorities – and their task periods for the FASTEST possible rates ... in some cases those settings may be the only reason why input and output signals are being "skipped" ... specifically, in the demonstration that I posted, just simply changing the "scantime hog" task priority from 5 to 7 would have provided a perfect fix to the customer's problem ... this is counterintuitive to most programmers ... without some explanation (or painful experience), it could certainly be assumed that making the task priorities HIGHER should have a corrective effect ... but ... in actual practice, sometimes a higher priority can cause problems - and a LOWER priority is required instead ... in closing ... many people would consider intermittently skipped I/O signals to be a serious problem ... I've made an honest effort to provide some information and some knowledge which hopefully will help alleviate some of the "bad programming practices and little or no engineering" situations that you yourself have mentioned ... I whole-heartedly agree with you that these "pedal-to-the-metal" settings could well be considered "bad programming practices" ... going further, personally I think that one of the main purposes of the forum is to help identify and correct some of these "bad programming practices" before they cause problems ... that was my intention – and my sole purpose for writing ... thank you for this opportunity to clarify what I had posted earlier ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
and to Robobob and drforsythe ... thank you both for your kind compliments ... I sincerely appreciate the positive feedback ...

Share this post


Link to post
Share on other sites
Good write-up Ron, this "hidden" I/O task is often overlooked by many system programmers. I haven't got the hardware to test it, but what happens to your "chirping" if you chose priority 6 for your logger ? I know that the controller will "time-slice" between multiple tasks of the same priority, and I'm guessing it will have some effect.... but how much ? daba

Share this post


Link to post
Share on other sites
Ron, do you have a tech reference for the priority setting of the CompactLogix 'Dedicated I/O Scan'. Also is there a good reference for the differences between the CompactLogix and the ControlLogix handling of the I/O. Great write-up. We generally just use the Continuous type so anything at all interrupts it.

Share this post


Link to post
Share on other sites
Actually this information can be found in this pub; Publication 1769-UM011F-EN-P - January 2007 Exactly how Ron spelled it out is in there...Pg 67, 68, 69

Share this post


Link to post
Share on other sites
I know you stated this is a Compact Logix system, but we have been wrestling with an issue in the Control Logix family that is related to your issue: High-speed task, set with Priority 1 with a 5ms schedule does NOT scan repeatedly every 5ms. This task typically scans every 1.5 to 2.85 ms (even though it is set to 5ms Periodic Schedule). I have completed many, many experiments to reduce the schedule of the high-speed task with regularity with no known solution. We have brought in A-B/Rockwell to hammer them over the head. This solution was an A-B upgrade to replace a dated G&L Kollmorgen system that had a subroutine that executed every 1ms. The end result...A-B/Rockwell cannot say (1) What is the minimum scan time a ControlLogix CPU can execute at & (2) Why do ControlLogix CPUs not adhere to a Periodic schedule.

Share this post


Link to post
Share on other sites
Can you put up a screenshot of the scan times?

Share this post


Link to post
Share on other sites
That number is the time it takes to execute the logic, not the interval between scans. Open RSLogix, right click on the task, click on properties and open the monitor tab. From there you can see the Scan Times and the Interval Times. Interval Time is what you're looking for.

Share this post


Link to post
Share on other sites
I am following you. INTERVAL TIMES is the delta between scan cycles; SCAN TIMES is the elapsed time, the duration of the scan cycle. TaskMonitor 2.bmp

Share this post


Link to post
Share on other sites
You got it. And since your interval times are varying from 4.9 to 5.1 mS, it looks like it's working just fine. Edited by MrAutomation

Share this post


Link to post
Share on other sites

Where is the link . Can you please send it here again. I cant find any attachement

Share this post


Link to post
Share on other sites

awesome thanks

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0