Compact Logix rung stuck?

I'm not trying to fix it, I just want to figure out how it ended up in that state (which is stuck). It shouldn't be possible.

Very possible. As I said earlier, if the PB is turned back on after it turned off by the ONS, but before the next time the ONS rescans, it will stay on.

This demonstrates it.
Turn on bits.3
Turn on HMR_Ro01_Set_PB
Turn off Bits.3
It is stuck.

possible1.jpg
 
I'm not trying to fix it, I just want to figure out how it ended up in that state (which is stuck). It shouldn't be possible.

The first thing I did was see if any of the addresses in that rung were being used somewhere else, and they are not.

The WW has a single script with the line "HMIR_R01_SET_PB = 1;".
The LIM is checking the tag that is on a WW Data Entry field which is limited from 0 to 11.

This PLC has no other communications with anything else and there is just the one WW station that has 4 screens and no back ground type scripts. The WW xrf for that tag is just that one button.

Sorry but I think some of us (including myself) have a tendency to try and solve a problem before seeing what the question really was.

Read KB article 39155. A One-Shot does not work the way you think on first scan. If the PB was high on first scan, then it gets stuck.
 
I don't see that what you explained matters...if the value was outside the LIM the first time the ONS wouldn't be active as the LIM box would be false. Next scan when the LIM was true and the PB still true the ONS would be active. There's no race condition involved with the LIM. Has to be that after the PB OTU it's being turned on again prior to the next scan.

Yes, but if this is happening every scan then what I said holds true. I've seen exactly this issue happen before (although there wasn't a oneshot involved in this case):

MOV 0 DINT_Tag
...
code
...
GRT DINT_Tag 0 OTL BOOL_Tag
...
code
...
MOV 1 DINT_Tag
...
code
...

If you put this into your PLC, and look at the rung with the GRT online, all you'll ever see is a GRT instruction testing "Is 1 greater than 0" and returning false, because your OTL never turns on.

If you MOV your DINT_Tag into another dummy tag right before the GRT is executed, you'll see that what the GRT instruction is actually testing is "is 0 greater than 0", so of course it returns false.

What you see is not always what the PLC sees...
 
Yes, but if this is happening every scan then what I said holds true. I've seen exactly this issue happen before (although there wasn't a oneshot involved in this case):

MOV 0 DINT_Tag
...
code
...
GRT DINT_Tag 0 OTL BOOL_Tag
...
code
...
MOV 1 DINT_Tag
...
code
...

If you put this into your PLC, and look at the rung with the GRT online, all you'll ever see is a GRT instruction testing "Is 1 greater than 0" and returning false, because your OTL never turns on.

If you MOV your DINT_Tag into another dummy tag right before the GRT is executed, you'll see that what the GRT instruction is actually testing is "is 0 greater than 0", so of course it returns false.

What you see is not always what the PLC sees...


Gotcha....I see what you're trying to explain. I was thinking you said it was affecting the logic, but I see now what you were conveying and you're right...I have to teach this to tech's all the time, that the scan is so fast, the value you are seeing is usually the last destructive instance of it in the code, but it may be changing throughout the scan.
 
Read KB article 39155. A One-Shot does not work the way you think on first scan. If the PB was high on first scan, then it gets stuck.

Ding ding ding we have a winner! Here is a quote from that article that explains it.

"When going into RUN mode, during Pre-scan, the storage bit is set to prevent an invalid trigger during the first scan."

They must have had it in program mode, hit the button and realized it was in program mode, then switched it back to run and bam stuck. Time to throw away the PLC key. They have no need to put the thing in program mode.

Thanks all.
 
Ding ding ding we have a winner! Here is a quote from that article that explains it.

"When going into RUN mode, during Pre-scan, the storage bit is set to prevent an invalid trigger during the first scan."

They must have had it in program mode, hit the button and realized it was in program mode, then switched it back to run and bam stuck. Time to throw away the PLC key. They have no need to put the thing in program mode.

Thanks all.

The key isn't the only way the processor can go into program mode....

Hint: Major Fault, reset by any means available ....

So if this is the reason the one-shot has got "stuck", the answer is to use the S:FS bit to clear the HMI interface data, I would do that anyway, always. All HMI commands need to be re-asserted by the operator after a PLC re-start.
 
Also, as daba and others suggested, get rid of the oneshot. It's not required.

The only thing you'll need to check is the functionality - there are two possibilities on how this is supposed to work:

1. Button is pressed, system waits until certain parameters are met (i.e. LIM instruction), and then when they are met, action is taken (i.e. MOV instruction) and button is reset

OR

2. Button is pressed, and as long as certain parameters are met (i.e. LIM instruction), then take action (i.e. MOV instruction) and reset button. If the parameters are not met at the time of button-pressing, no action is taken and the button is reset.

If the required functionality is as per option 1, then just delete the ONS and you're on your way. If it's as per option 2, then move the OTU so it's immediately to the right of the XIC, and delete the ONS.
 
Also, as daba and others suggested, get rid of the oneshot. It's not required.

The only thing you'll need to check is the functionality - there are two possibilities on how this is supposed to work:

1. Button is pressed, system waits until certain parameters are met (i.e. LIM instruction), and then when they are met, action is taken (i.e. MOV instruction) and button is reset

OR

2. Button is pressed, and as long as certain parameters are met (i.e. LIM instruction), then take action (i.e. MOV instruction) and reset button. If the parameters are not met at the time of button-pressing, no action is taken and the button is reset.

If the required functionality is as per option 1, then just delete the ONS and you're on your way. If it's as per option 2, then move the OTU so it's immediately to the right of the XIC, and delete the ONS.

spot-on !

but i would be concerned about option 1 : operator thinks he'd like to do an operation that currently isn't allowed, so he presses the button. 1 minute, hour, week, month, year, etc. later, that request is granted, regardless of what else has happened. I would be very concerned about any system that "remembers" HMI buttons being pressed. IMHO operator interaction must be classed as "real-time"
 
spot-on !

but i would be concerned about option 1 : operator thinks he'd like to do an operation that currently isn't allowed, so he presses the button. 1 minute, hour, week, month, year, etc. later, that request is granted, regardless of what else has happened. I would be very concerned about any system that "remembers" HMI buttons being pressed. IMHO operator interaction must be classed as "real-time"

I agree completely - but since that's the way the functionality currently is, I thought I should at least throw it in there for consideration ;)
 

Similar Topics

gents, I am trying to configure communication with EMERSON PK300 controller through port A1 using generic ethernet communication module . I could...
Replies
0
Views
28
I've blown the Output Transistor on the Output Card of a Compact Logix 1769-L24ER-QBFC1B It says J378. Does anyone know the replacement part...
Replies
3
Views
169
I am having trouble with getting no control of my analog output signal. I am using the SCL function block to control my analog output. The logic...
Replies
11
Views
211
I was wanting to see if anyone had any information on setting up a cub5 meter and getting the data to a Allen bradley PLC. I think i have the set...
Replies
0
Views
113
I had a comms fault between my VFD and Controller (5069-L320ERS2) that started about a month ago and happened maybe once a day to now where it...
Replies
1
Views
247
Back
Top Bottom