EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: 答复: Re: Question about communications based on modbus tcp.
From: lzf neu <[email protected]>
To: Mark Rivers <[email protected]>
Cc: tech-talk <[email protected]>
Date: Fri, 26 Jan 2018 09:15:42 +0000
I have tried the other slave addresses and 0xff as well, and found that the communications could only be established when the slave address was set to 2. I will consult the manual for the hardware devices to check and thank you very much.
发件人: Mark Rivers <[email protected]>
发送时间: 2018年1月26日 4:28:45
收件人: lzf neu
抄送: tech-talk
主题: Re: Re: Question about communications based on modbus tcp.
 

> Why this device cannot randomly set the slave address in drvModbusAsynConfigure command or set 0xFF directly to disable it ?

I don't know the answer to that.  You could try setting it to 0xFF or other addresses to see if they work.  I think you found that 0 does not work.

The slave address is used in the Modbus RTU and ASCII protocols, because these can be daisy-chained RS-485, so it needs a module address in the packet header.  Perhaps your vendor implemented the slave address even for TCP, although I think the specification says it should not.  Does the manual for your device say anything about this?  Does it have a switch or jumper to set the slave address?

Mark


________________________________
From: lzf neu <[email protected]>
Sent: Thursday, January 25, 2018 10:01 PM
To: Mark Rivers
Cc: lzf neu; tech-talk
Subject: 回复: Re: Question about communications based on modbus tcp.

Hi,

Thank you very much, now it works.
and I have two questions to cousult you.

Independent of the previous modbusR1-2 settings, the manual of modbus R2-9 says :"For TCP the slave address is used for the "unit identifier", the last field in the MBAP header.", and the last field in the MBAP header,
as i know,  is the slave address (ranging from 1 to 247).  Also, I have looked up the text book. it says for modbus tcp/ip devices, using IP can address the modbus slave and therefore the modbus identifier is useless and 0xFF should be uesd to fill in the slave address.

Why this device cannot randomly set the slave address in drvModbusAsynConfigure command or set 0xFF directly to disable it ?

Thank you very much.

Zhefu

发件人: Mark Rivers<mailto:[email protected]>
发送时间: 2018-01-26 11:24
收件人: lzf neu<mailto:[email protected]>
抄送: [email protected]<mailto:[email protected]>
主题: Re: Question about communications based on modbus tcp.
Hi,


I realize that I misread the previous version of your modbusInterposeConfig command:


modbusInterposeConfig(const char *portName,
                      int slaveAddress,
                      modbusLinkType linkType,
                      int timeoutMsec)


modbusInterposeConfig("Koyo3R",2,0,2000)


So your device is using slaveAddress=2, not 0.


Thus you need to use this slaveAddress in your drvModbusAsynConfigure command:


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

So this should be:
drvModbusAsynConfigure("RD3R",   "Koyo3R",  2, 3, 0, 95, 0, 1160, "rpDevice")


Please try this change.


Mark



________________________________
From: lzf neu <[email protected]>
Sent: Thursday, January 25, 2018 8:30 PM
To: Mark Rivers
Cc: [email protected]; lzf neu
Subject: 答复: Question about communications based on modbus tcp.


Thanks for your reply, I have tried the settings below in modbusR2-9:

drvAsynIPPortConfigure("Koyo3R",  "192.168.1.241:502",0,0,1)
modbusInterposeConfig("Koyo3R",0,2000,0)
drvModbusAsynConfigure("RD3R",   "Koyo3R",  0, 3, 0, 95, 0, 1160, "rpDevice")

However, the continuous error messages changed to the following lines, it seems the communications were still not established.:

