Use a voltage/current condition, not only a fixed delay. A fixed five-second timer may work during commissioning and fail later when the driven load, supply impedance, or acceleration time changes.

First estimate whether each start is acceptable. At the MCC, obtain the available three-phase short-circuit current from the utility study or calculate a first approximation from the transformer:

I_FL(transformer) = S / (sqrt(3) * V_LL)
I_SC(at transformer terminals) ~= I_FL / Z_pu
first-order voltage dip (pu) ~= I_start / I_SC

For example, a 1,000 kVA, 400 V transformer with 6% impedance has about 1,443 A full-load current and 24 kA terminal fault current. A motor drawing 1,800 A while starting would cause roughly 1,800/24,000 = 7.5% dip before adding upstream and cable impedance. Use the motor manufacturer's locked-rotor/current-versus-time curve: DOL starting is often 5-7 times FLA, while a soft starter or VFD changes both the current and acceleration time.

For a better calculation, include transformer, generator/utility, and cable R/X in a motor-starting load-flow study. A simple feeder check is:

Delta V_LL ~= sqrt(3) * I_start * (R*cos(phi) + X*sin(phi))

but starting power factor is low and the existing running motors must also be included. The permitted sag is an engineering requirement, not a universal number; check the utility/transformer limits and the dropout voltage of contactors and controls. A common design target is to keep the transient at the MCC around 10% or less, but that is only a starting criterion.

The PLC sequence I use is:

1. Calculate the preferred order from the study. Starting the largest/highest-inrush motor first often helps because the bus has the least existing load, unless the process dictates another order.
2. Before each start require: bus voltage healthy, no transformer/MCC alarm, no motor trip, permissives true, and no other motor in STARTING state.
3. Issue the start command and start a maximum-acceleration timer.
4. Require auxiliary RUN feedback, then wait until measured current is below a configurable threshold (for example 1.2-1.5 x FLA) continuously for a stabilization dwell such as 2-3 seconds.
5. Only then release the next motor. If RUN feedback never arrives, current stays high, or voltage falls below the limit, abort the sequence and identify the failed motor. Do not blindly skip it unless the process safety study explicitly allows that.

IEC 61131-3 structured-text pseudocode looks like this:

