Skip to Content

← All functionalities

Bioreactor controlM-DuinoModbus RTUControl

Variable frequency drive RPM control over Modbus RTU

Agitator speed sets mixing and oxygen transfer in a bioreactor, so the drive must follow its setpoint and report back honestly. This example, from a real bioreactor control deployment, covers Modbus RTU VFD control with an M-Duino PLC: run and stop on one register, an RPM setpoint scaled by one hundred on another, and real speed read back from a 32-bit value split across two 16-bit registers. Two drives share the 9600 8N1 RS485 bus at addresses 3 and 4.

Run, setpoint and feedback registers

Register 0x210D starts and stops the drive. Register 0x0144 carries the RPM setpoint multiplied by one hundred, so 250 rpm is sent as 25000. Feedback lives at 0x2149 as two consecutive 16-bit registers. Keeping command and feedback separate lets the PLC verify the drive actually reached the commanded speed.

Rebuilding a 32-bit speed reading

The real RPM does not fit in 16 bits, so the drive exposes it as two registers. The reader requests both, checks for a clean response, then combines them as (reg0 left-shifted 16) OR reg1. Casting to a 32-bit type before the shift avoids the classic overflow that silently zeroes the high word.

Periodic supervision

Every two seconds the loop reads back actual RPM and prints it. In production this value flows up into the gateway input registers, so the SCADA can compare commanded versus measured speed and raise an alarm if a drive stalls or runs away while the agitator should be holding a steady rate.

A snippet from the implementation

Straight from the example as deployed on the M-Duino — copy it freely:

void setup() {
  Serial.begin(115200);
  master.begin(9600);
  master.setTimeout(300);

  // Example startup: drive 1 at 250 rpm
  startDrive(DRIVE[0]);
  setRPM(DRIVE[0], 250);
}

The full example is a complete program — wiring header, setup and main loop — ready to adapt to your application.

Frequently asked questions

Why is the RPM setpoint multiplied by one hundred?

The drive stores speed with two decimals of resolution as an integer, so 250 rpm is written as 25000. The PLC scales it on the way in.

Why read two registers for the speed?

The actual RPM is a 32-bit value that does not fit in a single 16-bit Modbus register, so the drive splits it across 0x2149 and the next register; the PLC recombines them.

How do I avoid the high word reading as zero?

Cast the value to a 32-bit type before shifting left by 16. Shifting a 16-bit value first overflows and loses the upper bits.

Related functionalities