what is causing me plc to going in cycle loop

jg1423 said:

...
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

Click to expand...

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.

DISCLAIMER: this is a press so this must not be implemented without a proper safety review.

A latch-free implementation, for comparison.

Two rungs implement the automated one-cycle business logic, and just over a half-dozen total rungs when integrated with manual mode and the output logic.

The Work/Lower logic rung is busier than I'd hoped and could be simpler, but it is far easier to grok than OP's approach. Also, the extra complexity in that rung is balanced by the Home/Raise logic rung, which is implemented via a trivial, two-instruction Input Map pattern.
_

drbitboy said:

DISCLAIMER: this is a press so this must not be implemented without a proper safety review.
...
The Work/Lower logic rung is busier than I'd hoped and could be simpler, ...

Click to expand...

@Puddle is not the only donut today.

The guts of the business logic, Raise and Lower, can be done in one Start/Stop circuit pattern rung:

• A button press while at home is the Start condition
• Returning to home after extending to timer expiry is the Stop condition;
• .EN is the Run/Seal-in condition;
• .TT replaces the separate Press.Auto.Work bitbox;
• .DN replaces the separate Press.Auto.Home bitbox'
• A reset delays the start of the timer until all cylinders clear home.

Sometimes clarity is more valuable than being clever or concise (code golf).

With that in mind, here an approach to the business logic that is easier-to-understand, yet still far less convoluted than OP's original program.TL;DR

There is one timer Rung 0002 to allow all cylinders to clear their home positions, and a second timer on Rung 0003 to control the work cycle duration once that clearing occurs.

The Work command is the OR of those two timers' .TT bits.

The Home command is the .DN bit of the latter timer.

Now that I think about it, the XIC T4:0/TT on Rung 0002 is not strictly necessary, but if desired it should probably be XIC T4:0/EN., to prevent the first timer from re-starting until the all cylinders return to their home positions.