Introduction
On a factory floor, more than 90% of automated machines take their orders from one box: the PLC. It reads sensors, runs the logic, and tells every actuator what to do. If you want a SOLO drive to run a conveyor, a pump, or an axis, the real question is simple. How do you make a PLC command SOLO?
This article shows you the practical path. You will pick a fieldbus, wire it correctly, configure the PLC as the master, map your setpoints, and read back status and faults. The focus is plc motor control with SOLO, not PLC theory. If you need the basics of what a PLC is, start with our PLC overview.
PLC + Motor Controller: The Picture
The roles are clear. The PLC is the master. It holds the machine logic and decides the target speed, torque, or position. The SOLO controller is the slave, or node. It runs the fast current and motion loops in real time and reports back what the motor is doing.
This split matters. The PLC does not close the current loop at the microsecond level. It sends a setpoint a few times per cycle, and SOLO does the heavy control work locally. You get a clean division: high-level sequencing on the PLC, field-oriented control on the drive. For the basics of the controller side, see the PLC overview.
Takeaway: the PLC commands and supervises, SOLO executes the motion in real time.
Choosing the Bus: CANopen vs Modbus
The link between the PLC and SOLO is a serial fieldbus. CANopen is SOLO’s native PLC interface; Modbus is design-ready and delivered for integration projects that need it. The choice follows your machine, not a hard limit of the drive. The table sums it up.
CANopen (CiA 402)
CANopen runs on the CAN bus and adds a device model on top. For drives, the relevant part is the CiA 402 profile, the standard that defines modes of operation, a state machine, and an object dictionary for motion control. With CiA 402 you command profile position, profile velocity, or torque using well-defined objects, and the behavior is portable across compliant drives.
This profile is a topic in its own right, so we keep it focused here. CANopen generally gives you lower latency and better timing than a polled bus, which is why motion-heavy machines tend to pick it. If you want the ground-up view of the protocol, read our guide to CANopen communication for motors.
Modbus RTU / TCP
Modbus is simpler. There is no rich drive profile. You read and write registers, and each register maps to a value in SOLO such as target speed, torque limit, or a status word. Modbus RTU runs over RS-485, and Modbus TCP runs over Ethernet, which is handy when your PLC already has an Ethernet port.
The trade-off is timing. Modbus is polling-based, so the PLC asks for data on each scan and waits for the reply. That adds latency and jitter compared to CANopen. For steady-state jobs like driving a pump at a setpoint, this is usually fine. For tight, coordinated motion, CANopen is the safer pick.
Takeaway: choose CANopen for fast or multi-axis motion, Modbus for simple register-based control your PLC already speaks.
Wiring and Termination
Get the physical bus right before you touch software, because most early problems are wiring problems. On CAN, use a twisted pair for CANH and CANL, keep the stub lengths short, and place a 120 ohm termination resistor at each end of the bus. A bus with no termination, or with three resistors instead of two, will throw random errors that look like software bugs.

Then set the node address. On CANopen this is the node-ID, on Modbus it is the slave address. Each device on the bus needs a unique value, and the PLC must use the same baud rate as every node. If you are connecting from a PC for setup instead of a PLC, you will need a USB-to-CAN or USB-to-UART converter to reach the bus.

