drbitboy
Lifetime Supporting Member
...
just have one issue with my program where i put it in auto and i flick the switch for it to start its cycle. the 4 cylinder press just goes down for 2.5 sec then comes back up to home postion and then goes back down and keeps doing this till i put it in manual or press the e stop.
...
i [...] attached the project file or maybe attached screen shots to have a better look. the main logic is in the cycle sequence and press logic under OP10A
To answer the query in the OP, the reason that the code, which was attached to the post that started this thread*, keeps cycling is that, after the scan when CYC_COMPLETE is unlatched on Rung 8 (immediately after being latched on Rung 7; see Caveat below), on the next scan the XIO CYC_COMPLETE on Rung 2 will evaluate to True (because CYC_COMPLETE is now 0), which in turn allows the XIC CYCLING seal-in branch of Rung 2 to seal-in the value of 1 in the CYCLING bitbox.
So even though the cycle has completed on the Rung 7 on the previous scan, the multiple unlatches on the subsequent Rung 8 of that previous scan prevents that information (i.e. the cycle is complete), from being available to the current scan. And since CYCLING is still 1 on the current scan and the cylinders are at the home position, another cycle begins.
The immediate fix is probably as simple as adding one more unlatch, i.e. of CYCLING, OTU CYCLING, to that mess'o' unlatches on rung 8.
That said, @jg1423 should instead look at what @parky has written and refactor the logic to be much simpler, robust, and easier to diagnose when something goes wrong (e.g. sensor failure).
* Caveat As noted by @plvlce in post #2 regarding the code OP originally provided, the XIO SEQUENCE.2 on Rung 7 would cause premature latching of a 1 into CYC_COMPLETE, which would prematurely reset the entire sequence on Rung 8, and prevent the cycle from ever getting beyond assigning a value of 1 to SEQUENCE.1. So it seems likely that the document with the screen in post #1 contained a change that OP (@jg1423) made after OP saw the undesired cycling mentioned in Post #1. So the simplest change, which does re-create the cycling problem, is to replace the initial XIO SEQUENCE.2 on Rung 7 with XIC SEQUENCE.2, which makes sense as the value of SEQUENCE.2 remains 0 until the 2.5s timer expires, at which point the cylinders will have cleared their home position sensors, which in turn prevents Rung 7 from latching a 1 int CYC_COMPLETE because, with the cylinders extended, the XIC HOME on Rung 7 will evaluate to False. That will continue to be the case until the cylinders return to the home position and that XIC HOME on Rung 7 evaluates to True, at which point Rung 7's payload OTL CYC_COMPLETE latches a value of 1 into CYC_COMPLETE, which in causes all of the unlatching on Rung 8.
Sidebar: the unlatch of CYC_COMPLETE on one scan also causes Rung 1 to write a 1 into the Ready_To_Cycle bitbox on the next scan, but that has no effect because the button press pulse stretch has long since expired, and the XIC Cycle_Start_Pulse_Stretch.DN in the Start branch of Rung 2 prevents the XIC Ready_To_Cycle in that same branch from making the ORed exit of that branch evaluate to True.