Ryan Rose said:
...The logic, when meeting conditions, outputs the cylinder to move in low speed for .35 sec, then kick on high speed until it reaches an approaching destination sensor. Once it has, it drops the high speed output, and remains in slow speed until you've released the pushbutton. What is happening instead, is that it does actuate in low speed, goes into high speed after .35 sec, then stops outputting the low speed output altogether upon reaching the approaching sensor, even though the PB or PanelView PB has remained high.
In the screenshot image, it is shown in the state after which is has stopped, but the PB had remained pressed. Rung 69 is true, B3:5/12 is high, yet O:15/5 is going low and staying there. Would anyone be able to tell me why this is? This functions normally with the original program, which only lacks the parallel input of B3:5/12...
OK, this appears to be a simple but important mistake that you have made...
In your original program you have RUNG 0069 which contains the OTE instruction addressed to output O:15/5. This is the only instance of this OTE/O:15/5 combination in the original program. Once the preconditional logic on RUNG 0069 is TRUE, the OTE instruction will turn ON output O:15/5 as intended and as you have stated is working. Also, as a by the way, output address O:15/5 is assigned to an XIC instruction at the beginning of RUNG 0070. These two are the only instructions in the original program that have the output address O:15/5 assigned to them - the OTE being the more important instruction to consider here.
In your modified program you also have RUNG 0069 which contains the OTE instruction addressed to output O:15/5. You also have the output address O:15/5 assigned to an XIC instruction at the beginning of RUNG 0070. But, the OTE/O:15/5 combination on RUNG 0069 is not the only instance of this combination in the modified program.
Both programs are written entirely in the Ladder 2 routine. The original program has RUNG 0109 as the last rung of logic whereas the modified program has RUNG 0136 as the last rung of logic.
In the modified program, if we look at RUNG 0113, we can see that, from here to the end of the program, you have added new Binary addresses to map directly to certain output addresses. These Binary addresses and rungs do not exist in the original program. Also, I notice these Binary addresses are not used anywhere else in the program at the moment. You may have added this mapping as a means to either manually toggle the Binary addresses to quickly test the outputs, or you may have added them as flags to be later used to trigger the outputs from your modified manual logic, such as RUNG 0069. Whatever the reason, and as a result of adding these rungs, you now have a second instance of an OTE instruction with the output address O:15/5 assigned to it.
This scenario is known as a duplicate output address and is not good practice. It can cause unexpected operations and here is why...
What you must first understand is that the Ladder 2 program logic is continuously and completely being scanned by the processor. With that in mind, it is also important to understand how the OTE instruction is executed...
Each rung that contains the OTE/O:15/5 combination is being scanned. If the preconditional logic before the instruction is TRUE, then the rung-condition-in to the OTE instruction is TRUE and, by design, the OTE instruction will set the output address O:15/5 = 1. This is what you are trying to do on RUNG 0069.
However, what you may not be aware of is the fact that on RUNG 0128 the XIC instruction assigned to address B3:8/15 is also having an effect on the second OTE instruction assigned to address O:15/5.
On RUNG 128 the XIC instruction assigned to B3:8/15 is FALSE, so the rung-condition-in to the OTE instruction assigned to O:15/5 is also FALSE. However, when the preconditional logic to an OTE instruction is FALSE, it does not "do nothing", as you may expect. Instead, and by design, it will set the output address O:15/5 = 0.
So, in a nutshell...
A TRUE precondition to an OTE instruction will set its address = 1
A FALSE precondition to an OTE instruction will set its address = 0
Further...
The output address is not updated until the end of each scan cycle.
Because RUNG 0069 is scanned before RUNG 0128, the output address is first being told to update to "1" at the end of the current scan. But then on RUNG 0128 it is told to update to "0" at the end of the scan cycle, all in the same scan cycle. So the later rung condition wins. At the end of the current scan cycle the output address will be updated to "0".
You should try remove this or all those extra output mapped rungs from the program (0113-0136), and test again. If that turns out to be all that is wrong here, and you do want those rungs back in for some reason, then please explain their purpose and we can help you achieve your goal without causing issues like the above.
Hopefully this is all that is amiss here?
Original - Single Output Instance...
Modified - Duplicate Output Instance...
Regards,
George
