As Ethernet becomes more and more prevalent in industrial control networks, we find many times it’s easier to convert older serial protocols to TCP/IP and get them across the plant floor. Sometimes if it’s part of a larger project we can perform the conversion with a PLC. Other times it’s just easier to throw a dedicated device in and be done with it. Today we’re going to look at the Stride Modbus TCP to RTU/ASCII Gateway from Automation Direct.
As we lay the groundwork for this review I would like to state up front this is a purely functional review: Does it perform what it is intended to do. Here at IEI Labs we perform several reviews depending on the need. In this case we are looking at a single application device and as such warrants a simple functional only review.
As with all things here at IEI Labs, the first thing we do is set up a representative system so we can “burn it in” and run it through it’s paces. This gives us a chance to fully test the device in a controlled environment before it’s deployed where failure generally isn’t an option. We go to great lengths to replicate the production environment in the lab to fully vet the device under test. So on with the review…
The device under test or review is:
Automation Direct Stride Modbus Gateway
Model SGW-MB1511-T
S/N: K10A0005A190500024
Firmware Version: V3.5.012
As a summary, the notable features of the Stride Modbus Gateway are as follows:
- Converts from Modbus TCP to RTU ASCII or vice-versa.
- Metal Housing
- Wide temperature rating
- Din rail mount
- Supports RS-232/422/485.
- DIP switch selectable termination resistor for RS-485.
- Supports up to 16 TCP devices, client or server.
- Supports up to 128 slaves devices or 1 master device.
- Programming through web interface on the ethernet port.
Note there is a similar device that is sold by Automation Direct that comes in a plastic case. This review does not apply to that device. As is typical from Automation Direct this is a well built device. The programming and configuration is performed through a web interface on the Ethernet port. It’s a simple but functional interface that gets the job done. The manual available on the product page is clear and easy to navigate.
The gateway has 2 modes of operation: Transparent or Agent Mode.
- Transparent Mode: The polling device Modbus register read or write request is directly translated to either a Modbus TCP or RTU request. The data request is simply passed through the device. In this mode if a register isn’t being polled the gateway isn’t doing anything.
- Agent Mode: The gateway is performing the polling automatically and is storing the data in the gateway memory. The polling device register read request is then replied to from the gateway and not directly from the end device. This speeds up the polling but comes at a cost as covered later in the review.
Since the gateway can operate as either a master or a slave this leads to four operating modes:
- Transparent mode with serial port functioning as a master
- Transparent mode with serial port functioning as a slave
- Agent mode with serial port functioning as a master
- Agent mode with serial port functioning as a slave
The configuration of the various modes and ports is straight forward. The transparent mode settings whether configured as a master or slave are intuitive and operated as expected. You bind a serial port slave or master ID to the ethernet port and it passes the data request through. As expected there is a slight delay introduced since the conversion needs to take place and the request sent on the converted medium.
The agent mode introduces some new terms to the polling process. Since the gateway will be performing the register reads automatically a map needs to be defined that links the registers to be polled to those being requested. This is done through the message list menu option. Essentially an alias is created that defines the serial port, slave or master ID, modbus function code number, the start of the data address and length of data to read. A new term, the mapping address head is the internal address of the gateway where that data is stored. The web interface includes a function to continually monitor the data that is stored in the gateway internal memory.
Test Configuration
In the lab several tests were configured to fully test each of the 4 operating modes. This was accomplished through 2 different test beds:
- Direct Wire – The PLC registers were polled by VTScada through the gateway. VTScada was configured on the ethernet port and the PLC was configured as RS-485 on the serial port. The terminating resistor was used through the dip switch.
- Wireless – The PLC polled the registers on the ICP DAS WF-2060 I/O module. The PLC was configured as RS-485 on the serial port and the WF-2060 on the ethernet port through the gateway. VTScada polled the PLC directly on the ethernet port, this was separated from the gateway polling.
Long Term Test Configuration
A 4 week test was run using test bed 2 with the gateway in agent mode. The agent poll rate was set to 1 second and the PLC poll rate was also set to 1 second.
Results
Transparent Mode
Everything operated as expected in the transparent mode, data requests simply passed through the gateway. There is a delay that was noticeable only when polling through the wireless I/O module. When polling at less than 1 sec, the card would buffer up the requests until eventually the buffer filled and the card would reboot. This was no fault of the gateway.
If the device being polled whether wired or wireless would disappear (power fail, reboot) the polling device would report a lost connection. This is a nice feature as an alarm or some notification could then be generated.
Agent Mode
The agent mode is really to speed up the polling process, removing the need to pass through the gateway. The gateway can theoretically poll up to 100ms in agent mode though it was only tested to 500ms. The polling device could then poll at any rate and expect “fresh” data as long as the rate was greater than the agent polling interval.
If the device being polled whether wired or wireless would disappear (power fail, reboot) the gateway would perform a “hold last” value in response. This in turn would result in the polling device to continue to read the same value with no indication the polled device is gone. In this case the data would be “stale” and if performing a critical function would be erroneous. This is a serious flaw that prevents this mode from being used in all but the simplest of applications.
Summary
The Stride Modbus Gateway is a single application device that converts either way from Modbus TCP to Modbus RTU or ASCII. The gateway was easy to program and configure. It offers two modes of operation: Transparent and Agent. Transparent mode worked as advertised with no issues. Agent mode has a serious design flaw in that it provides no mechanism to indicate to the polling device that the polled device has been lost and that the data is erroneous. This could be done by providing a register that indicates the connection status of the agent. The polling device could then read this value and determine the status of the agent connection and react accordingly.
Materials Used
- Automation Direct Stride Modbus Gateway SGW-MB1511-T.
- Schneider PLC Modicon TM241CE24T with Ethernet, RS-232, RS-485
- ICP DAS WF-2060 Wireless I/O Module
- Trihedral VTScada Software