Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: ATU on August 07, 2018, 12:18:53 PM
-
On the BRX, how would you handle Modbus TCP Ascii Protocol? Its a older device with some type of Ethernet Converter that I am stuck with, but the Ethernet Modbus protocol is in Ascii.
-
Didn't know they put ascii on TCP. We don't support it.
Creating a generalized handler would be more work, but if you know exactly what you are reading/writing, it isn't too hard to roll your own with TCPOPEN/STREAMIN/STREAMOUT/CHECKSUM.
-
Do-more does not support the original Modbus/ASCII (Serial or on Ethernet). You are going to have to write your own logic and treat it like a "custom protocol". You would only need to implement the function codes you need, generating the Master and processing the Slave's response.
You would use OPENTCP to create the connection, but then also have to handle any situations where the remote side might disconnect you. Then use STREAMOUT/STREAMIN to transmit/receive the ASCII "packets".
Which function code(s) will you need to implement?
-
Only need the holding register read, code 3? Do you have any documentation good links for the TCP protocol?
-
http://www.modbus.org/specs.php (http://www.modbus.org/specs.php)
-
Modbus/TCP basically just drops the serial address byte and CRC from the RTU packet and adds a 7 byte header. I'm happy to answer questions, although I have never implemented the ascii variety.
-
The only place ascii mode is mentioned is in the Legacy spec. So I swap the RTU packet information in the TCP Protocol with the Ascii formated packet?
-
Maybe, but you may be looking at Modbus/RTU (Ascii) over TCP, not Modbus/TCP.
-
MODBUS Messaging on TCP/IP Implementation Guide V1.0b?
There is also MODBUS APPLICATION PROTOCOL SPECIFICATION
V1.1b3
No mention of Modbus Ascii anywhere. I had to pull up the legacy spec
Modicon
Modbus Protocol
Reference Guide
PI–MBUS–300 Rev. J
To find any mention of it.
I have my client digging up the documentation for the device to see if you can choose between Ascii and RTU.
Even 20 years ago on most equipment you had a choice. I am hoping there is some dipswitch somewhere to flick.
-
Maybe, but you may be looking at Modbus/RTU (Ascii) over TCP, not Modbus/TCP.
So even if there is a choice, the protocol may be different from the BRX Modbus?
-
So even if there is a choice, the protocol may be different from the BRX Modbus?
BRX Modbus/TCP is according to the spec I directed you to. There are a number of NotReallyModbusTCP implementations out there, including the Modbus/RTU over TCP I mentioned. I'm sure they are all close to the spec, but in comms, 'close' usually means 'doesn't work'.
-
OK, sending out and receiving data.
Sending out
:010303EC000C74<CR><LF>
Receiving
:01830478<CR><LF>
I found that 04 is an internal error in the slave?
My question is the LRC value. I used CHecksum and then the STRPRINT function using FmtInt(D10,hex,2,zeropad) "$0D$0A" where D10 is the LRC value. Is the LRC value supposed to be converted to ASCII?
-
Exception code 4 is Slave Device Failure.
Not sure what it means in this context.
-
My question is the LRC value. I used CHecksum and then the STRPRINT function using FmtInt(D10,hex,2,zeropad) "$0D$0A" where D10 is the LRC value. Is the LRC value supposed to be converted to ASCII?
It appears so from my brief web search.
-
I looked up on the Simply Modbus website on how to calculate the LRC. It was different than what the CHECKSUM instruction gave me. I hard coded that number in the request string and it works! I get the data. Not sure why it didn't.
This is the request string that works
:010303EC000B02
When I used Checksum on that string (prior to adding the Checksum), it calculated a 75 using an Offset of 1 so it doesn't include the ':'
-
I found this on the Simply Modbus website:
1. Add up all the data bytes in the message (before converting to ASCII and without the initial colon and final CR/LF).
2. Throw away any bits that carry over 8 bits.
3. Make the result negative (by twos compliment) to get the LRC byte.
-
Different LRC apparently. The one in the instruction is what Koyo uses in their serial protocols. The sum and invert is different.
-
Maybe add a another choice for Modbus ASCII LRC and one for LRC Koyo?
-
Any possibility of adding the MODBUS LRC to the Checksum instruction?
-
No time soon.
But I think it can already do what you need. Change to Checksum:8 and output to a signed byte LRC, then use MATH LRC = -LRC to do the two's complement.
-
using the StreamIn instruction
When specifying a Data Buffer Block
Does it Store the data byte for byte received or characters received? For instance if I receive 1 byte containing 2 characters, does it store the 2 characters in separate bytes or 1 byte as it is received. If you have the terminator characters unchecked, does it store those bytes or does it strip them out?
Here is the issue
When I receive the data into a Long String, I get 107 characters when I check to look for the termination Characters
When I uncheck that box and store it in a data buffer and wait for a timeout, the instruction receives 96 bytes and no sign of termination characters in the data block buffer. Just trying to make sense of what is going on. First time I am trying to write a protocol and it won't be the last.
-
No conversions. Byte in, byte out. Terminators are stored as received, unless the strip option is specified.
-
I finally got it to work with the string method. Seemed to be the best way to handle it. Read it into one large string and then parse out the data as sub=strings and then do the conversions.
BTW, the string to data conversion instructions saved me a ton of work. Nice job on those.