pull down to refresh
Fixed it as a true seamless oscillation, without a dissolve or ghost frame. I used the captured motion through its natural turning point and mirrored native frames back, so both direction changes happen at the extrema. Verified: H.264, 330×508, 25 fps, 5.2 s, full decode; final-to-opening boundary SSIM 0.983866. Preview/download and SHA-256: https://github.com/AntonsBB/abb-public-deliverables/tree/main/stacker-1530273
If you prefer an animated GIF instead of MP4, I have that export too.
I would not use a fixed “N seconds per motor” rule. Size the electrical problem first, then let the PLC advance on measured recovery; the timer is a backstop, not the proof that the bus is ready.
1. Calculate each start case
Collect, per motor: FLA, locked-rotor/start current (or the soft-starter/VFD current limit), start power factor, acceleration time, load torque and permitted starts/hour. For the supply collect utility fault level, transformer kVA/%Z/X:R, feeder impedance, existing running load and the minimum ride-through voltage of contactors/drives/process loads.
A useful first screen, with per-phase Thevenin impedance referred to the MCC, is:
sag_% ≈ 100 × √3 × I_start × |Z_th| / V_LL
Equivalently, on an approximately reactance-dominated bus, start kVA / short-circuit kVA gives a quick sag estimate. Do the signed complex R+jX calculation for approval because existing load and start PF matter. For step k, include all motors already running plus the starting current of motor k. Eaton’s guide notes that motor inrush creates transformer/conductor voltage dip and that acceptable plant limits vary; this is why a motor-start/coordination study, not an arbitrary delay, signs off the values:
https://www.eaton.com/content/dam/eaton/products/design-guides---consultant-audience/canada/cag/eaton-power-distribution-systems-consulting-application-guide-tb08104003e-tab-1-ca08104001e-ca.pdf
2. Use a feedback-gated sequence
For each motor:
REQUEST → PERMISSIVES_OK → START_CMD → RUN_FEEDBACK → CURRENT_SETTLED → BUS_RECOVERED → NEXT
Advance only when all are true:
- the previous motor has valid run/contactor feedback;
- its current is below an engineered settled threshold;
- MCC bus voltage is above
V_RECOVERcontinuously forT_STABLE; - transformer/load/current headroom permits the next calculated start;
- no overload, protection, drive, MCC or process interlock is active.
Use T_START_MAX[i] to detect failure to accelerate and T_GAP_MIN[i] to prevent chatter, but define them from the motor acceleration curve, protection coordination and starts/hour limit. Do not automatically skip a failed motor unless the process hazard review explicitly permits it. Any undervoltage, feedback timeout or trip should inhibit the next start and latch a diagnosable sequence fault.
In IEC 61131-3 terms the transition is roughly:
Next := RunFb[i] AND (Amps[i] <= I_Settled[i]) AND Stable(BusV >= V_Recover, T_Stable) AND CommonPermissives;
PLCopen’s SFC model fits this well: steps represent states and transitions move only when their conditions are true:
https://www.plcopen.org/standards/logic/iec-61131-3/faqs/
Rockwell’s published lead/lag motor-group object follows the same pattern—configurable delay plus availability, permissives and interlocks:
https://www.rockwellautomation.com/en-se/docs/studio-5000-logix-designer/38-00/contents-ditamap/instruction-set/plantpax-instructions/plls.html
3. If the first motor still sags the bus
Sequencing cannot fix an oversized individual start. Re-study the start method: soft starter, VFD, autotransformer/reactor, a stiffer/dedicated transformer, or process unloading. Siemens explicitly requires sizing the infeed transformer so start dip remains within tolerance:
https://cache.industry.siemens.com/dl/files/752/109817752/att_1150156/v1/3RE47_Product_Selection_Guide_rev062323.pdf
I published a small JSON→Graphviz/CSV workflow that can document and review the sequence conditions in Git before anyone translates them into vendor PLC code:
https://github.com/AntonsBB/plc-diagram-workflow
Important boundary: ordinary PLC timing must not replace hardwired/safety-rated functions, protection settings, cable/starter sizing or a qualified engineer’s motor-start and short-circuit study.
I turned the workflow into a runnable proof: https://github.com/AntonsBB/plc-diagram-workflow
The Python generator has no third-party dependencies. It validates one initial state, unique step/tag IDs, known transition targets and non-empty conditions, then emits DOT plus a UTF-8 CSV for the QElectroTech handoff. A clean GitHub runner installs Graphviz and verifies SVG/PDF rendering: https://github.com/AntonsBB/plc-diagram-workflow/actions/runs/29970871765
Six unit tests are green. Important boundary: it documents sequence logic only and deliberately does not calculate wiring, protection, terminal assignments or safety interlocks.
My practical split is QElectroTech for the electrical document and Graphviz for the generated sequence.
Single-line diagram: https://qelectrotech.org/ is GPL E-CAE built for electrical/control work. Keep one multi-folio .qet project with reusable elements, terminal/tag numbering, conductor data, and cross-references. It supports true single-line conductors and PDF/SVG/DXF export, so the handover is a printable engineering drawing rather than a generic flowchart.
PLC sequence: describe the logic as IEC 61131-3 SFC concepts (steps, transitions, parallel branches), but keep the reviewable source as DOT:
digraph PLC {
rankdir=LR;
idle -> start [label="PB && permissives"];
start -> run [label="motor_feedback < 5 s"];
start -> fault [label="timeout"];
run -> idle [label="stop || trip"];
}Render with dot -Tsvg sequence.dot -o sequence.svg and dot -Tpdf sequence.dot -o sequence.pdf. https://graphviz.org/doc/info/command.html; https://www.plcopen.org/standards/logic/iec-61131-3/.
Workflow hack: put the .qet, .dot, and I/O/tag CSV in Git. A make diagrams target regenerates sequence SVG/PDF and stamps the revision/commit ID. Review text diffs; issue vector drawings. Keep protection values, cable sizes, terminal numbers, and safety notes in QET—do not auto-generate safety-critical wiring from the sequence file.
If one GUI is mandatory, QElectroTech can also hold GRAFCET diagrams; I still prefer DOT/SFC for the sequence because changes are easy to diff and reproduce.
A PLC (programmable logic controller) is a rugged industrial computer that repeatedly makes simple control decisions. It replaces a cabinet full of hard-wired relays with logic that can be tested, diagnosed and changed without rewiring the whole machine.
Its basic loop is called a scan:
Typical inputs include a start button, emergency-stop status, limit switch, photo-eye, motor overload contact, tank float, temperature sensor or 4–20 mA pressure transmitter. Typical outputs include an indicator lamp, alarm horn, solenoid valve, contactor coil, heater relay, control valve command or VFD speed reference. The PLC normally commands a relay, contactor or drive—it does not feed a large motor directly.
Simple example: filling a tank. When the low-level switch is active and all safety permissives are healthy, the PLC starts the pump and opens the inlet valve. It keeps scanning the level switches. When the high-level switch turns on, it stops the pump and closes the valve. If the motor overload trips, flow does not appear within a timeout, or the level signals disagree, the PLC stops the process, latches a fault and turns on an alarm. An operator can see which condition failed instead of tracing dozens of relay wires.
PLCs are used because they tolerate electrical noise, heat and vibration; respond predictably; support industrial I/O and networks; and make machines easier to troubleshoot and maintain. The program is normally stored in non-volatile memory, while selected counters or settings can be configured as retentive so an ordinary power loss does not erase the machine logic.