Restoring Interroll MultiControl Start After Power Cycle

A zone that runs perfectly until the first power interruption, then sits dead with a valid speed byte in its output image, is a state-machine problem, not a motor problem. The MultiControl BI has come back up in a state where it will accept the speed value but will not act on it, and the PLC is holding a start command that the MultiControl never saw arrive. Nudging the roller by hand feeds rotation back into the controller and knocks it out of that state - which is a diagnostic clue, not a fix.

Fault Isolation Before Changing Any Setting

Before anything else, confirm what the MultiControl itself thinks its state is. The PLC output image proves only that the PLC wrote a number; it says nothing about whether the drive channel is enabled.

1. Open the MultiControl web server on the unit and go to the diagnostics/error view. Read the current state of each RollerDrive channel and the stored error list. A latched entry there explains the no-start immediately.
2. Check the RollerDrive type configured for each of the four connections. An EC5000 on a channel configured for a different drive type will accept a speed setpoint and never commutate.
3. Measure the 24 V supply at the MultiControl terminals during the restart, not at the power supply. Multiple RollerDrives inrushing together can drag the rail below the undervoltage threshold long enough for every controller in the string to latch a supply fault.
4. Watch the fieldbus connection indication. Note how long after power-up the PLC connection actually establishes - this is the window in which your PLC is writing commands into nothing.
5. Note whether the nudge is needed on every start or only on the first start after a power cycle. Only-after-power-cycle points at the connection handshake. Every-start points at mechanical load or drive configuration.

Do not move on until you know which of those two the symptom is. The rest of the procedure assumes the power-cycle-only case.

Three Recovery Approaches Compared

There are three ways people attack this, and they do not fix the same thing.

The first approach is worth checking once - if the General Control Error is configured as an error requiring reset, change it and retest. If it is already set to Ignore, the latch is not there and further web-server changes are wasted time. The third approach is the one that makes power cycles a non-event, and it is what to build.

Enable Edges, Connection State, and Why the Nudge Works

In the universal full process image, each RollerDrive connection gets its own control and status bytes. The speed setpoint is data; the drive only turns it into torque when the channel is enabled and the controller reports the drive ready. Those are independent - a valid setpoint sitting in a disabled channel produces exactly the symptom described: correct value at the output, no rotation.

When the field supply drops, the MultiControl loses power and its RollerDrive outputs de-energize. The PLC, on a separate supply, keeps scanning and keeps holding the start bit high. When the MultiControl powers back up and the cyclic connection re-establishes, it starts from a stopped internal state and receives a control byte that has been high the whole time. There is no transition for it to act on. The channel stays where it came up: stopped.

The manual nudge injects rotation the controller can see on the drive's feedback. That rotation drives the internal state out of its stopped condition, the enable is applied against the setpoint already present, and the roller carries on. It looks like the drive "found its position"; what actually happened is that the state machine was forced to move because the PLC never gave it an edge.

The same mechanism explains why the unit never reaches an "okay" state on its own: nothing in the sequence ever asks it to. Suppressing errors does not create the enable transition.

Connection-Gated Start Handshake

Build this once as an AOI or function block and instantiate it per MultiControl. The rule is simple: no command leaves the PLC until the MultiControl says it is connected, and every reconnection produces a fresh enable edge.

1. Map the MultiControl input image so the connection/status bits are available as named tags, not just raw bytes. Verify by pulling the network cable - the connection tag must drop.
2. Latch a Connected bit from the fieldbus connection status plus the per-channel ready indication. Require both before any output is written.
3. Gate all control-byte writes with Connected. While it is false, write zeros to the control byte and the speed byte for that channel. Do not park a non-zero setpoint in the image.
4. Detect the rising edge of Connected (one-shot). On that edge, hold the start/enable bit low for a defined settle period - a few hundred milliseconds is enough for the controller to finish its own initialization - then release the HMI start command through to the control byte.
5. Pulse the error-reset bit in the control byte on that same reconnection one-shot, before enabling. This clears anything latched during the outage without an operator touching the HMI.
6. Feed the MultiControl's error/warning status back to the HMI as a displayed state, not as an interlock the operator has to acknowledge before the line will run.

With the gate in place, the PLC start bit at the MultiControl is guaranteed to go low then high after every power event, regardless of what the operator left the HMI button in.

Verification

1. Start the zone normally and confirm all rollers run in the commanded direction at the commanded speed.
2. Leave the HMI start command active. Pull the field supply to the MultiControl while the rollers are running.
3. Restore power without touching the HMI. Trend the Connected tag, the control byte, and the speed byte together - the control byte must show a clean low-to-high transition after Connected goes true, not before.
4. Confirm all rollers resume without a manual nudge. If one channel stays dead while others recover, that channel has a drive-specific error - go back to the web server error list for that connection.
5. Repeat the power cycle three times, including one interruption during acceleration and one while the zone is stopped but enabled. Recovery must be identical each time.
6. Read the MultiControl error list after the third cycle. It should be clear, or contain only the expected supply-loss entries with no latched state - that reading is the pass criterion.

Recurring Pitfalls on MultiControl BI Installations

Suppressing the wrong event is the most common wasted afternoon. Setting General Control Error to Ignore is a legitimate step when that event is latching the unit, but it hides genuine communication faults afterward. Verify the setting, and if it was already permissive, put it back the way you found it and move to the PLC side.

Shared 24 V between the MultiControl logic and the RollerDrive power is the second. If logic and motor power come off the same rail and the rail sags on restart, the controller can boot and fault repeatedly before the PLC connection ever establishes, and the error list will show a string of entries with no obvious trigger. Separate the rails or size for the combined inrush of every drive on the string.

Third: leaving a non-zero speed value in the output image while disconnected. Some restart sequences apply the stale setpoint the instant the connection comes up, before the PLC has finished its own reconnection logic - a zone that lurches on power-up instead of staying dead is the same handshake defect with the opposite symptom.

Fourth: assuming the four connections on one MultiControl behave as a unit. Each RollerDrive connection has its own status and its own error state. Gate and reset them individually, or one faulted drive will keep three healthy ones idle.

FAQ