Configuring the PLC as Master
With the bus wired, you set up the PLC as the master and tell it how to talk to SOLO. On CANopen, you usually import the drive description and add SOLO as a node at its node-ID. On Modbus, you define SOLO as a slave at its address and list the registers you will read and write. After that, the work is mapping data in two directions: commands out, status in.
Mapping Setpoints (speed / torque / position)
A setpoint is the value the PLC writes to make the motor act. The three common ones are target speed, target torque, and target position. On CANopen with CiA 402 you select a mode of operation, then write the matching object, for example target velocity in profile velocity mode. On Modbus you write the value into the register that holds that setpoint.
Watch the scaling and units. A speed setpoint may be in RPM, raw counts, or a fixed-point format, and a wrong scale is a frequent cause of a motor that spins far too fast or barely moves. Confirm the unit for each value once, write it down, and reuse it across your program.
Reading Status and Faults
Control is only half the loop. The PLC also has to know what the drive is doing, so it reads back a status word and an error register. On CiA 402 the statusword tells you the drive state, such as ready, switched on, operation enabled, or fault. On Modbus you read a status register that carries the same kind of information.
When SOLO reports a fault, the PLC should react: stop the sequence, raise an alarm, or attempt a controlled reset. Map the error register to readable codes in your program so an operator sees a clear message, not a raw number. Reading faults this way is what turns a drive from a black box into a node your logic can supervise.
Takeaway: map setpoints with correct units, and always read the statusword and error register so the PLC can act on faults.
A Minimal PLC Program Flow
You do not need a large program to get moving. A minimal, reliable flow has four steps, and it works the same in ladder or structured text.
- Enable: walk SOLO through its state machine until it reaches operation enabled. On CiA 402 this is the standard transition sequence in the controlword.
- Setpoint: write the target speed, torque, or position once the drive is enabled.
- Monitor: each scan, read the statusword and actual values, and check for faults.
- Stop: on a stop command or a fault, command a controlled stop, then disable the drive.
In structured text this is a small state machine: IDLE to ENABLE to RUN to STOP, with a branch to a FAULT state when the error register is set. Keep the enable and fault handling in their own rungs or blocks so they are easy to test. Build this skeleton first, confirm it on one axis, then add your machine logic on top.
Takeaway: enable, send setpoint, monitor, stop, with a clear fault branch, is enough to run SOLO reliably from a PLC.
Scaling to Multiple Drives
One axis is the easy case. When a machine needs several motors, you put multiple SOLO units on one bus and give each a unique node-ID or Modbus address. The PLC then commands each node in turn, and a shared CAN bus keeps wiring simple compared to point-to-point links.
A multi-node bus brings its own topics: address planning, heartbeat monitoring so the PLC detects a dropped node, and bus load and timing as the node count grows. These belong to bus design rather than single-drive control, so we keep them out of scope here. If you want predictable timing across many nodes, the protocol choice matters, as we cover in time-sensitive protocols.
Takeaway: more drives means more nodes on one bus, each with a unique address and its own health check.
Pros, Cons & Trade-offs
Before you commit, weigh fieldbus control against the old approach of analog I/O, where the PLC sends a 0 to 10 V or 4 to 20 mA signal for speed and reads a few discrete lines. The table shows where each one earns its place.
How SOLO Handles PLC Integration
SOLO is built to support PLC integration over standard buses, so you can fit it into an existing control system instead of reworking the system around the drive. Its native PLC interface is CANopen with the CiA 402 profile, and Modbus (RTU and TCP) is design-ready, delivered for integration projects that need it. Setpoints, status, and faults are exposed over the bus, so your PLC program can command motion and supervise the drive through the same link.
Because SOLO runs field-oriented control locally, the PLC stays free for machine logic while the drive handles the fast loops. You can find protocol docs, register references, and libraries on the SOLO resources page to map your setpoints and status without guesswork.
Conclusion
Driving SOLO from a PLC comes down to a few decisions. Pick the fieldbus that fits your machine, CANopen for fast or multi-axis motion and Modbus for simple register control. Wire and terminate the bus, give each node a unique address, and set up the PLC as the master. Map your setpoints with the correct units, and always read the statusword and error register so your logic can act on faults. Start with the minimal enable, setpoint, monitor, stop flow on one axis, then build out. When you are ready to map the details, the SOLO resources page has the protocol docs and libraries you need.
FAQ
Can a PLC control SOLO over CANopen?
Yes. SOLO supports CANopen with the CiA 402 drive profile, so a PLC acting as the CANopen master can command modes like profile velocity, torque, or position and read the drive state. You add SOLO as a node at its node-ID, then map the objects you need.
Modbus or CANopen for a PLC: which should I use?
Use CANopen when you need low-latency or coordinated motion, or several axes on one bus, because it is event-driven and carries a real drive profile — it is SOLO’s native PLC bus. Modbus suits simple, register-based control on PLCs that already speak Modbus RTU or TCP, and is design-ready for integration projects. Match the bus to the machine, and ask us about Modbus if your line needs it.
How does the PLC read motor faults from SOLO?
The PLC reads a status word and an error register from SOLO over the bus. On CiA 402 the statusword reports the drive state, and the error register carries fault codes. Map these to readable codes in your program so the PLC can stop, alarm, or reset when a fault appears.
Can one PLC control several SOLO drives?
Yes. You place multiple SOLO units on one bus, give each a unique node-ID or Modbus address, and the PLC commands each one in turn. Plan the addresses, add a health check such as heartbeat, and watch bus load as you add nodes.
