What would cause this output to stay on?

[tarik1978]

This statement will be always true unless offset is 0
Value > ( Value - offset)

 

[PLCDontUQuitOnMe]

As stated by Steve Bailey, due to the SUB instruction in the branch above, this rung will always be true.



What is possible is that AFTER this rung, something is changing the values of either L_HEIGHT_ADJ_VAL or L_CORE_HEIGHT_MIN and that is the value you are seeing through your software, however at the time this rung executes, the actual values are different.


Try this: Add another branch directly below the problem rung and use two MOV instructions to move the values of L_HEIGHT_ADJ_VAL and L_CORE_HEIGHT_MIN into two separate new registers and look at the values (these will be the values that were in these registers when this branch executed). The values you see might be different due to the way the software displays register values on your computer.


Also check if L_HEIGHT_ADJ_VAL and L_CORE_HEIGHT_MIN are being modified anywhere else in the program after this rung.

 

[plvlce]

Steve Bailey is correct regarding the SUB instruction resulting in the OTEs always being true unless the deviation is <= 0. The SUB enforces that the GRT will always see the minimum as (value - deviation) since it is run immediately prior.

Remember -- the values you currently see are not necessarily the values present at the time a rung is examined, especially if they are used elsewhere.

The fact that the left-hand rail is not green makes me suspect the rung is not being currently run, however (unless the screencap was taken while offline).

 

[dmroeder]

The key to this puzzle is what PLCDontUQuitOnMe mentions, set aside what values LogixDesigner is showing you for a second and just focus on exactly what that SUB box is doing.

 

[Operaghost]

The key to this puzzle is what PLCDontUQuitOnMe mentions, set aside what values LogixDesigner is showing you for a second and just focus on exactly what that SUB box is doing.

It comes down to what was L_HEIGHT_ADJ_VAL at the point in the scan where the PLC was evaluating that particular GRT instruction.

Solve the math yourself by hand. Pick a value for L_HEIGHT_ADJ_VAL. Say 5000. Let's stick with 30 as the deviation. Do the ADD and the SUB. After those two instructions and before we move to the next level of the branch you would have the following values.

L_HEIGHT_ADJ_VAL = 5000
CORE_HEIGHT_DEVIATION = 30
L_CORE_HEIGHT_MAX = 5030
L_CORE_HEIGHT_MIN = 4970

Now when you execute the bottom branch, 5000 is greater than 4970 so the two outputs energize. No matter what happens with that tag, this will always be true because of the ADD and SUB above it.

At some point elsewhere in the logic any of those values might be changed. That is why looking at the screen and seeing the values displayed can be misleading. It isn't "what you see", it's what the PLC sees at that point in the scan.

On the next scan, when the PLC scans that rung of code, it will redo the calculation, and evaluate as true. It will always evaluate as true.

OG

 

[MikeyN]

It doesn't matter what the values are right after that rung is scanned. As long as CORE_HEIGHT_DEVIATION is 1 or greater, the two OTEs will always be true. The program is taking the adjusted value and subtracting 30 and then immediately evaluating if the adjust value is greater than adjusted value minus 30. Of course it is, it just subtracted 30 guaranteeing that it will be greater.

What should probably be in the SUB instruction, and the ADD for that matter, is a recipe setpoint of some kind that isn't tied to the adjusted value. Setpoint +/- 30, then compare the adjusted value to the setpoint min and setpoint max. This should allow the adjusted value to be evaluated properly.

 

[Steve Bailey]

Immediately before evaluating the GRT instruction, the PLC subtracts the value in CORE_HEIGHT_DEVIATION from the value in L_HEIGHT_ADJ_VALUE and puts the result in L_CORE_HEIGHT_MIN. In other words, L_HEIGHT_ADJ_VALUE - CORE_HEIGHT_DEVIATION = L_CORE_HEIGHT_MIN.

Then the GRT instruction checks for L_HEIGHT_ADJ_VALUE greater than L_CORE_HEIGHT_MIN. As long as L_HEIGHT_ADJ_VALUE and CORE_HEIGHT_DEVIATION are both positive, the comparison will always evaluate true.

 

[GaryS]

The output may be used somelace else in the program
do a cross referance on them to see
always keep in mind the the ladder display will show the state of the bits no matter where they are set or reset
I don't know where the JSR falls into this i didn't see it anyplace in th origenal post

 

[drbitboy]

Restating what others have already said: understanding PLCs is all about time; left to right, top to bottom in time; values displayed in online mode are a series of snapshots at discrete times, but we must never forget that those sampled-for-display values may have little or nothing to do with what the values were at the time the instructions executed.

Analogy

Check this out: https://youtu.be/qCm0uKgQxvc?t=150; that was in the fourteenth minute of play, when the score went from one-nil to two-nil, and Liverpool was winning*. This is analogous to the middle of the scan, when the output values were assigned based on the "score."

But then look at this: https://youtu.be/qCm0uKgQxvc?t=772; ouch. This is analogous to the end of the scan, when the outputs and integers (scores) were sampled for display.

* OT Sidebar: Gosh but I love watching Mo Salah play: doesn't get the initial pass as the play develops, but still puts his head down on the minuscule chance the keeper makes a mistake, and is rewarded for that.

 

[TheWaterboy]

Trending the values might be revealing. Like bit says - the values on screen are sampled, not realtime.

 

[JTCat]

You either have duplicate destructive bits causing this (cross reference to find out) or you need to break up that a separate rung or make it an AOI to ensure that the math that you are attempting to accomplish is executed in the correct order.

When you branch things like that things don't always read left to right, top to bottom.

 

[Lare]

if you add allways zero contact between GRT and OK bits, is OK_bits still at true state after that test?
(Which would indicate double coil syndrome)

 

[lostcontrol]

Restating what others have already said:
understanding PLCs is all about time; left to right, top to bottom in

Not related to the topic , but can I poke this & say, that 90% of PLC's follow this concept
I believe the modicon 984 series was different...

 

[alive15]

This is a long shot, but once I had a C-more HMI writing to a DINT tag, while at the same time, the PLC logic was adding/subtracting to the tag. If you have an HMI which can modify tag values, check its program.

Also as others have mentioned, trending the tag will provide more clues; if your graph keeps jumping up and down, then something else is writing to the tag simultaneously.

 

[zachary.wilson]

Howdy,
Doesn't seem like something is processing correctly, in the rung above your ote, it is doing the math but if you look at what it is saying the math is, it doesn't add up. like steve bailey said, it will always be true, because you are looking at the L adj value and subtracting 30 from it, and placing that in the L core height min. then immediately after that looking to see if the L adj value is above the core height, which it should always be 30 above it. based off the math you just told it to do.
But from your screen shot it isn't showing those numbers. the math goes wrong after you go from your L_height_mm to L_height_adj value. the 338 plus 3770 is 4108 which makes the rest of the math right, and would make the GRT true and your bits happy. Is it possible your raw data is flickering between two numbers faster than the screen can update, but is still processing it, so you see one set of numbers/data but it is actually two different?
Couple ways to test this is but an always off after the GRT and if the OTEs turn off and stay off then you know it isn't pulled from somewhere else. also if you put a counter after the GRT, everytime it swaps it would count up.

Just a couple suggestions, also it should have the green bar on the side of the ladders which seems odd they arent there. Hope some of this helps.