Protocol Converters

rajy2r

Member
Join Date
Nov 2006
Location
Canada
Posts
167
I have looked at a few Modbus (i.e. Protocol Converters). Redlion DA10, Spectrum Controls Universal Gateway, Anybus Gateway or Prosoft.

They all essentially look the same for modbus and other protocols, so wondering if there is a benefit of using one over the other. The setups are fairly similar too.
 
I have looked at a few Modbus (i.e. Protocol Converters). Redlion DA10, Spectrum Controls Universal Gateway, Anybus Gateway or Prosoft.

They all essentially look the same for modbus and other protocols, so wondering if there is a benefit of using one over the other. The setups are fairly similar too.

For me it boils down to tech support. If you have a problem, can you get help.

Each has their own 'style' of implementation. After support, it's not a question of if it works, but if it fits into your application.

We have Anybus (not gateway, but separate systems - they sell to OEMs who put their equipment inside their product) and their support appears to be good.

We've used Prosoft for years. They have decent examples that actually work (they are tested as typed in and do actually work). Their tech support is good, although they can take a couple of days to get back to you based on how many people are calling. Creating a test system is obviously lower priority than fixing production systems.

I have no experience with the others.
 
They all essentially look the same for modbus and other protocols, so wondering if there is a benefit of using one over the other..

What are you doing with them? I dont know enough (yet) but we just started selling a serial to Ethernet Modbus adapter called MOXA MB3180, I need more time to play with them but so far they seem good. I know they cant do what some of the others can like the data stations but for a simple gateway...

https://www.plccable.com/moxa-mgate-mb3180-modbus-tcp-ethernet-serial-gateway-rs-232-422-485/


thingstodo said:
For me it boils down to tech support. If you have a problem, can you get help.

Great... im out :D
 
I have thought about protocol converters a little.
There are two main ways this can be done.
The most direct way is to strip off the header of the incoming packet and wrap a header that the destination PLC will understand. Then initiate the transfer to the destination PLC.


The second way would be to use a lot of memory as a scratch pad that all PLCs can write to and read from. In this case the PLC would need to initiate all the data transfers. The would also need to be a read modify write mutual exclusion ability to keep a PLC from reading data while another PLC is writing to the same place. Siemens calls this data consistency.


On top of the byte order of the source and destination must be known. Some PLCs use little endian and others used big endian. Modicon floating point uses big endian for 16 bit transfers but sends the low word first for 32 bit transfers. Odd.



Before buying I would ask how these situations are handled.


Our motion controller can translate between different Ethernet protocols. Data can be read or written from what we call the variable table. Each PLC, HMI gets its own connection that handles the little/big endian problem.


However, I would chose the first method of just changing the header and endianess if I wanted to just send data back and forth between different PLC protocols.
 
I have thought about protocol converters a little.


On top of the byte order of the source and destination must be known. Some PLCs use little endian and others used big endian. Modicon floating point uses big endian for 16 bit transfers but sends the low word first for 32 bit transfers. Odd.



However, I would chose the first method of just changing the header and endianess if I wanted to just send data back and forth between different PLC protocols.

Only thing to add is sometimes you have to swap nibbles or the lower and upper byte.

So swapping bytes and nibbles is a good feature to have in a protocol converter.
 
The configuration methods and tools make a difference in the device's ease of use and flexibility.

Red Lion has Crimson 3, which is probably the most flexible way to move data around, but has the steepest learning curve. The virtual HMI is a very useful feature as well.

Anybus Communicator is fairly straightforward, and their documentation in English and German is good. Their footprint is small and their hardware is durable and well engineered.

Spectrum's Universal Gateway uses a browser-based configuration. It's a relatively new product, and the chief application engineer is a Forum member.

Both the Spectrum Universal Gateway and the Real Time Automation gateways benefit from browser-based configuration that contributes to their ease of use.

Prosoft is the gold standard for reliability and backward compatibility, as they've been around the longest. Prosoft Configuration Builder is not modern and polished, but it keeps up with the times and features do get added. Some Prosoft devices can be configured entirely from within the PLC program.

If I was told "connect one Modbus RTU device to ControLogix, but your junior engineer has to do it and you can't help", I would reach for the Spectrum Universal Gateway.

If I was told (which I was, last year) "you need to connect an unknown serial protocol that was reverse-engineered ten years ago on a custom microcontroller, but you have to commit to the platform before you get any details", I would choose Red Lion.
 
What are you doing with them? I dont know enough (yet) but we just started selling a serial to Ethernet Modbus adapter called MOXA MB3180, I need more time to play with them but so far they seem good. I know they cant do what some of the others can like the data stations but for a simple gateway...

https://www.plccable.com/moxa-mgate-mb3180-modbus-tcp-ethernet-serial-gateway-rs-232-422-485/

Great... im out :D

I have used the MOXA MB3180 with a Contrologix and it definately did the job at a very cost effective price. I just found the Contrologix Code for Modbus to be confusing to setup initially.

