RSLogix 500 weirdness

I've seen a lot of strange happenings in Rockwell Software. Some of the time I can hammer away at the issue until I solve the problem. The rest of the time, I rely on the experience of the great people that make up this forum. This is one of those times.

Our press has been displaying an alarm state on its beacon, but no message appears on the HMI to indicate which alarm is tripped. I started digging through the program to see which one of the 80 possible alarms is causing the trouble. As it turns out, the beacon is tripped by a bit in the program that is true when any of the 5 integer files for the alarms is not equal to 0.

This is where it gets strange... None of the preceding logic in the rung is true, and yet the output bit is true. The press is not in a shutdown condition, which makes sense because there is no actual alarm. But how can an output be true if the inputs are all false? There are two XICs, two XIOs, and one OTE attached to this bit, so it isn't getting activated elsewhere in the program. There are no MOV instructions or anything like that associated with this bit at all, and under "usage" there is no indication of FW.

This is on a 1747-L541C 5/04 processor OS401 Series C FRN 3-8, running RSLogix 500 V9 CPR 9. I have attached an image of the offending rung. The test bit was just inserted to make sure I wasn't going insane and seeing something that wasn't there.

Is it possible that the routine which this logic resides in is not currently being scanned? Something preceding its JSR?

Or another possibility is a JMP/LBL causing the logic not to be scanned.

I finally found the culprit. N28:2 was not actually equal to 0. We have a low lube level warning. The OTE for N28:2/2 should have been energized, but it didn't show energized. I had to force the input on and then back off again to get the output to energize. In this image the OTE is okay, but initially the XIO was green and the timer was finished which activated T21:20.DN, but the OTE was not energized. This is still the same weird kind of issue, just in a different part of the program.

dmroeder said:

Is it possible that the routine which this logic resides in is not currently being scanned? Something preceding its JSR?

Or another possibility is a JMP/LBL causing the logic not to be scanned.

Click to expand...

We run all of our JSRs on one rung with no activating conditions, and there are no JMP/LBLs in the program, but that was a great suggestion that I hadn't considered!

Crisis averted for now, thank you very much. What ever will we do if Rockwell manages to release a program with no bugs? I might actually grow some hair back.

The fact that the test bit goes true suggests that the logic is being solved.

I'd bet a box of shiny metal donuts that there is logic that writes zeroes to N28:0-4 elsewhere in the program. They're nonzero at the time this rung is scanned, but zero so quickly thereafter that you can't see the transition.

Like this: N28:0 is definitely = 128 at the time the rung is scanned, but you still see zero in the register when you monitor it.

What ever will we do if Rockwell manages to release a program with no bugs?

Click to expand...

Nothing you have posted suggests that there's anything wrong with the SLC operating system or RSLogix 500. Somebody went fussing with your system and forced an Input off to bypass an alarm condition.

Edit: I should have been so snippy. I like to latch my alarm conditions and timestamp them if possible for exactly this reason.

One thing that's counterintuitive in RSLogix 500 is that forcing an I/O point doesn't necessarily make all the instructions referencing that point show the Forced condition. I admit that's hard to troubleshoot, but it's not a bug.

Best way to trouble-shoot that is to add a COP on the output branch and copy those words to some unused words and see which one is the culprit.

Alarms shod be a latch or set as some languages would call them
that way the you can trouble shoot the alarm and reset it when it's clear.

Ken, you were correct about something setting the integer files to 0. It was not obvious at all, and it wasn't even directly in the PLC. A message was sent back from the PanelView to set the integer files back to 0 using a reset button on the screen. This button was supposed to have been disabled or removed on all of the presses 6 or 7 years back because it never worked, but I guess that press was overlooked. One of the operators found it on a buried screen and got curious about it. It has been removed, and now I am going to redo all of the alarms. Thank you very much for your insight, all is well with the world again.

What does the alarm reset logic look like? If the alarm reset is before the logic to trigger the alarm, then you may have a scan cycle issue where the integer is being reset automatically and just giving a flash. I've seen similar issues before where execution order was the culprit.

edit: nevermind, just seen your reply Mikey I need my coffee this morning

Looks clear to me the lube oil is dropping setting the alar then going backup the resetting the alarm. but when the alarm is set the PV reads the alarm and post it but when you look the alarm in cleared.
that's who alarms should always be a latch bit you would then know where to look
the alarm message in the PV should also tell the operator what happening and where to look to correct the problem.

Gary, the lube level was low enough that the input was constantly on. When the PanelView set the integer file to zero, it latched a reset function that constantly set the bit back to 0. It was happening every scan cycle, so I couldn't see the active alarm anymore.

It's all good now, I am going through and rebuilding most of these systems anyway. Just another little quirk in the logic that needs repaired. All of the systems that I have built or rebuilt for our plant have had latching alarms for this exact reason.

This might be a little OT, but I have come to realize that a lot of our troubleshooting problems stem from old programming habits. The older gentlemen that programmed these machines (retired for nearly two decades now) were used to programming PLC5s with little memory. As a result, I am often seeing little work-arounds such as this means of resetting the alarms, or using one integer file to handle hundreds of compute functions. It has been really fun, if a little frustrating, taking a step back in time and seeing the difference between programming styles. I am enjoying the challenge, and am now incredibly thankful for the resources available to me that the other gentlemen didn't have access to back in the day.

Thank you all so much for all of the help.

Mikey
I have been programming since SCL100 then PLC2 PLC3 PLC5 and yes they had memory limitation to consider. you learn to work around them.
But all alarms should be latched either latched output or held in with a keeper.
the reset should be cleared (reset) at the end of one scan or use a momentary from the HMI.