Re: A Modbus problem relating to byte order and endian

[Maren Purves via Tech-talk <tech-talk at aps.anl.gov>]

If you're running the versions of asyn and modbus (neither one of which I know a lot about, they may have byte-switching options built in) on systems they were not compiled on and there may have been endian-switching in one of the components, recompiling on the system you're running it on may (may!) help.

I'm afraid I'll have to leave the rest to the experts in the systems you're using.

Maren Purves
Head of Instrument and Telescope Software
East Asian Observatory / JCMT

On Mon, Nov 6, 2023 at 10:20 PM Chiang, Liang-Chih [江良志] <chiang.lc at nsrrc.org.tw> wrote:

Thanks for replying.

According to your experience, I think I have two options:

1.modify the controller parameters to change the byte orders of Modbus registers

2.read each Modbus register separately, then combine them

Some information are provided as follows, though maybe not helpful.

My computer:

OS: CentOS 6.9

Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit

Byte Order: Little Endian

CPUModel: Intel Core i7-6700

EPICS/IOC server:

OS: CentOS Stream release 8

Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit

Byte Order: Little Endian

CPUModel: Intel Xeon Silver 4210R

Best regards.

LiangChih Chiang

NSRRC beamline group

email: chiang.lc at nsrrc.org.tw 

---

寄件者: Maren Purves <m.purves at eaobservatory.org>
寄件日期: 2023年11月7日 下午 04:10
收件者: Chiang, Liang-Chih [江良志] <chiang.lc at nsrrc.org.tw>
副本: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主旨: Re: A Modbus problem relating to byte order and endian

 

Aloha,

this may not so much have to do with the version of asyn and modbus but with the architectures and/or operating systems of the computers involved. I remember running into problems like this when we switched from Solaris (on Sun machines) to Linux (on x86 machines) (about 20 years ago, with the IOCs staying the same) - when for array readouts displayed as images we got 'striped data'.

In your case recompiling on the system you're running it on may help, I think at the time I may have implemented byte-switching in transfer, but this being 20 years ago I don't remember the details.

Maren Purves
Head of Instrument and Telescope Software
East Asian Observatory / JCMT

On Mon, Nov 6, 2023 at 9:09 PM Chiang, Liang-Chih [江良志] via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hi, EPICS mates,

I have a motor driver(Oriental AZ series) with built-in encoder.

Its RS-485 2-wire interface is adapted by a MOXA Nport 5150A to ethernet(TCP/IP).

I use Modbus to read its encoder position.

I tested it on my own computer,  and successfully read out the encoder position.

However after transfered to a production EPICS/IOC server, the encoder position value became strange.

Please notice that the versions of modbus module are different.

On my computer(asyn-4-26, modbus-2-7), the read value is:

decimal -271,289

hex FFFB DC47

On EPICS/IOC server(asyn-R4-42, modbuus-R3-2), the read value is:

decimal 1,205,664,767       

hex  47DC FBFF

Following is my settings and EPICS record:

## drvAsynIPPortConfigure("portName", "hostInfo", priority, noAutoConnect, noProcessEos)

drvAsynIPPortConfigure("AZPORT01","192.168.2.61:4001",0,0,1)

## modbusInterposeConfig("portName", linkType, timeoutMsec, writeDelayMsec)

modbusInterposeConfig("AZPORT01", 1, 1000, 100)

##drvModbusAsynConfigure("portName", "tcpPortName",slaveAddress, modbusFunction, modbusStartAddress, modbusLength, dataType, pollMsec, "plcType")

drvModbusAsynConfigure("AZPORT01_CH1ENC",   "AZPORT01",    1, 0x03,  0x00CC, 0x02,    6, 100, "AZPORT01")

record(longin, "$(P)$(R)Xenc") {

    field(DTYP, "asynInt32")

    field(INP, "@asyn($(PORT)_CH1ENC 0)MODBUS_DATA")

    field(SCAN, "I/O Intr")

}

By the way, if I changed the "dataType" from 6(INT32_BE) to 5(INT32_LE), the value became:

decimal -599,261,189       

hex  DC47 FFFB

Best regards.

LiangChih Chiang

NSRRC beamline group

email: chiang.lc at nsrrc.org.tw