Re: MODBUS User-Defined Function Codes

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi William,

Modbus transactions are always write/read.  As long as the write/read is atomic (done with a mutex held) then there should be no conflict between running StreamDevice and the asyn Modbus driver on the same asyn serial port driver.

All Modbus I/O with the asyn Modbus driver is done in this one line:

https://github.com/epics-modules/modbus/blob/4e39e7a89687403443f3180a3b0d8b0d2ca35eb2/modbusApp/src/drvModbusAsyn.cpp#L2177

It uses writeRead, so it is atomic.

My impression was that StreamDevice also holds a lock between write and read requests so that they are atomic.

What do you see when Modbus and StreamDevice share the same underlying asyn port?

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of William Jamieson via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 2, 2026 11:54 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: MODBUS User-Defined Function Codes

 

Does anyone have experience using user-defined function codes alongside the standard function codes that can be handled by the asyn MODBUS driver? I am currently using the MODBUS driver for the standard 03 "READ HOLDING REGISTERS" function while simultaneously using streamDevice driver for executing user-defined functions. This is resulting in conflicts between the MODBUS and streamDevice driver. I have tried setting up two virtual ports pointing to the same serial port:

drvAsynSerialPortConfigure("rs485_modbus", "/dev/ttyUSB0", 0, 1, 0)

drvAsynSerialPortConfigure("rs485_stream", "/dev/ttyUSB0", 0, 1, 0)

Then using a SEQ record that disables the rs485_modbus port then enables the rs485_stream port before processing the stream record. after processing, it disables the rs485_stream port and re-enables the rs485_modbus port.

I disable and enable ports by writing a 0 (disable) or 1 (enable) to the CNCT field of an ASYN record for each port. Example record:

record (asyn, "modbusPort_ASYN")
{
    field (PORT, "rs485_modbus")
}

Not only does this switchover create a lot of I/O Error messages in the IOC shell, but this still results in a garbled data readback from the stream record.

Does anyone have a successful method of making these two methods work in parallel? (or some other tools that make it work) Or should I just give up and use deviceStream reads/writes instead of just the custom ones. I prefer to use the MODBUS driver if possible for the standard MODBUS function codes.

Thanks for any help!

William Jamieson

PPPL I&C Engineer