Can a CLICK PLC Control Optidrive E2 or Commander SK?

A CLICK PLC can command an Invertek Optidrive E2 or Emerson Commander SK through Modbus only when the selected PLC interface and drive share the same Modbus transport, electrical layer, and client/server roles. Confirm those points from the current manuals before purchasing hardware. The evidence names the products and intended protocol but gives no connector, register address, baud rate, or PLC model.

Where does the Modbus request travel?

Follow the packet. The PLC control routine creates a read or write request. The PLC communications interface transmits it across the physical link. The drive communications processor validates the destination, interprets the requested register, and passes an accepted command to the drive control state machine. A response then follows the same path back to the PLC.

Layer one first. A correct register map cannot compensate for the wrong interface, reversed conductors, an incorrect pinout, missing biasing or termination, or an Ethernet/serial mismatch.

How do the two drive choices compare?

Both candidates require the same compatibility investigation. Product name alone does not establish that a particular unit has Modbus fitted, that it uses the PLC's available physical interface, or that its command registers are writable in the installed configuration.

Do not transfer register addresses or parameter meanings between the drives. Even when both implement Modbus, their control words, status words, scaling, writable ranges, and fault behavior can differ.

Which drive and PLC arrangement should you select?

Select the combination whose current manuals establish all four interfaces: physical transport, Modbus role, register map, and drive control-source configuration. Reject a combination if any required interface depends on an undocumented adapter or unavailable option.

Before ordering, build a one-page interface schedule containing:

• The exact CLICK CPU and communications interface.
• The exact drive model and installed communications option, if one is required.
• The physical connector, pinout, cable type, shield arrangement, and termination requirements.
• The drive address and every applicable serial or Ethernet setting.
• The registers for status, fault state, command, and speed or frequency reference.
• The data type, signedness, scaling, byte order, word order, and read/write permission for each value.
• The drive parameters that select communications as the command and reference source.
• The required behavior after a communications timeout or PLC stop.

The preferable drive is the one with a complete register map and a testable loss-of-communications response for the intended machine. Example code can shorten development, but it does not replace validation against the exact PLC and drive manuals.

How should the physical and protocol settings be configured?

1. Identify the drive's actual communications interface from its label, installed options, and manual. Determine whether it is serial Modbus or Modbus over Ethernet; do not infer the transport from the word “Modbus.”
2. Confirm that the selected CLICK hardware supplies the matching interface and can initiate requests as the Modbus client/master.
3. Wire the documented connector and pinout. Apply the cable, shield, grounding, biasing, and termination instructions for that physical layer.
4. Assign a unique drive node or unit address. Record it in the interface schedule rather than relying on a commissioning laptop's temporary settings.
5. For a serial link, match baud rate, parity, data format, and stop-bit configuration. For an Ethernet link, match the addressing and port settings specified by the device manuals.
6. Set the PLC request timeout and retry behavior so one disconnected drive cannot stall the control task. Use values appropriate to the required update rate and the number of transactions; read permitted ranges from the device documentation.
7. Test a documented read-only status register before issuing any command. A successful read separates basic communications from drive-control configuration.

If the first read fails, inspect transmit and receive activity at each hop. A request with no response points toward wiring, addressing, framing, interface selection, or a drive that is not listening. An exception response points toward the requested address, access type, or function. A valid but implausible value points toward offset convention, data type, scaling, or byte and word order.

How should command and reference registers be mapped?

Separate communication health from motion authority. First read identity or status data. Then read drive state and fault information. Only after those reads are stable should the PLC write command and reference data.

Read documented status value
If the reply is valid:
    Decode drive-ready, running, and fault states from the manual
    Write the documented reference value with documented scaling
    Write the documented command value
Else:
    Inhibit new commands
    Apply the machine's communication-failure state

Check whether the PLC software uses zero-based or one-based register notation and compare that convention with the drive manual. An offset error commonly produces legal replies from the wrong register. For values spanning multiple registers, confirm word order as well as byte order.

Set the drive's command source and reference source explicitly. A drive can reply correctly to reads while ignoring writes because keypad or terminal control remains selected. Retain any required hardwired permissive, protective, or safety-rated circuit; ordinary Modbus commands are not a substitute for a safety function.

How do you verify control and failure behavior?

1. With run commands inhibited, read the chosen status and fault values repeatedly. Record request success, response stability, and observed update time.
2. Change one harmless, observable drive state and confirm that the corresponding status indication changes in the PLC.
3. Write a low reference value using the documented scaling, then read back the applicable reference or monitor value where the drive provides one.
4. Apply all machine permissives and issue a controlled run command. Confirm that commanded direction, reference, drive status, and actual machine response agree.
5. Remove the run command and verify the documented stop behavior.
6. Interrupt the communications path and confirm the configured timeout response, PLC alarm, command inhibition, and recovery sequence.
7. Restore communication without automatically restarting hazardous motion. Require the intended reset or start sequence, then repeat the read-write-read test.

Do not accept a test that proves only that packets move. Acceptance requires correct scaling, correct control-source selection, predictable loss-of-link behavior, and agreement between PLC state, drive state, and physical motion.

Frequently asked questions