AB7072 - Modbus ASCII?


#1

I specified two AB7072 serial to Ethernet IP converters for my Controllogix panel. The one in service as a normal RS485 Modbus link works fine but upon contacting tech support for the RS232 Modbus field device (its a gas turbine throttle valve) I have been told that it runs Modbus ASCII rather than the Modbus RTU… I wish it had said that in the manual!

Now I need to convert my Modbus RTU setup in the AN7072 to be Modbus ASCII. Your manual says that the unit is capable of ASCII but the wizard is only configured to setup RTU. Could some offer any help of an easy solution?

Alastair
QLD, Australia.


#2

Hello @ajmac,

The Communicators do not have built in support for modbus ascii, you will need to manually create transactions using modbus ascii. Modbus ascii is almost the same as modbus but all the data is sent as ascii characters rather then the values them selves. Here is an example I had created for another customer. smc_example.cfg
In the case of this example there were some issues with the checksum’s not matching. The customer managed to calculate the checksum manually for the query and add it as a constant and then use a data object for the response.

This web site is a good resource that you can use to understand how modbus ascii works.
http://www.simplymodbus.ca/ASCII.htm

Deryck


#5

Still no joy.
I have used simply modbus and have good comms with the device. I have used the simply modbus query and response info that IS WORKING to build the Anybus query and response in ASCII but I can’t get any comms to establish. I am not sure where to put the ‘data’ that is required to tell the Anybus converter where to store the response data in the Ethernet/IP datablock, any ideas?

ALV10_Simply_Modbus_q%26r


#6

Hi,

Modbus ascii involves some more overhead then standard modbus make sure you are not missing any parts. http://www.simplymodbus.ca/ASCII.htm

You will need to put date in the corresponding location depending on it purpose. Input data, data from read requests falls under 0x000 - 0x1FF. Output data, data written to the slaves, is from 0x200 - 0x3FF. (section 2.4.3)

Regards,
Deryck


#7

I honestly don’t understand why I can’t get this to operate. See attached screen shots. My Request for 10 registers is copied directly from the simply modbus request field that is working perfectly with the slave device. I think i must have something wrong in the response field, or perhaps the Anybus checksum setup is incorrect? Thoughts.ALV10.cfg (16.0 KB)


#8

Hi @ajmac ,

The screen shots looks correct, but I didn’t check that the hex values correspond to the correct characters. the .cfg file you uploaded looked different.

When I was working with a customer on a similar issue, they were running into issues with the checksum. What they ended up doing was manually calculating the checksum for the query and entering it in as a constant. The response was consumed as a data object, but written to the general area (0x400) to be ignored.
You should be able to find a twos complement calculator online, enter in the transaction and calculate the checksum.

Deryck


#9

The request checksum is correct, I have it as a static value taken from the checksum the simply modbus master successfully used while requesting the 10 registers.
When you say 0x400 area do you just mean the reply checksum portion of the response?


#10

Hi @ajmac,

If you take a log of the traffic does the message look correct? Do you see any Rx data with the slave responding back with anything?

When you say 0x400 area do you just mean the reply checksum portion of the response?
In the response rather then adding the checksum object you would add a data object and consume the checksum, but since you do not need to read this with the plc you can write it to the general memory area. This essentially has the communicator skip the checksum and just consumes it writing it to an unused part of memory.

Deryck


#12

I have logged the data traffic now. The response from the slave is shown perfectly and matches that shown when I use a simply modbus master to query the slave. Thus I am happy with the Anybus query and that it is receiving a good response from the ASCII slave. However the data is not being transferred to the memory area in the PLC and the red serial comms LED is still lit on the Anybus converter, suggesting that it is still not happy with the serial side of communications.


#13

Hello,

Can you upload a copy of your configuration and a log of the traffic for me to take a look at. If data is not being consumed most likely the response back does not exactly match the consume transaction.

Regards,
Deryck


#14

Here you go. Attached.29_04_19.cfx (579 Bytes)
29_04_19.cfg (16.0 KB)
Anybuslog.txt (27.9 KB)


#15

You will note that I have enabled the diagnostic couple of bytes and shifted by received data down to 0002 to make room for it.


#16

Hello @ajmac,

Your consume transaction does not match the data see in the logs. It looks like the data object is only 20 bytes long but im seeing at least 40 bytes/characters in the log. To start i recommend updating the data object to match the bytes coming in.
If you are still not seeing data consume try having the checksum be a data object and consume that too to remove that from the equation. It looks like there is a bug with the check sum and as you suspect it might be calculating the checksum for the consume incorrectly.

Regards,
Deryck


#17

I have updated the consumed block to 40 bytes and replaced the checksum with a static checksum manually calculated for the simulated modbus slave data i am sending and i have successfully began to communicate between the PLC and the ASCII slave…so long as I don’t change the simulated data, if I do the checksum no longer matches the manually entered one and the comms fails…obviously. However with the Anybus checksum block in place i have no comms just as before. Is there any way to disable the checksum checking on the received data?


#18

Hello @ajmac,

Looking though some older issues we have it looks like the communicator does not support calculating the checksum for modbus ascii. Though I have not been able to find the reason why. It might be due to how modbus ascii calculates the crc.

  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.

As previously suggested i suggest you grab the check sum as a data object and write it to the extended memory section to discard it.

Regards,
Deryck


#19

I’ve dumped the checksum into 0400 local memory area and all is well, coms between ASCII device and PLC is working now. However I would suggest that you guys correct the checksum functionality on the next release as not have a checksum does leave the link open to noise disruption not being detected.


#20

Hi @ajmac,

Glad to hear it is working! I will forward this feedback to development.

Regards,
Deryck


#22

Back at site today…to reinstall the unit and run it with the actual ASCII field equipment. Is doesn’t work. It can’t be much that is wrong but I an scratching my head. Any thoughts?
At site I have the converted serial side connected to my laptop running modsim and everything works.
Connect modscan to the same simulation laptop and again all works and good data transfer. Disconnect the simulation laptop and plug into the field device and again all is fine, the modscan reads all the real ASCII date from the field device.
Plug the anybus into the field device without any changes from it working perfectly against the modsim laptop and NOTHING!
Modscan reports that the ASCII field device when communicating with it was responding in 200ms to the query. Could it be a timing issue related to the real work ASCII field device? How can I slow the anybus down to test this idea?


#23

Hi @ajmac,

Timing was the thing that comes to mind for me. try increasing the Message delimiter from the subnetwork settings. My guess is this is not catching the end of the messages correctly. The default setting is 0 for 3.5 characters for modbus RTU. I would change it to 200 and see if that helps.

Do you see anything if you take a log?

Deryck