Problem referencing coils used in multiple places in A-B PLC5/40C

I have a problem with a program written where OTE Coils are used in multiple places (as are other items) in a RSLogix 5 program from a PLC5/40C. The are just skipped (JMP/LBL) over depending on the step the process is in.

When I try to view the program on-line, the 'ON' status for these bits/ outputs is erratic and turns on and off for no reason even though at the processor, the lights are steady.

The system works fine, but this makes it hard to troubleshoot. Also, as we begin to replace PanelView HMI's with VersaView touchscreens using RSView32, any conditional color changing of anything referenced in the program also will blink on and off just like the online view.

Is there a problem here, and a way to correct it, or is this just something I'll need to learn to live with?

One idea:
Go through the program an replace each coil bit with an internal binary bit.

Then, OR all those bits together to produce the output.

This may not work as the author may be relying on the fact that the coil will be in the last state of the last scanned rung. You will have to be careful. Whether this is the case or not, that is poor programming and merits a serious look.

my distinguished colleague Rick has already given you the answer ... here’s just a little more detail on the subject ...



the underlying reason that you’re seeing the “flicker” is because the screen display of the RSLogix5 software is being updated at various random points within the PLC processor’s ladder logic scan ... in other words, you have no control over exactly WHERE in the rung-by-rung scan the screen display “snapshot” is taken ... if the bit/box happens to contain a 1 (status = on) at the precise instant that the screen display is updated, then the “coil” (the OTE instruction) will appear green on your RSLogix5 display screen ... but if the bit/box happens to contain a 0 (status = off) at the precise instant that the screen display is updated, then the “coil” will not be highlighted in green ...



Rick’s suggestion to copy the data to a “buffer” is a good one - and will probably fix all of your problems ... but if for some reason it doesn’t, then you might consider posting your .RSP file so that we can make further suggestions ...



finally ... a note for SLC/MicroLogix/RSLogix500 users ... under normal conditions you won’t see the same “flicker” effect with your systems ... that’s because the screen display for an SLC/MicroLogix/RSLogix500 system is (normally) updated only at the very end of the rung-by-rung ladder scan ... specifically, the “green status” of the screen display will (normally) reflect only the on-or-off status of the last OTE in the ladder logic scan ... it’s important to know that the actual 0 or 1 status of the bit/box MIGHT indeed be changing several times during the scan ... (just like in the PLC-5/RSLogix5 system) ... but ... the annoying “flicker” that we’re discussing in this thread just won’t show up on the display screen ...

Originally posted by Ron Beaufort:

finally ... a note for SLC/MicroLogix/RSLogix500 users ... under normal conditions you won’t see the same “flicker” effect with your systems ... that’s because the screen display for an SLC/MicroLogix/RSLogix500 system is (normally) updated only at the very end of the rung-by-rung ladder scan

Click to expand...

Just so I have this right. This infers that peer to peer comm requests (such as DF1 serial or DH+ request) on the SLC/Micrologix are queued up and only serviced in the housekeeping portion of the scan. Is this correct?

Keith

Ron Beaufort said:

my distinguished colleague Rick has already given you the answer ... here’s just a little more detail on the subject ...



the underlying reason that you’re seeing the “flicker” is because the screen display of the RSLogix5 software is being updated at various random points within the PLC processor’s ladder logic scan ... in other words, you have no control over exactly WHERE in the rung-by-rung scan the screen display “snapshot” is taken ... if the bit/box happens to contain a 1 (status = on) at the precise instant that the screen display is updated, then the “coil” (the OTE instruction) will appear green on your RSLogix5 display screen ... but if the bit/box happens to contain a 0 (status = off) at the precise instant that the screen display is updated, then the “coil” will not be highlighted in green ...

Click to expand...

I appreciate the input..

This was my original thought, that it was simply the way I was viewing it through RSLogix5, but when I saw the same problem on my graphics, it pointed me back to the actual logic execution, and made me think if I went to the processor I would have a bunch of output chatter, but this wasn't the case. So I guess I am still at somewhat of a loss. I will look into the above suggestions, which will take some time, since some of these output coils are reference 20+ times throughout the ladder. Could I simply place an [XIC] reference to the coil, pulling in a memory bit at the END of the ladder?

Once again, thanks for the help.

from Keith:

This infers that peer to peer comm requests (such as DF1 serial or DH+ request) on the SLC/Micrologix are queued up and only serviced in the housekeeping portion of the scan. Is this correct?

Click to expand...

I’m quite sure that it is ... take a look at the SVC (Service Communications) instruction ...



from cntrlfrk:

Could I simply place an [XIC] reference to the coil, pulling in a memory bit at the END of the ladder?

Click to expand...

maybe but maybe not ... whether this would work or not depends on what the original programmer had in mind when he used all of these multiple OTEs ... if there is some underlying reason, then your proposed solution might not work ... if it’s SAFE to do so, you might give it a try ... or consider posting your .RSP file ... we’ll be glad to take a look at it ...



going further ... I mean no offense, but something in the way that you’re wording your posts makes me think that you MIGHT not completely understand the “nuts-and-bolts” of the processor’s “scan routine” ... this is a common (almost universal) issue in the PLC classes that I teach ... may I suggest that you read this post ... you might want to pay particular attention to the paragraph titled "Elaborating on Step 2" ...





preview of major ideas:



(1) an OTE is NOT an “output” ...



(2) an OTE is an “instruction” which tells the processor to manipulate the status of a bit/box in the processor’s memory ... if the OTE is executed with “true” logic, then the processor will place a “1” in the bit/box ... if the OTE is executed with “false” logic, then the processor will place a “0” in the bit/box ... either way, the manipulation of the bit/box happens RIGHT NOW ... specifically, the processor manipulates the 1-or-0 status of the bit/box BEFORE it leaves the OTE’s rung and goes on to the next rung ...



(3) regardless of the 1-or-0 status of the bit/box, the actual output (the field device) is not manipulated until the end of the ladder scan ... specifically, after ALL of the ladder logic rungs have been executed ... more specifically, the bit/box in the processor’s memory may go from 1-to-0-to-1-to-0-to-1, etc. several times while the processor is executing the ladder rungs ... BUT ... the actual output (the field device) will NOT be flickering on and off during the scan ...



... again, it’s quite possible that you have all of these ideas completely nailed down and that I’ve simply misunderstood your comments ... if so, I apologize ... I assure you that I mean no offense ...



finally ... for the purposes of this (PLC-5/RSLogix5) thread, let’s say that if the bit/box in the processor’s memory goes from 1-to-0-to-1-to-0-to-1, etc. several times while the processor is executing the ladder rungs, then the “green highlighted” screen display might indeed flicker on and off in a completely random pattern ...

Originally posted by Ron Beaufort:

I’m quite sure that it is ... take a look at the SVC (Service Communications) instruction ...

Click to expand...

Well, I guess you really do learn something new every day.

Keith