I think for a few more dollars the other options are a bit better because of the ease of setup.

We do use the MOXA IOLOGIX E1240 units for remote IO and they work great.
 
Last edited:
For me it boils down to tech support. If you have a problem, can you get help.

Each has their own 'style' of implementation. After support, it's not a question of if it works, but if it fits into your application.

We have Anybus (not gateway, but separate systems - they sell to OEMs who put their equipment inside their product) and their support appears to be good.

We've used Prosoft for years. They have decent examples that actually work (they are tested as typed in and do actually work). Their tech support is good, although they can take a couple of days to get back to you based on how many people are calling. Creating a test system is obviously lower priority than fixing production systems.

I have no experience with the others.

Never used Anybus myself, but did use the Prosoft MVIE56 and agree with their support they make great products. Have heard good things about Anybus, perhaps will try on other projects.
 
I have thought about protocol converters a little.
There are two main ways this can be done.
The most direct way is to strip off the header of the incoming packet and wrap a header that the destination PLC will understand. Then initiate the transfer to the destination PLC.


The second way would be to use a lot of memory as a scratch pad that all PLCs can write to and read from. In this case the PLC would need to initiate all the data transfers. The would also need to be a read modify write mutual exclusion ability to keep a PLC from reading data while another PLC is writing to the same place. Siemens calls this data consistency.


On top of the byte order of the source and destination must be known. Some PLCs use little endian and others used big endian. Modicon floating point uses big endian for 16 bit transfers but sends the low word first for 32 bit transfers. Odd.



Before buying I would ask how these situations are handled.


Our motion controller can translate between different Ethernet protocols. Data can be read or written from what we call the variable table. Each PLC, HMI gets its own connection that handles the little/big endian problem.


However, I would chose the first method of just changing the header and endianess if I wanted to just send data back and forth between different PLC protocols.
Not aware of your motion controllers, but perhaps you can share some info.
 
The configuration methods and tools make a difference in the device's ease of use and flexibility.

Red Lion has Crimson 3, which is probably the most flexible way to move data around, but has the steepest learning curve. The virtual HMI is a very useful feature as well.

Anybus Communicator is fairly straightforward, and their documentation in English and German is good. Their footprint is small and their hardware is durable and well engineered.

Spectrum's Universal Gateway uses a browser-based configuration. It's a relatively new product, and the chief application engineer is a Forum member.

Both the Spectrum Universal Gateway and the Real Time Automation gateways benefit from browser-based configuration that contributes to their ease of use.

Prosoft is the gold standard for reliability and backward compatibility, as they've been around the longest. Prosoft Configuration Builder is not modern and polished, but it keeps up with the times and features do get added. Some Prosoft devices can be configured entirely from within the PLC program.

If I was told "connect one Modbus RTU device to ControLogix, but your junior engineer has to do it and you can't help", I would reach for the Spectrum Universal Gateway.

If I was told (which I was, last year) "you need to connect an unknown serial protocol that was reverse-engineered ten years ago on a custom microcontroller, but you have to commit to the platform before you get any details", I would choose Red Lion.

Thanks for the feedback. I used a RedLion DA30 on the last project with 4 different protocols and it has been great. It was a bit of learning as i hadn't use a RedLion product before, but with the virtual HMI, it worked very well.

I was looking for feedback before we standardize on a product.
 
I just found the Contrologix Code for Modbus to be confusing to setup initially.

I agree it's not great and quite confusing, but it also depends a bit on the application you need. If all you need is to read the same Modbus registers all the time, you can get away by having a fixed string you pump out to the modbus device (the data request) and parse the received data which is simpler than implementing the full blown modbus protocol.

I had some good results doing this on a L55 (or 61) via the serial port.
 
I agree it's not great and quite confusing, but it also depends a bit on the application you need. If all you need is to read the same Modbus registers all the time, you can get away by having a fixed string you pump out to the modbus device (the data request) and parse the received data which is simpler than implementing the full blown modbus protocol.

I had some good results doing this on a L55 (or 61) via the serial port.

That is very true. For the fraction of a cost it is a very functional unit.
 

Similar Topics

Can anyone recommend any reasonable types of 232 - 485 converters. I will eventually need 5, the drives I am talking to only have 232, but can...
Replies
10
Views
3,027
Hi all Trying to remotely connect to a TIA Portal PLC. I can ping it without a problem but can't get my software to connect. I've opened port...
Replies
8
Views
278
I’m working on getting a Parallel Redundancy Protocol PRP system set up in a lab situation. The L73 PLC is in rack 4. 3 io racks are 1,2,3. I...
Replies
6
Views
691
Does anyone have information or documentation regarding the protocol used in Rockwell's Remote IO, and how the physical layer of the network...
Replies
5
Views
877
Hi everyone, I've got to interface 4 x Mitsubishi Q series PLC's with an Allen Bradley Compact Logix PLC using a Red Lion Data Station DSPLE000...
Replies
1
Views
488
Back
Top Bottom