drbitboy
Lifetime Supporting Member
OP
How about this?
Or this?
Understanding scan cycle and rung execution order
- Thread starter drbitboy
- Start date
modiconguy
Member
Brilliant! The jump continued towards infinity.
I found the following in the help file:
Emphasis mine. The jump wasn't conditional because it was set to a boolean output rather than connected to a contact. It looks like the LT is keeping its output energized even though the network is de-energized and the project is set to "don't Maintain output links on disabled Elementary Functions". Seems buggy, but now it works.
drbitboy
Lifetime Supporting Member
OP
Nice find.
Seems weird (i.e. a bug, or at least unexpected) that the jump would happen unconditionally, but the coil will take the hint from the output rung of the [LT] OUT rung and assign a 0 to [LESS] when the [EN] of the [LT] instruction is TRUE even though the result of the [LT] instruction itself is TRUE.
It halts as when it goes to index 13 it jams there for infinite time.
You have NE-instruction before adding.
With value 0 it don't anymore add index on loop and watchdog timer halts PLC.
Control expert ladder behaves differently than FBD-code. I have had problems with trigger contacts on ladder. Trigger output will hold output on even that it should be one scan pulse.
Try indexing with FBD code if it makes difference on PLC.
drbitboy
Lifetime Supporting Member
OP
Yes, he already figured that out. And the solution was to insert a logically unnecesary NO contact between the LT and the jump.
But the question I have is this: why does the jump occur from the LT instruction when the OUT rung, from the LT instruction to the jump (Q2), is FALSE?
The OUT rung of the LT instruction that feeds the jump must be FALSE, because the input rung of the LT instruction is also FALSE, because that LT input rung in turn is fed by the NE instruction output rung which evaluated to FALSE.
That seems like a bug to me, especially when the output rung of the NO instruction, that feeds the Q2 jump on the solution OP came up with, is FALSE, yet it inhibits the jump. But perhaps it is only a feature
.
Last edited:
Only just noticed this post, cannot understand the screenshots, where are the variables ? all I see is what looks like actual values but no symbols is this the way it works in monitoring ?, very weird.
Also, I would have done the compare for the last array as a separate rung after that logic, like you say, perhaps the compare with a jump label as it's output is a bug.
Also, I would have done the compare for the last array as a separate rung after that logic, like you say, perhaps the compare with a jump label as it's output is a bug.
modiconguy
Member
That's what I thought, but I didn't bother mentioning it because the result was the same. The project setting that I think is most relevant applies to all languages.
modiconguy
Member
But the question I have is this: why does the jump occur from the LT instruction when the OUT rung, from the LT instruction to the jump (Q2), is FALSE?
The OUT rung of the LT instruction that feeds the jump must be FALSE, because the input rung of the LT instruction is also FALSE, because that LT input rung in turn is fed by the NE instruction output rung which evaluated to FALSE.
That seems like a bug to me, especially when the output rung of the NO instruction, that feeds the Q2 jump on the solution OP came up with, is FALSE, yet it inhibits the jump. But perhaps it is only a feature
My best guess is that when the HALT occurs the PLC stops updating the diagram. It appears to continue showing the correct values for each variable. I've added a new screenshot that I believe shows the LT is still calling for a jump.
I_Automation
Lifetime Supporting Member
During online monitoring it does not show the tag, but the value of it.
Some platforms show both and this one takes a shortcut.
modiconguy
Member
Yes, the variable names are hidden during monitoring (animation) for integers and floats. In Control Expert you can either hover the cursor on the variable or temporarily disable animation for that section.
I'm still not sure why the LT still energizes the output. Maybe a disabled EF won't de-energize its output links/rungs until the next scan, which never happens due to the jumps? I've added screenshots to show that disabling the EN/LT still works outside of the loop, and to show the discrepancy between the visibly de-energized rung and the energized jump.
I_Automation
Lifetime Supporting Member
It's not the LT command's output, it's regarding this quote:
The LT output doesn't matter because this platform considers it an unconditional jump and jumps whatever the status of the line is.
modiconguy
Member
I think that quote just served as a hint for me to intervene with contacts. My further experiment showed that during the jumps that led to a HALT, the LT will energize anything that's linked to it, even a simple coil. This leads me to believe that because the LT was executed at least once in this scan, its calculated output will be sent out on that rung regardless of its current execution state:
During regular execution outside of any jumps, there's no problem enabling and disabling this EF:
drbitboy
Lifetime Supporting Member
OP
Similar Topics
I'm trying to understand how the PLC will scan this "For" loop.
will the "PhoneNb" variable not increment until all instructions within the "For"...
I am using Allen Bradley PLC for Ethernet/IP communication. I send any explicit msg request (Get attribute or Set attribute), I observed packet...
Took a new job and the controls schemes are fairly old and I'm used to Allen Bradley and Siemens. I'm looking to replace a pair of Superior...
Hello Team, I am desperate for some help with an assessment I have as part of a Level 3 general engineering course. I am in a role that is much...
Good day
is there somewhere i can see the situation and compatibility regarding different firmware revisions.
I have a 2711-K5A5, series H and...