Re: [External] Re: MODBUS User-Defined Function Codes

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

Hi William,

I had forgotten about the interpose_interface part of the Modbus driver.  That will affect StreamDevice communication, although it should just add and remove CRCs.

Is it fixed in stone that your device uses non-standard Modbus function codes?  That seems like a questionable design.  Could you do the same thing using different address ranges rather than function codes?

An alternative approach would be to write an asyn driver that inherits from the drvModbusAsyn class.  All of the methods in that class are virtual, so you can just reimplement the methods that use the additional function codes.  That would be a cleaner solution, and you can probably re-use most of the code.

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: Tuesday, February 3, 2026 7:16 AM
To: Torsten Bögershausen <tboegi at edom.se>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: [External] Re: MODBUS User-Defined Function Codes

 

Thank you for the information. I have implemented everything across the same virtual and physical port using the below settings in st.cmd:

drvAsynSerialPortConfigure("rs485_port", "/dev/ttyUSB0", 0, 0, 0)
asynSetOption("rs485_port",0,"baud","19200")
asynSetOption("rs485_port",0,"parity","even")
asynSetOption("rs485_port",0,"bits","8")
asynSetOption("rs485_port",0,"stop","1")
modbusInterposeConfig("rs485_port",1,1000,0)

The below commands are used to read in data via function 3 (st.cmd):

drvModbusAsynConfigure("oxigraf_data_1", "rs485_port", 230, 3, 0, 7, 0, 200, "oxigraf")
drvModbusAsynConfigure("channel_o2_readings", "rs485_port", 230, 3, 35, 4, 0, 200, "oxigraf")
drvModbusAsynConfigure("pump_drive_level", "rs485_port", 230, 3, 10, 1, 0, 200, "oxigraf")
drvModbusAsynConfigure("command_codes", "rs485_port", 230, 3, 97, 3, 0, 200, "oxigraf")

I also began tracing the port to a file (st.cmd):

asynSetTraceMask("rs485_port", 0, 0x09)
asynSetTraceIOMask("rs485_port", 0, 0x04)
asynSetTraceFile("rs485_port",0,"rs485_port-trace.txt")

For the streamDevice portion of the communication, I am using one simple proto file that directly sends binary to the serial and waits for a reply. It is following the command structure specified in Section 3.3 of Modbus User Defined Command Format of the "MODBUS INTERFACE GUIDE OXIGRAF MO2i FAMILY OXYGEN SENSORS" Manual, dated January 8, 2008. User-defined command 100 is used.

Format of message specified by manual:
Command: Addr 100 1 O2.H O2.L CRC.L CRC.H

Response: Addr 228 5 CRC.L CRC.H   

My proto file:

Terminator = ;
ReplyTimeout = 200; # milliseconds
ReadTimeout = 2000;

calibrateLow{
        out "\xe6\x64\x01\x08\x2a"; #e6 is the modbus slave address, 64 is user-defined command 100, 01 is the command specific to the device "low end calibration", 08 2a is an integer describing cal gas concentration (2090 for 20.90% O2). When I enable modbus interpose config, the CRC is calculated and sent automatically as the trace below shows.
        in "\xe6\xe4\x05\x1b\x34"; # e6 is the modbus slave address, e4 is the expected response 228, 05 is the expected response 05, and 1b 34 are the expected CRC from the slave device
}

When I process the stream record that calls the calibrateLow section of the above proto file, the below trace happens:

2026/02/03 07:59:40.410 /dev/ttyUSB0 write 7
e6 64 01 08 2a e5 39

2026/02/03 07:59:40.434 /dev/ttyUSB0 read 5
e6 e4 05 1b 34
2026/02/03 07:59:40.435 modbusInterpose::readIt, CRC error

The following errors also appear in the IOC shell:
2026/02/03 07:59:40.434526 rs485_port lowCalibrate_BO: asynError in read:
2026/02/03 07:59:40.434555 rs485_port lowCalibrate_BO: I/O error after reading 0 bytes: ""
2026/02/03 07:59:40.434568 rs485_port lowCalibrate_BO: Protocol aborted
2026/02/03 07:59:41.383 drvModbusAsyn::doModbusIO port channel_o2_readings error calling writeRead, error=asynManager::queueLockPort queueRequest timed out, nwrite=0/6, nread=0
2026/02/03 07:59:41.415 drvModbusAsyn::doModbusIO port pump_drive_level error calling writeRead, error=asynManager::queueLockPort queueRequest timed out, nwrite=0/6, nread=0
2026/02/03 07:59:41.447 drvModbusAsyn::doModbusIO port command_codes error calling writeRead, error=asynManager::queueLockPort queueRequest timed out, nwrite=0/6, nread=0
2026/02/03 07:59:41.562 drvModbusAsyn::doModbusIO port oxigraf_data_1 error calling writeRead, error=, nwrite=6/6, nread=5
2026/02/03 07:59:43.935 drvModbusAsyn::doModbusIO port channel_o2_readings writeRead status back to normal having had 2 errors, nwrite=6/6, nread=10
2026/02/03 07:59:44.862 drvModbusAsyn::doModbusIO port command_codes writeRead status back to normal having had 2 errors, nwrite=6/6, nread=8
2026/02/03 07:59:44.990 drvModbusAsyn::doModbusIO port oxigraf_data_1 writeRead status back to normal having had 2 errors, nwrite=6/6, nread=16
2026/02/03 07:59:45.118 drvModbusAsyn::doModbusIO port pump_drive_level writeRead status back to normal having had 2 errors, nwrite=6/6, nread=4

The slave device accepts the command and behaves as expected, but modbusInterpose throws the above CRC error. In addition, some nuisance errors seem to appear from the brief break in modbus polling.

I think that modbusInterpose is interfering with what the stream expects to see on its "in" line. I am not sure how to mend this. I have tried getting rid of the CRC (\x1b\x34) on the "In" line of the proto file as well, but that still results in the same "2026/02/03 07:59:40.435 modbusInterpose::readIt, CRC error."

William Jamieson

On Tue, Feb 3, 2026 at 2:32 AM Torsten Bögershausen <tboegi at edom.se> wrote:

On 2026-02-02 18:54, William Jamieson via Tech-talk wrote:
> 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)

I think that this is the wrong approach - according to my understanding.
Both the modbus and streamdevice should lock the asynport.
("rs485_port")
Which should the lock the underlying device, "/dev/ttyUSB0".
If you enable all asyn traces (and direct them to a file)
there should be some light comming up, if there is a problem
here in synchronizing things.
Or if there is a problem with the hardware ?


>
> 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
>
>