The key point is: do not choose eight arbitrary fixed delays. A timer-only sequence can start the next motor while the previous one is still accelerating or while the bus has not recovered. Use a calculated delay as the initial value, but advance on measured voltage/current and starter feedback.

1. Do a motor-starting screen first1. Do a motor-starting screen first

For each motor, get these from the motor/starter/VFD data:

• rated current I_FLA
• locked-rotor or starting-current multiplier
• expected acceleration time at the real load torque
• allowed starts per hour / minimum restart time
• starter type: DOL, star-delta, soft starter, VFD, autotransformer

A useful first-pass calculation is:

I_start = I_FLA × starting-current multiplier
S_start = √3 × V_LL × I_start
ΔV_pu ≈ |Z_source_pu| × I_start_pu

Put utility, transformer and feeder impedance on the same base in Z_source_pu. For a transformer-only rough screen, its nameplate Z% supplies that component. This is only a magnitude estimate; the final check should be a phasor motor-start/load-flow study including the already-running motors and cable impedance.

The actual relationship is essentially:

V_MCC = V_source − I_start × (Z_utility + Z_transformer + Z_feeder)

Use the transformer/MCC/contactor/VFD manufacturer limits and the utility's permitted dip/flicker limits—there is no universal “5-second formula.”

2. Sequence on recovery, not just elapsed time2. Sequence on recovery, not just elapsed time

A practical step time is:

T_gap(i) = T_accel(i) + T_voltage_recovery + engineering margin

But the PLC should start motor i+1 only after all of these have remained true for a settling time:

• motor i has RUN_FB
• its current has fallen below a commissioned I_SETTLED(i)
• MCC bus voltage has recovered above V_RECOVER
• no overload, starter, process or safety fault exists
• the next motor's permissives and minimum off-time are satisfied

Also use a separate T_START_MAX(i). If RUN_FB is not obtained before that timeout, stop the sequence and alarm; do not blindly continue.

Conceptual state machine:

READY:
  if AUTO and all permissives and Vbus >= V_START:
      command motor[i]
      go to WAIT_RUN

WAIT_RUN:
  if trip or Vbus < V_ABORT: go to FAULT
  if start timeout:          go to FAULT
  if RUN_FB[i]:              go to WAIT_SETTLE

WAIT_SETTLE:
  stable = RUN_FB[i]
           and I_motor[i] <= I_SETTLED[i]
           and Vbus >= V_RECOVER

  if stable continuously for T_SETTLE:
      if i < 8: i := i + 1; go to READY
      else: go to ALL_RUNNING

FAULT:
  inhibit automatic restart, preserve the first-fault cause,
  and require the site's defined reset/recovery procedure

Previously started motor commands remain on as the index advances. Add a single-start mutex so two commands cannot transition on the same PLC scan. Often the largest/hardest-starting motor is started while the bus is least loaded, but process constraints and the study should decide the order.

3. Know what sequencing cannot solve3. Know what sequencing cannot solve

Sequencing prevents overlapping inrush. It does not reduce the dip caused by one motor. If any single DOL start is unacceptable, use a properly selected soft starter, VFD, star-delta/autotransformer starter, larger transformer/feeder, or another engineered reduced-voltage method. Reduced voltage also reduces starting torque, so verify the load can accelerate.

For open-source prototyping, this state machine maps cleanly to IEC 61131-3 Structured Text or SFC in https://autonomylogic.com/about; its current ST documentation includes CASE, timers and time literals. I would simulate the order and faults there, then implement and validate it in the production PLC/vendor toolchain.

Useful manufacturer references: https://library.e.abb.com/public/619009ca06434972a40b3479a1ed3c69/AP_Apparecchi-manovra-MT%28EN%29C_1VCP000735.pdf and 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.

For an eight-heavy-motor MCC, this logic must be reviewed against the short-circuit, coordination, motor thermal/acceleration and arc-flash studies by the responsible electrical/control engineer. Pneumatic timing alone is not a good primary solution because it cannot see bus recovery or electrical faults.

A PLC is a rugged industrial computer that repeatedly turns field conditions into controlled actions. Unlike a normal PC, it is designed for electrical noise, vibration, temperature changes, 24/7 operation and predictable timing.

A simplified PLC scan looks like this:

1. Read inputs and copy their states into an input image/table.
2. Execute the program (ladder logic, function blocks, structured text, etc.).
3. Write the calculated output states to the output modules.
4. Run communications/diagnostics and repeat—typically every few milliseconds.

