Controllogix to RS232/RS485?

[danw]

Although the ASCII devices are not Modbus ASCII, you should be aware that Modbus ASCII uses a 7 bit word: one start bit, 7 data bits, a parity bit and 1 stop bit.

A couple of vendor app programs that I have use 7 bit ASCII as well, and this aspect becomes an issue when Hyperterminal is used because Hyperterminal does not save the correct comm setup when 7 bit is used. When Hyperterminal is closed and re-opened with a saved setup, it won't communicate with a 7 bit ASCII device because it re-launches configured for 8 bit data words.

All that verbiage because you have a single serial port on the CLX which (presumably) can only accept one set of comm parameters (baud rate, bits/word, parity). Mixing 7 bit and 8 bit words on the same serial line is not doable. The Modbus RTU device will not recognize the 7 bit words and the ASCII enabled devices probably won't recognize the 8 bit words.

But you can prove this true or false by connecting to each device individually with the 'wrong' bits/word setting and see if cmnom works.

 

[Ken Roach]

Neither fish nor fowl

I went back and re-read the part of your original post where you mentioned wanting to put all the devices onto a single RS485 line, so now your comments about multidrop and protocol mixing make more sense to me.

Shall we call these the "PSG Gauge" and "BCG TripleGauge" protocols, so we keep them straight ?

I only read the booklets briefly, but I'll make some comments.

The PSG Gauge protocol is similar to Modbus. It has an address, a length byte, a function code, and a 16-bit CRC. It appears to work on a simple query-response basis. But it's definitely not Modbus.

The BCG TripleGauge protocol is simpler. It just blasts out a 9-byte status data string every 20 milliseconds, and accepts a 5-byte command packet. The packet has a fixed header byte that doubles as a length value, and uses a simple "add the bytes" checksum.

Neither of these are ASCII. The data is never represented by the values of ASCII text characters that represent digits. And Carriage Return or Line Feed values are not used to terminate the data frames.

 

[Ken Roach]

The A-B 1734-232ASC or -485ASC modules are good with data that has CR or LF or some other non-text delimiter. And they're OK with data that has a fixed length, like the BCG TripleGauge protocol.

What they are not good at is handling incoming data that has a variable length and no fixed delimiter, like the PSG Gauge protocol.

If this were my system, I would carefully consider the HMS Fieldbus "Communicator", model AB7007.

The Communicator is halfway between being a "configurable" versus a "programmable" device. You set up protocol decoders that define certain bytes with a certain meaning and it handles manipulating the data, calculating the checksums, and putting the data into the I/O object for the ControlLogix.

It supports both CRC and simple "LRC" checksums. It handles fixed and variable data lengths. It comes with a "Modbus Wizard" when you really do want to run Modbus protocols.

Of course I'm a little biased; I have one here on my desk I'm using to implement a protocol I failed to do with the 1734-485ASC because of the variable length data field. I had made my original choice before learning the protocol details.

 

[NetNathan]

Ken,

Thanks for all you investigating.
I have looked at the HMS "Communicator" and the other "Anybus" components.
I have also looked at the RTA gateway products and they seem very nice.

They have an Ethernet/IP to ASCII module that supports 2 RS232 ASCII ports (435NBX).
http://www.rtaautomation.com/products/435/pdf/435NBXUserGuide.pdf

They also have Ethernet/IP to Modbus (460ETCMM)
http://www.rtaautomation.com/products/460/pdf/460ETCMM_Datasheet.pdf

The advantage, from a user perspective, with the 435NBX and 460ETCMM is the connection to the PLC. They won’t be in the scan list or IO tree of the PLC. The gateways will directly push and pull data from the user defined tags with no messaging instruction needed. They are also configured from their web page.

 

[Ken Roach]

Serial is not necessarily ASCII

The problem I see with the RTA units is the same as with the A-B POINT modules: neither of these protocols are ASCII nor Modbus, so the devices intended to handle those protocols may have trouble with string delimiting or timing.

If you wanted to take advantage of the checksum in the protocol, you would have to calculate it yourself in ladder logic. I have examples but it's not an easy task.

For real ASCII string applications, like barcode readers, the RTA gateways are runaway favorites for ease-of-use.

But for binary protocols like these, I like the HMS Communicator's "protocol builder" features.

 

[NetNathan]

The problem I see with the RTA units is the same as with the A-B POINT modules: neither of these protocols are ASCII nor Modbus, so the devices intended to handle those protocols may have trouble with string delimiting or timing.

If you wanted to take advantage of the checksum in the protocol, you would have to calculate it yourself in ladder logic. I have examples but it's not an easy task.

For real ASCII string applications, like barcode readers, the RTA gateways are runaway favorites for ease-of-use.

But for binary protocols like these, I like the HMS Communicator's "protocol builder" features.

RTA was a big help. After I sent them the manuals and he said the RS232 is not pure ASCII and their gateway would not work without special engineering.

I asked him about the HMS Communicator and his response:

"The Communicator device is much better suited to this application. It allows you to implement custom protocols.
I don’t know how much work that will be for you but it is the right solution to start with.
I’d love to sell you something but I am not built for this application."


So, in the end, you were correct on the HMS unit and I thank you for that.
Now all I have to do is figure out how t get the HMS unit up and running (The RTA unit seemed to be a slam dunk to set up.)

I am glad I sent the manuals to this site and to RTA. Otherwise I would have been screwed when I tried to make the RTA unit talk to the devices.

 

[jdbrandt]

In the Controllogix system I am doing for a vacuum furnace.....
I have 2 devices that only have RS232 for communications and 1 that is only Modbus RTU on RS485.
I am planning on buying (2) RS232 to RS485 serial converters for the RS232 devices so I can have all devices talking RS485 on 1 line.

Don't want to sound too dumb here, but I have never done Modbus RTU only Modbus TCP.

Will I have an issue with the Modbus communication to the RS485 device? If I talk ASCII to the other devices will i be able to talk Modbus RTU to the other device?

Now to talk Controllogix to serial RS485 and/or Modbus RTU.

The 1734 RS485 Point IO module I was going to use, I now find is for Devicenet only and will not talk ASCII.

Any Ideas....I am using Ethernet/IP between all my Controllogix devices, VFD, and 1734 Point IO racks, so that is my preferred method of comms.

Should I just go to Anybus and get an Ethernet/IP to ASCII gateway?
I heard Anybus makes good products.

Has anybody used *******'s "Devicemaster UP" gateway?
http://www.*******.com/pub/en/ethernet-ip-to-serial-device-communications


Maybe someone has a better idea?

IF Rockwell is the pre-approved way to go, be advised that the 1769-SM2 module has the capability to talk MODBUS RTU. That said, the -SM2 is primarily a 'Drives Division' card, that for the MODBUS Master usage, you're kind of on your own. It does work (*). Look at the AB Forum and KB for particulars.
Another piece of advise: use some kind of isolation devices between anything and everything. You'll be glad you did. And, with all these exchanges, its nice to have a RS232 analyser,. Everybody has their favorites, but I use CommFront. And, a MODBUS simulator will go a long way... Chipkin's is free, and super useful.
Good luck.