epics> 2018/01/26 09:44:15.992 drvModbusAsyn::doModbusIO port RD3R error calling writeRead, error=192.168.1.241:502 timeout: Resource temporarily unavailable, nwrite=6/6, nread=0
2018/01/26 09:44:19.156 drvModbusAsyn::doModbusIO port RD3R error calling writeRead, error=192.168.1.241:502 timeout: Resource temporarily unavailable, nwrite=6/6, nread=0
2018/01/26 09:44:22.320 drvModbusAsyn::doModbusIO port RD3R error calling writeRead, error=192.168.1.241:502 timeout: Resource temporarily unavailable, nwrite=6/6, nread=0
.....

Thanks in advance !

Zhefu
________________________________
发件人: Mark Rivers <[email protected]>
发送时间: 2018年1月24日 12:44
收件人: lzf neu; [email protected]
主题: Re: Question about communications based on modbus tcp.

Hi Zhefu,


If you look at the difference between the example Koyo1.cmd startup script between R1-2 and R2-9 you will see the following.  For simplicity I have removed the commented out lines that relate to serial RTU and serial ASCII since those don't apply to you.


*******************************************

corvette:modbus/iocBoot/iocTest>git diff -U9 R1-2 R2-9 Koyo1.cmd
diff --git a/iocBoot/iocTest/Koyo1.cmd b/iocBoot/iocTest/Koyo1.cmd
index 7a9d0f4..7434046 100755
--- a/iocBoot/iocTest/Koyo1.cmd
+++ b/iocBoot/iocTest/Koyo1.cmd
@@ -3,91 +3,94 @@
dbLoadDatabase("../../dbd/modbus.dbd")
modbus_registerRecordDeviceDriver(pdbbase)

# Use the following commands for TCP/IP
#drvAsynIPPortConfigure(const char *portName,
#                       const char *hostInfo,
#                       unsigned int priority,
#                       int noAutoConnect,
#                       int noProcessEos);
-drvAsynIPPortConfigure("Koyo1","164.54.160.158:502",0,1,1)
+drvAsynIPPortConfigure("Koyo1","164.54.160.158:502",0,0,1)
#modbusInterposeConfig(const char *portName,
-#                      int slaveAddress,
#                      modbusLinkType linkType,
-#                      int timeoutMsec)
-modbusInterposeConfig("Koyo1",0,0,5000)
+#                      int timeoutMsec,
+#                      int writeDelayMsec)
+modbusInterposeConfig("Koyo1",0,5000,0)


# NOTE: We use octal numbers for the start address and length (leading zeros)
#       to be consistent with the PLC nomenclature.  This is optional, decimal
#       numbers (no leading zero) or hex numbers can also be used.
+#       In these examples we are using slave address 0 (number after "Koyo1").

# The DL205 has bit access to the Xn inputs at Modbus offset 4000 (octal)
# Read 32 bits (X0-X37).  Function code=2.
-drvModbusAsynConfigure("K1_Xn_Bit",      "Koyo1", 2,  04000, 040,    0,  100, "Koyo")
+drvModbusAsynConfigure("K1_Xn_Bit",      "Koyo1", 0, 2,  04000, 040,    0,  100, "Koyo")

*******************************************

So the differences are:

- In the drvAsynIPPortConfigure command in R1-2 the noAutoConnect flag was set.  This should not be set in R2-9, so you should change this:

drvAsynIPPortConfigure("Koyo3R",  "192.168.1.241:502",0,1,1)

to this:

drvAsynIPPortConfigure("Koyo3R",  "192.168.1.241:502",0,0,1)

- The arguments to modbusInterfaceConfigure were changed from this in R1-2:

modbusInterposeConfig(const char *portName,
                      int slaveAddress,
                      modbusLinkType linkType,
                      int timeoutMsec)

to this in R2-9:

modbusInterposeConfig(const char *portName,
                      modbusLinkType linkType,
                      int timeoutMsec
                      int writeDelayMsec)

So you should change this:

modbusInterposeConfig("Koyo3R",2,0,2000)

to this:

modbusInterposeConfig("Koyo3R",0,2000,0)

- Finally the drvModbusAsynConfigure command has changed from this in R1-2:

drvModbusAsynConfigure(portName,
                       tcpPortName,
                       modbusFunction,
                       modbusStartAddress,
                       modbusLength,
                       dataType,
                       pollMsec,
                       plcType);

to this in R2-9:

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

This means that the slaveAddress argument has moved from the  modbusInterposeConfig function to the drvModbusAsynConfigure function.

Since you were previously using slaveAddress=0 in modbusInterposeConfig, you should now use slaveAddress=0 in drvModbusAsynConfigure.  Thus you should change this:

drvModbusAsynConfigure("RD3R",   "Koyo3R",  3, 0, 95, 0, 1160, "rpDevice")

to this:

drvModbusAsynConfigure("RD3R",   "Koyo3R",  0, 3, 0, 95, 0, 1160, "rpDevice")


Mark


________________________________
From: [email protected] <[email protected]> on behalf of lzf neu <[email protected]>
Sent: Wednesday, January 24, 2018 2:00 AM
To: [email protected]
Subject: Question about communications based on modbus tcp.


Hi,


There are radiation dose monitor devices by using modbus tcp protocol to communicate.

The communications have succeeded to establish by using epics 3.14.12.5, modbusR1-2 combined with asynR4-9 (very old version) many years ago.

Therefore, I want to upgrade to the latest program by using modbusR2-9 combined with asynR4-30 and epics 3.14.12.5.

My settings are the same as the old version of modbusR1-2 in start.cmd file:


drvAsynIPPortConfigure("Koyo3R",  "192.168.1.241:502",0,1,1)
modbusInterposeConfig("Koyo3R",  2,0,2000)
drvModbusAsynConfigure("RD3R",   "Koyo3R",  3, 0, 95, 0, 1160, "rpDevice") # modbusR1-2 version


I noticed that there was a little difference of parameter settings in the command drvModbusAsynConfigure of new version (modbusR2-9). The manual says :"For TCP the slave address is used for the "unit identifier", the last field in the MBAP header.", and the last field in the MBAP header, as i know,  is the slave address (ranging from 1 to 247).   So, i randomly set:


drvModbusAsynConfigure("RD3R",   "Koyo3R",  111, 3, 0, 95, 0, 1160, "rpDevice")  # modbusR2-9 version, I randomly set 111


or:


drvModbusAsynConfigure("RD3R",   "Koyo3R",  0xFF, 3, 0, 95, 0, 1160, "rpDevice")  # use 0xFF to disable the parameter


however, I cannot establish  the communications by using the new version of modbus and I have no idea how to do.

The error messages are as follows:


epics> 2018/01/24 15:19:26.062 drvModbusAsyn::doModbusIO port RD3R is disconnected
2018/01/24 15:19:30.069 drvModbusAsyn::doModbusIO port RD3R error calling writeRead, error=192.168.1.241:502 timeout: Resource temporarily unavailable, nwrite=6/6, nread=0
2018/01/24 15:19:31.229 drvModbusAsyn::doModbusIO port RD3R has I/O error
2018/01/24 15:19:35.234 drvModbusAsyn::doModbusIO port RD3R error calling writeRead, error=192.168.1.241:502 timeout: Resource temporarily unavailable, nwrite=6/6, nread=0


Any help will be appreciated,  and thanks in advance !


Zhefu





References:
Question about communications based on modbus tcp. lzf neu
Re: Question about communications based on modbus tcp. Mark Rivers
答复: Question about communications based on modbus tcp. lzf neu
Re: Question about communications based on modbus tcp. Mark Rivers
回复: Re: Question about communications based on modbus tcp. lzf neu
Re: Re: Question about communications based on modbus tcp. Mark Rivers

Navigate by Date:
Prev: Re: Driver support of VMM ControlNet interface module (5136-CN-VME) 李刚
Next: Re: Problems with scaler record on epics archiver Gabriel de Souza Fedel
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Re: Question about communications based on modbus tcp. Mark Rivers
Next: Driver support of VMM ControlNet interface module (5136-CN-VME) 李刚
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 26 Jan 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·