That repetition is important: the PLC is not “running a script once”; it is continually asking, “What is true now, and what should the machine do next?”

Typical inputs

• Digital: Start/Stop buttons, limit switches, photoeyes, proximity sensors, overload contacts, low/high level switches.
• Analog: 4–20 mA pressure/flow/level transmitters, temperature sensors through a transmitter, 0–10 V signals.
• Networked data: a VFD’s speed/current/fault status or measurements from remote I/O.

Typical outputs

• Digital: indicator lamps, alarms, contactor coils and solenoid valves.
• Analog: a speed reference for a VFD or position reference for a control valve.
• Network commands: start/stop and setpoints sent to drives or other controllers.

The PLC output normally controls a contactor, relay, VFD or valve interface; it does not power a large motor directly.

Simple example: automatic tank fillingSimple example: automatic tank filling

Inputs:

• LOW_LEVEL: tank needs water
• HIGH_LEVEL: tank is full
• OVERLOAD: pump protection has tripped
• SAFETY_OK: safety circuit is healthy

Output:

• PUMP_CMD: command to the motor starter/VFD

Easy-to-read equivalent logic:

IF (NOT SAFETY_OK) OR OVERLOAD OR HIGH_LEVEL:
    PUMP_CMD := OFF
ELSE IF LOW_LEVEL:
    PUMP_CMD := ON
ELSE:
    keep the previous PUMP_CMD state

So the pump starts at the low-level point, stays on while the tank fills, and stops at the high-level point or immediately on a protection/safety fault. The PLC can also timestamp faults, show tank status on an HMI and alert an operator.

PLCs are used because the same behavior would require many relays and much more wiring. Logic can be changed without rebuilding the whole panel, I/O is modular, faults can be diagnosed online, and the cycle is deterministic enough for industrial sequencing.

One important boundary: a normal PLC program should not be the only emergency-stop layer. Safety functions should be hardwired through approved devices or implemented in a safety-rated PLC according to the required risk assessment.

My practical stack would be QElectroTech for the issued electrical drawing and Graphviz for the generated operating sequence. Trying to make one tool do both usually makes the result harder to maintain.

1. In QElectroTech, create one single-line folio and one control/GRAFCET folio. Use a reusable IEC symbol collection and title block, and keep the same equipment tags everywhere (QF1, KM1, M1, etc.). QET projects already group folios, elements, conductors, cross-references and reports; a folio also maps cleanly to a page when exporting PDF. Export the parts/nomenclature CSV as a simple QA check.
2. Keep the PLC sequence as text in Git and render it automatically. Example steps.csv:

step,label,next,condition
S0,Idle,S1,START and E-stop OK
S1,Start M1,S2,M1 aux and 3 s elapsed
S2,Start M2,S0,STOP or fault

Minimal dependency-free generator:

# seq2dot.py
import csv, sys

def esc(s):
    return s.replace("\\", "\\\\").replace('"', '\\"')

with open(sys.argv[1], newline="", encoding="utf-8") as f:
    rows = list(csv.DictReader(f))

print('digraph plc { rankdir=LR; node [shape=box, style=rounded];')
for r in rows:
    label = f'{r["step"]}: {r["label"]}'
    print(f'  "{esc(r["step"])}" [label="{esc(label)}"];')
for r in rows:
    print(f'  "{esc(r["step"])}" -> "{esc(r["next"])}" '
          f'[label="{esc(r["condition"])}"];')
print("}")

Render it with:

python seq2dot.py steps.csv > sequence.dot
dot -Tsvg sequence.dot -o sequence.svg

Graphviz dot is a good fit here because it lays out directed sequences hierarchically and produces reviewable SVG. QElectroTech is the better place for the final single-line/control sheets, conductor numbering and PDF package.

Workflow hack: use the exact same device tags in the CSV and QET project, regenerate the SVG in CI, and ship .qet, .csv, .dot, SVG and PDF together. A sequence change then appears as a small text diff instead of a redraw. I would avoid generating QET XML directly unless the QET version is pinned; the format is XML, but the GUI should remain the authority for the electrical drawing.

Official references: https://download.qelectrotech.org/qet/manuals/html/users/project/what_is.html, https://download.qelectrotech.org/qet/manuals/html/users/folio/index.html, https://graphviz.org/doc/info/command.html.

For a real installation, the generated diagram is documentation—not a substitute for checking fault current, protection/selectivity, cable sizing, interlocks and local-code compliance by a qualified engineer.