回覆: A Modbus problem relating to byte order and endian

[Chiang, Liang-Chih [江良志] via Tech-talk <tech-talk at aps.anl.gov>]

Hi, Dear Mark, Thank you very much.

That should fix the problem.

I didn't notice it because I read the Modbus module documents(pdf files) of versions 2.10 and 3.10,

which were downloaded long time ago.

And INT32_LE_BS and INT32_BE_BS don't exist in version 3.10 yet.

My bad.

Thanks again.

Best regards.

LiangChih Chiang

NSRRC beamline group

email: chiang.lc at nsrrc.org.tw 

---

寄件者: Mark Rivers <rivers at cars.uchicago.edu>
寄件日期: 2023年11月7日 下午 10:13
收件者: 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

 

Hi,

The problem is that you are using the same enum values (5 and 6)  to specify the datatypes for Modbus R2-7 and R3-2.  However, the Modbus R3-1 release notes say this:

Note: The enum values for the datatypes are not backwards compatible. INT16 and UINT16 were swapped and everything beyond INT32_LE is different. This may require changes to startup scripts.

This is the definition of the enum values in R2-7:

https://github.com/epics-modules/modbus/blob/718cb02ec47db81d942d8cd54f76b1f9aaf06fdf/modbusApp/src/drvModbusAsyn.h#L40

5 = dataTypeInt32LE

6 = dataTypeInt32BE.

This is the definition of the enum values in R3-2:

https://github.com/epics-modules/modbus/blob/66e562422342f6e7b45a0298f936b9c0fc32011a/modbusApp/src/drvModbusAsyn.h#L80

5 = dataTypeInt32LE

6 = dataTypeInt32LEBS

7 = dataTypeInt32BE.

So if you use enum values you need to use 7 rather than 6 for Modbus R3-2.  However, I strongly recommend that you use the symbolic name string rather than the enum number, i.e. INT32_BE or INT32_LE.  Those will not change in the future if more types are added.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Chiang, Liang-Chih [江良志] via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, November 7, 2023 2:20 AM
To: Maren Purves <m.purves at eaobservatory.org>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: 回覆: A Modbus problem relating to byte order and endian

 

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