Hi everyone
I'm looking for assistance with setting up communication between a CR310 datalogger and a Modbus ASCII sensor.
The sensor has the following characteristics:
Communication: RS485
Protocol: MODBUS ASCII
Baud rate: 19200 bauds
Slave address: 1
Data bits: 8
Stop bits: 2
Parity: None
Modbus function to read data: 03 "Read holding registers"
Registers to be read: 1000 - 1028 (29 in total)
The sensor is connected to the RS232 port on a Campbell CR310 datalogger through an ADAM-4520 RS-232 to RS-485 converter. I have used Simply Modbus Master to successfully establish communication with the sensor through the converter so I know that it is working correctly.
Simply Modbus Master sends the following request and then receives a correct response from the sensor with data from all 29 registers.
:01 03 03 E8 00 1D F4 CR LF
However, when using the CRBasic code below uploaded to the CR310 logger and using the terminal emulator in Loggernet I see that the CR310 is sends the following request but never receives any response.
T 3A 30 31 30 33 30 33 45 38 30 30 33 41 44 37 0D :010303E8003AD7
T 0A
I have tried changing configuring the ModbusOption parameter in the ModBusMaster instruction as 10, 11, 12 and 13 (all the Modbus ASCII values according to the CRBasic Help) and the data request sent by the logger is always the same.
Now, regarding the data request that the Campbell sends. I believe that the T in the beginning of the package stands for transmit and all received packages should start with an R. I'm unsure what the data that comes next (in italic) is. Then comes what I believe to be the request itself ":010303E8003AD7"
If I compare this data to what the Simply Modbus Master sends I notice that the Campell's package is missing the CR LF
:01 03 03 E8 00 1D F4 CR LF | Modbus master
:01 03 03 E8 00 3A D7 | Campbell
According to the protocol description the ModBus ASCII protocol should send the CR LF trailer when sending Function 03 to a ModBus Slave.
Could the issue be that the Campbell does not send the CR LF trailer and what steps should be taken to solve it?
If you think this is not an issue, any other ideas? Any help is very much appreciated!
CRBasic program:
'Variables declared
Public Modbus_ResultCode
Public Mod_In(2) As Float
BeginProg
' COMRS232 flushed
SerialFlush (ComRS232)
' Communications on COMRS232 opened.
' Baud : 19200
' Format : 7 - Binary, no parity, two stop bits, 8 data bits
' TXDelay : 0
' Buffer size : 10000
' Sleep mode : Off
SerialOpen (ComRS232, 19200, 7, 0, 10000, 0)
' SW12 powered on to power on sensor
SW12 (1)
' Main scan
Scan (10,Sec,0,0)
' ModBus Master instruction on COMRS232, 19200 baud
' Function : 03 - Read Holding Registers
' Start address : 1001 (The data address in the Modbus frame sent to the slave will be equal to "Start-1")
' Length : 29
' Tries : 1
' TimeOu : 200 (2 seconds)
' ModBusOption : 13 (have also tried 10, 11 and 12)
ModbusMaster (Modbus_ResultCode, ComRS232, 19200, 1, 3, Mod_In(), 1001, 29, 1, 200, 13)
NextScan
EndProg
I can see a CR/LF (0D 0A) in your transmitted messages. Your destination array looks way too small though.
What do you get in Modbus_ResultCode?
Dear pokeeffe, thank you for your reply. Here are my further toughts.
I can see a CR/LF (0D 0A) in your transmitted messages.
Yes, I believe you are correct. I did not realize that the 3A 30 31 30 33 30 33 45 38 30 30 33 41 44 37 0D 0A is really the package being sent. After translating it from HEX to ASCII I can see that this is the package and of course the 0D 0A is the CR/LF trailer.
Your destination array looks way too small though.
Yes! I left it to small after some testing but it is fixed now.
What do you get in Modbus_ResultCode?
The result code increments by 1 after each scan. The CRBasic Help provides the following information on this behaviour: "ResultCode is set to 0 if communication is successful; it increments by 1 after a communication failure (a failure is an expiration of the timeout period and any Tries)"
Are you sure the serial port settings are correct? You set mode 7 in SerialOpen() to enable 2 data bits, but it's possible the RS485 adapter is operating in default 8n1 mode. If so, you can remove the SerialOpen() instruction.
The issue has been resolved! Turns out, it was the serial cable between the datalogger and the ADAM-4520 converter that was faulty. It was not the same cable I had used to connect the ADAM converter to my desktop for testing with ModBus Master.
With new cable and the program in my original post everything works as expected.
Thank you for all your thoughts pokeeffe.
🙋♂ :high-five:
Dear NLA_MV, you give a perfect answer to the question. I appreciate it.
Yes, translating 3A 30 31 30 33 30 33 45 38 30 30 33 41 44 37 0D 0A with the hexadecimal converter, we got the value
:01 03 03 E8 00 3A D7
It is important that the package is correct, and the 0D 0A trailer is, of course, what I'm looking for.
You can learn more about Modbus ASCII protocol here:
https://www.modbustools.com/modbus.html