Output should not be active

Jasonkenna

Member
Join Date
Sep 2022
Location
ohio
Posts
4
I am currently working with a machine using rslogix 5000 and have 2 rungs that are not active yet the output is. These are simple rungs with a greater than equation as well as a limit switch input. What could be causing these outputs to be active when they should not be.

20220915_074257.jpg 20220915_074310.jpg
 
Have you done a cross reference on the bits (highlight and right click > Cross Reference or press Ctrl+E) to see that they're not being set somewhere else in the program somehow?

Is this inside an AOI? If it's inside an AOI, have you clicked down to the specific instance using the dropdown menu in the top right of the screen? I'm guessing it's not an AOI because that dropdown isn't visible, but it also looks like Logix is running on a PanelView of some sort.
 
Have you done a cross reference on the bits (highlight and right click > Cross Reference or press Ctrl+E) to see that they're not being set somewhere else in the program somehow?

Is this inside an AOI? If it's inside an AOI, have you clicked down to the specific instance using the dropdown menu in the top right of the screen? I'm guessing it's not an AOI because that dropdown isn't visible, but it also looks like Logix is running on a PanelView of some sort.

Yes this logic is pulled up on a panelview. This is not an AOI.
 
JMP/LBL skipping those rungs
JSR not evaluating True (something disabling JSR for that routine)
TND placed above the rungs somewhere.
 
Is the routine that OTE is in being scanned? Can you toggle it off (Right click, Toggle Bit or CTRL-T)

Yes the routine is being scanned and I am able to toggle it off. I toggled these bits off yesterday and attempted to run another cycle last night but these two OTE's reactivated and locked in again. I never reached the 100psi required for the fault OTE to ever activate even if the limit switch was not engaged.
 
icon9.gif
Output should not be active

The only thing we can agree on is the frowny-face, because a properly functioning PLC cares not a whit what you want it to do or think it should do, but it will mercilessly and inexorably do exactly what you told it to do.

TL;DR

Add four new boolean tags and two rungs:

  • One rung immediately before these two rungs, copying the states of those two outputs at that earlier time to the first two of the new booleans
  • One rung immediately after these two rungs, copying states of those two outputs at that later time the last two of the new booleans
Caching those states at those times will determine whether the two rungs in question are functioning as designed.

It would not hurt to cache the state of the limit switch as well.

P.S. you're not the first, and won't be the last.

P.P.S. it would not matter here*, but are there any forces in place?

* since these are output bit boxes, and I am pretty sure that output forces are applied independent of the program scan, and do not feed back into the program scan's copy of the outputs.
 
Last edited:
Yes the routine is being scanned and I am able to toggle it off. I toggled these bits off yesterday and attempted to run another cycle last night but these two OTE's reactivated and locked in again. I never reached the 100psi required for the fault OTE to ever activate even if the limit switch was not engaged.

If you are able to toggle it leads me to believe the logic isn’t being scanned. Are you certain the routine is being called and there are no jumps?
 
they are the only OTE's in the program for these tags

Are there OTL (Output Latch) instructions for those BOOL tags, instead of Output Examine (OTE) instructions ?

Alarms and Faults are exactly the kind of tags that I frequently use OTL's on, to capture the over-limit condition even after the values are back to nominal.

You almost certainly have not found a mysterious Logix bug.

The most likely explanation is an address conflict. It's possible there is also an HMI writing to those tags, or a Task/Program/Routine execution issue that is not regularly executing those rungs. Also look to be sure someone did not inadvertently create tags with the same name in the Program Scope and in the Controller Scope.

The computer you're looking at is surely a "VersaView", just an ordinary Windows PC in a heavy industrial case with an A-B label on it, rather than a PanelView Plus.

This sort of troubleshooting can be head-scratching, but I still recommend focusing your efforts on the most probable causes, especially another instruction setting those tags true.
 
Add a rung at the beginning of the main ladder OTU Test_Running_Bit


Then above your questionable lines add a rung OTE Test_Running_Bit


If the routine is being called Test_Running_Bit will be on that scan, if it's not on then that routine wasn't called that scan.


The other thought is that the HMI might WRITE to these tags and be toggling them on.
 
can you post up a copy of the program? the best answer comes from the best question, and you only get the best questions if you know where the problem lies in the first place.
 

Similar Topics

I have a project with Factorytalk SE 8.2 and 2 Micrologix 1400. Its basic High, low, and Hi-High level digital inputs in one PLC and 1 output to a...
Replies
2
Views
1,815
Hi. Can someone please help me? My background is computer programming and not PLC's. I was forced into this job at my work because of the slowdown...
Replies
38
Views
30,194
How can I use 1 button and 1 light using only b3
Replies
5
Views
121
Compactlogix controller, program has 28 conveyors that use TON's to start the conveyors. The TT sounds a warning horn during start and the DN...
Replies
6
Views
98
Hello guys, I am new to this forum and have some problems with my PowerFlex755 EENET frequency inverter. I want to do a point to point...
Replies
0
Views
44
Back
Top Bottom