CASE step OF
  READY:
    IF autoStart AND allCommonPermissives THEN step := START_M1; END_IF;

  START_M1:
    cmd[1] := TRUE;
    IF runFb[1] AND amps[1] < 1.30 * fla[1] AND stableFor(1, T#3s) THEN
      step := START_M2;
    ELSIF startTimeout(1) OR busVoltage < minStartVoltage THEN
      cmd[1] := FALSE;
      faultMotor := 1;
      step := ABORTED;
    END_IF;

  START_M2:
    (* same reusable function block for motor 2 *)
END_CASE;

Implement the repeated part as a tested MotorStartStep function block and drive an array of eight motor records (command, run feedback, amps, FLA, timeout, permissive, fault). OpenPLC can run IEC 61131-3 logic for a proof of concept; for the real MCC, use the PLC/vendor toolchain accepted by the plant and test with recorded current and bus-voltage trends.

The maximum start timeout can be based on the motor/load acceleration calculation, t_acc = integral(J * d_omega / accelerating_torque), or more practically on the manufacturer's start curve plus measured commissioning time and a documented margin. Also check starts-per-hour and transformer/motor thermal limits; a sequence that avoids instantaneous sag can still overheat equipment after repeated restarts.

Emergency stops, short-circuit protection, overload protection, and personnel-safety interlocks must remain in safety-rated hardware or a safety PLC. The sequencing PLC coordinates starts; it should not replace the protective system.

For an open-source workflow, I would not force one tool to do both jobs. The most practical combination is:

• QElectroTech for the electrical single-line diagram. It has IEC-style symbols, conductors, cross-references, title blocks, parts lists, and clean PDF/SVG export. It is much faster and less error-prone than drawing an SLD in a generic canvas tool.
• Mermaid or Graphviz for the machine sequence. Keep the sequence as text in Git so a logic change produces a reviewable diff. If the sequence must map directly to PLC code, use SFC/GRAFCET terminology (steps, transitions, actions) rather than a generic flowchart.

My workflow hack is to make a tiny YAML file the source of truth:

states:
  IDLE:  {on: START_AND_SAFE, next: FILL}
  FILL:  {on: LEVEL_HIGH,    next: MIX}
  MIX:   {on: TIMER_DONE,    next: DRAIN}
  DRAIN: {on: LEVEL_LOW,     next: IDLE}

A short Python script can read this and emit Mermaid:

stateDiagram-v2
  IDLE --> FILL: START && SAFE
  FILL --> MIX: LEVEL_HIGH
  MIX --> DRAIN: TIMER_DONE
  DRAIN --> IDLE: LEVEL_LOW

The same YAML can also generate a transition table for the PLC programmer and a commissioning checklist. That is the useful part: the diagram, code review, and test steps all use the same state names instead of being redrawn independently.

For the SLD, create one reusable QElectroTech project template containing the title block, page numbering, standard protection symbols, wire/tag format, and a small set of approved macros (incoming isolator, breaker, motor starter/VFD, 24 VDC supply, PLC I/O). Maintain the tag list in CSV and use the same tags in the PLC project: M101, LSH101, XV101, etc. This makes cross-checking the sequence against the electrical drawing straightforward.

Suggested deliverables are:

1. sequence.yaml - reviewed state/transition data.
2. Generated sequence.mmd or .dot - never hand-edited.
3. installation.qet - authoritative electrical drawing.
4. tags.csv - shared equipment/I/O naming.
5. Exported PDFs committed or released for technicians.

For a one-off job, diagrams.net is quicker, but it becomes painful when tags or sequences change. QElectroTech plus generated Mermaid/Graphviz is a better repeatable workflow. Generated drawings still need an engineer to verify protection, cable sizing, isolation, earthing, interlocks, and the applicable IEC/NFPA rules; the script should remove drafting repetition, not make safety decisions.

A PLC (programmable logic controller) is a rugged industrial computer whose main job is to make the same control decision, predictably, thousands of times a minute. A useful mental model is: sense -> decide -> act -> repeat.

During each scan the PLC normally:

1. Reads its physical inputs into an input image.
2. Executes the control program (ladder logic, structured text, function blocks, etc.).
3. Copies the calculated output image to the physical outputs.
4. Runs diagnostics and communications, then starts the next scan.

A scan often takes only a few milliseconds. Reading all inputs as a snapshot before solving the logic also makes the behavior easier to reason about than a general-purpose program reacting at arbitrary times.

Typical inputs include:

• Digital: a Start button, limit switch, photoelectric sensor, or overload contact (ON/OFF).
• Analog: temperature, pressure, flow, or level, commonly represented as 4-20 mA or 0-10 V.

Typical outputs include:

• Digital: a warning lamp, solenoid valve, contactor, or relay coil.
• Analog: a speed reference for a variable-frequency drive or a valve-position command.

Simple conveyor example: pressing Start does not directly power the motor. The PLC sees the Start input, checks interlocks such as "guard closed," "emergency stop healthy," and "motor not overloaded," then energizes the motor output. A photoeye at the end detects a box; the program can stop the belt, actuate a pneumatic pusher for one second, retract it, and restart the belt. Timers and sequence state make every cycle repeat consistently. If an interlock becomes false, the normal outputs drop to their defined safe state.

PLCs are used because their I/O is electrically isolated, their scan timing is deterministic, they tolerate heat/noise/vibration better than office computers, and technicians can troubleshoot live logic and I/O without rewriting an entire application. One important boundary: personnel-safety functions should use safety-rated relays or a safety PLC and an engineered safety circuit, not ordinary application logic alone.