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
↧