problem on Controllogix to send/read Modbus TCP data & using TCP-ASCII bridge

iuhytvYUTCU

Member
Join Date
Jun 2018
Location
Shanghai
Posts
28
I am working on a project, inside an AB CLX, I implemented the Modbus TCP Client AOI published on AB website, to interreact with a Modbus ASCII device (HACH PCX2000).

The Controller connects using Ethernet port, to a TCP-ASCII bridge, then the bridge module connects to the device through RS485.

The needed operations seemd to be easy, until I put the whole thing to test.
At the beginning of the procedure, a single character 'c' is sent to the device. Then 'e' is sent. Both of them need no reading back. Final operation is to send 'A', and then immediatly read from the device, the data I need ('A' is the command to tell the device to report). These operations work as intended when testing under PC-USB-RS485-Device structure.

First issue is that it takes random time delay for device to recongnize 'c' and 'e'. When checking RS485 activity on PC (PC-USB-RS485 line is wired), I can see more then needed characters appeared on the line, however I can not confirm what are they. It is seen that the PLC sent multiple batches of data in a time span, and not every batch of data that PLC send is identical, only when PLC sent a line including 0#63 (character c) the device will finally recongnize.

Second wierd thing is that I have to set the bridge in Modbus over TCP/IP transparent transmission mode for the whole thing to work, which is not true according to my understanding; the bridge should not transparently drop the modbus TCP data on the serial line, am I wrong?? Although I am not convinced, again. 🤥

Final problem is that after sending 'A' I was not succcessfully reading back the device report. Actually I have to say I don't know how to use the AOI in this scenario that the controller sends out a command and then reads right away, especially behind a modbus protocol bridge, or is this basically impossible/incompatible?

Any understanding or suggestions, folks? Big thanks to any words in adv!!!
 
Need some basic definitions here

The AOI that I've used on the CompactLogix PLCs does Modbus TCP over Ethernet. Modbus TCP over Ethernet can be converted by a piece of equipment that may be called a 'bridge' or a 'gateway' to a serial protocol. Most commonly the serial protocol is Modbus RTU or Modbus ASCII. Modbus ASCII is not the same thing as a ASCII-based instrument command protocol. Modbus ASCII is a version of the Modbus protocol that uses human-readable ASCII characters to form the Modbus packet. Like all Modbus, Modbus ASCII is used to read and write register and bit data from PLCs and other equipment.

Based upon this, you cannot send single ASCII characters using any form of Modbus protocol. That sounds more like a simple instrument command protocol. There are instructions available on the PLC that can be used for those situations. It sounds to me like the Modbus AOI is not the right approach to solving this problem.
 
What is the exact Ethernet/Serial device you are using ?

The 2200 PCX Hach particle counter has a simple ASCII command/response protocol that is not related to Modbus at all.

If the Ethernet/serial device you have can really function in "transparent mode" then you'll have to write your own raw sockets implementation of the serial protocol. Or if it's meant to use Modbus/TCP to send generic ASCII strings, you may be able to use that AOI.

But if it's purely a Modbus/TCP to Modbus RTU or Modbus ASCII gateway, then it won't work for this application.
 
I agree with Corsair and Ken Roach. OP needs to send the characters in the HACH command protocol (c, e, A, etc.), and also parse the responses.

The HACH 2200 PCX manual (here) mentions "Modbus ASCII" but does not supply the memory map that would be integral to any Modbus implementation in the HACH.

A TCP<=>ASCII(serial) interface, that translates bytes sent using a TCP-based protocol to an ASCII serial cable (RS-485), will not work with Modbus TCP data because

  • the Modbus TCP protocol has no built-in checksum, it uses the checksum built into the outer TCP/IP protocol, which encapsulates the Modbus TCP protocol, to detect corruption during transmission.
  • While the Modbus ASCII protocol usage a Longitudinal Redundancy Checking (LRC) checksum at the end of the message.
So even if the 2200 PCX spoke the Modbus ASCII protocol, and the TCP<=>ASCII(serial) interface knew to convert the each binary TCP byt to on of the the sixteen hexadecimal character that compose the Modbus ASCII protocol (which it almost certainly does not), it would definitely not know to append the LRC.

OP needs to use the Logix plain socket interface (I am not sure what it is called; update: "raw sockets;" thanks Ken!) to write 7-bit ASCII characters to the TCP connection to the interface, and then the interface will transmit them over the RS-485 wire, and vice versa. The simplest way to get this working with to write a PC-based program, because the socket interface library is much easier to work with; developing such an application from scratch on the CLX is going to significantly lengthen development time. Once the PC-based application is working, part of which will involve a HACH server emulator, porting the application to the CLX will be much easier, because the CLX can be connected to the emulator, and the emulator can display what data it receives. Having a serial sniffer on the RS-485 network would be a workable alternative.
 
I think have worked with that very instrument (but PCX2200 sounds more familiar) quite a bit and because it is pure Ascii I wound up using UCON plugin for Kepware to get it done through a USB to RS485 adapter at the server. It needs the send/waitfor kind of interaction that is tough to code in a PLC.

I never saw "modbus ascii" in my PCX2200 implementations, it was serial ascii only. I imagine they might have updated...but that's not usually Hachs' style. (SC1000 anyone? ).

You might be able to use the serial port of an L61 or maybe a 5380-serial module to do this, I always intended to try but as yet I have not.

I have used a PLC-5 on a similar instrument but I was only sending commands, not reading back.
 
Appreciate all your replies m(__)m

I come to the conclusion that the device HACH PCX 2200 (corrected) is only expecting simple ASCII comms on serial line but not Modbus ASCII compatible. Because the PLC dosen't equip with a serial port so I think I have to go with other method then.

Besides, even I utilize the raw socket mechanism built in the Ethernet port, along with transparent mode, maybe I can get the commands trasmitted to the device, but it does not seem possible I can get the report data back, does it? The report data is basically ASCII characters, mostly numbers 0~9 and dots(.) and spaces, more or less.

Another thing to made clear is the bridge I use, it comes from a company based in China, however it has business abroad, check out the module here:
https://www.pusr.com/support/downloads/user-manual-usr-m511-user-manual.html
I think it's a pure protocol converter.
 
Hmm, the bridge does have an "AT Command Mode," which is probably for communicating with a dial-up modem to connect to the serial device, but it appears that would not be accessible from the PLC.

OP will need a different piece of hardware between the PLC and the HACH device.
 
There is a device from Anybus I am going to experiment with that claims to be able to speak plain ascii from an ETH I/P device. Its not available till october so I'm not certain it will be ascii enough.
 

Similar Topics

Hello PLC folks, I am using ControlLogix L74 v21 PLC and FTView Studio SE v10 in my current project. I have one engineering PC in which I hold...
Replies
0
Views
1,390
Dear Colleagues, Now I'm testing Rockwell-based control system that has been stored for 8 years. Have some major issue, that have not met before...
Replies
0
Views
1,134
Hi everyone! Hope you all are doing great! We have a really strange issue with comms between Wonderware and a controllogix L62, we use an...
Replies
4
Views
1,674
HI all. We have found a weird issue with our 1756-L72 controllogix processor. After it was opened the other day and closed, (we guess this is...
Replies
14
Views
3,509
Good day, I got a concern regarding the Redundancy setup. The problem is when communications get interrupted between the Primary PLC and the...
Replies
5
Views
3,664
Back
Top Bottom