How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

I doubt that will work. Modbus is an application layer protocol. You're counting on the gateway to see this EIA485 message *destined* for a particular Modbus "Unit ID" (i.e., address on the 485 wire) and decide that it should, instead, be routed *out* to the ethernet side of the fence. To do so, the address field of the message encountered by the gateway would have to reflect the gateway's modbus address/unit ID. This would require rewriting the message "in" the "loopback connector".

Just like looping an ethernet packet back through a router/switch won't guarantee that it gets *through* the router/switch!

On Fri, 20 Sep 2013 11:00:18 -0700, Klaus Kragelund wrote: [snip]

I would try and find a old PC with a parallel port. Install Linux and get the parallel port driver code and examples. These let you send data to the parallel port easily.

Craft a message on the PC for the controller. There are a variety of Linux and windows tools that can do this. Use a bit in the parallel port as a trigger. Turn on the trigger bit and push the packet out the wire. The app/kernel delay from trigger bit to packet hitting the wire is going to be in the low uSec range. You could compute time on the Ethernet cable but that time is going to be in your final product and small anyway.

Watch for the gateway to wiggle the RS485 signals. You could do it with a Intronix logicport analyzer or something similar.

Other option would be to take something like a Mbed dev board and some simple code. Use the Mbed to generate the Ethernet packet and to watch the 485 lines. Last time I used a Mbed it was OK for quick little projects like this.

[snip]

Pinging the box would give you a starting point. You could use something like hrPING or some other high resolution (uSec anyway) tool. That would tell you how fast the gateway can turn around a IP packet. I think the bigger issue is how long does it take to turn the IP packet into RS485.

--
Chisolm 
Republic of Texas 
Still raining, 5.75in last check

(Plenty of empty lines and some dicussion clipped)

IIRC, there is a ping command in Modbus protocol. Measure the signals at the sending Ethernet machine with Wireshark or tcpdump and scope the same on RS-485. You'll get the answer by a simple subtraction. If you want the total delay, the Ethernet trace is all you need.

--

Tauno Voipio

Full disclosure: I know nothing about Modbus. Googling for info on Modbus loopback, I find: Modbus® RTU Serial Communications User Manual which offers on Pg 9 and 20: RTU Function Code 08 Loopback Test. Used for diagnostic testing of the communications port.

3.6 Function Code 08 - Loopback Message Description Echoes received query message. Kinda looks like it has a suitable repeater (store and regurgitate).

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558

The real issue for ethernet to serial converters is how to split the serial stream to Ethernet packets. The naive approach would be to send one Ethernet package for each serial character, which is of course totally unacceptable.

In practice, you haver to assemble several characters to a frame and send a frame when the frame is full or the last character has been received. Some old converters waited more than 10 ms with no more serial characters, before sending the last Ethernet frame.

If the converter understands something about the serial frame, such knows what is the terminating character in the frame and then send the last Ethernet frame.

Serial Modbus RTU separates frames with an idle period at least 3.5 character times long, so that is the delay before sending the Ethernet frame. However, an idle period longer than 1.5 character times is illegal in Modbus, so you should wait at least that period of time, before sending the Ethernet frame. The upper level CRC check would then reject this frame, if such gaps exists within a message.

My experience with reasonable serial speeds (115k2 and below), modern eth/serial converters send that last frame quite rapidly and any internal processing delays within the gateway or Eth switches are small, compared to serial character times (100us@115k2) at reasonable serial speeds.

The situation was quite different 5-10 years ago, but these converters have improved considerably.

What is an RS-485 loopback adapter ?

I know what an RS-232 (connect pins 2 and 3) or RS-422 (Tx+ to Rx+ and Tx- to Rx-) loopback adapter is, but what is a 2 wire RS-485 adapter ?

Regarding loop back messages on RS-232/422, the Modbus function code 8 (Diagnostics) with subfunction 0 could be used, since it has the same bit pattern in both request and response, so it can be used in loopback tests.

What is your serial speed ?

In any half duplex protocols, such as Modbus RTU, the total throughput will increase by much less than a factor of 2, when doubling the line speed, due to various fixed delays, thus there is a diminishing return when increasing line speed.

I recommend splitting your serial Modbus slaves into several subnetworks, driven by separate Eth/serial converters driven in parallel by scanning programs. A 100BaseT backbone can easily handle the traffic from multiple serial networks. The cost of extra Eth/ser converters can be compensated by reduced RS-485 cabling costs, if the slaves are scattered around a larger area.

Modbus has a standard means to pack the frames into TCP transport (though UDP had been more suitable). The converters I know decode Modbus frames from serial line and forward them in the standard way in TCP transport, and the same to the other direction, of course.

--

Tauno Voipio

The Modbus protocol includes provisions for encapsulating a modbus message in an ethernet frame. The gateway just peels off the ethernet framing, then "interprets" the modbus message contained within -- and pushes it onto the wire (the gateway typically being a modbus master).

Modbus is much slower than a typical ethernet. So, there is a potential for the gateway to be overdriven by ethernet packets intended for the modbus network (unless you drive it synchronously).

Obviously doesn't make much sense in a 2-wire/simplex/HDX deployment.

Think: "4-wire"

But you still have to deal with the *addressing* issue.

Imagine trying to implement an ethernet ping by simply capturing the electrical signals on the wire and "playing them back" a short time later. (hint: they'd just be "seen" twice by the targeted node, not "returned" to the originator)

Yes, but you are no longer measuring the "delay through the gateway". Instead, you are measuring (twice) the delay through the gateway, the time up and down the stack in the "PC" that is talking to the gateway, the time to transmit the loopback message and its reply (8+8 characters @ < 38K baud =~= 4ms) plus the time inside the modbus slave to decode the message and schedule its reply (do you now have to "measure the processing delay in the targeted node"?)

An ethernet ping "works" because the transport delays are smaller (assuming no congestion in intermediate switches) and the ICMP echo servers *tend* to be written "down low" in the network stacks (instead of at the application layer).

The OP is essentially interested how many slaves can be served each second. Thus the total transaction delay (request+response) is critical.

With Modbus RTU, the master _must_ observe the 3.5 character delay between receiving a response from one slave, before sending a request to an other slave. Otherwise, any properly working slave on the bus is not able to recognize, if the next request is addressed to it, causing a timeout situation.

The original RS-422/485 standard recognize a 4 wire RS-485 configuration, in which the master has the transmitter constantly on (essentially RS-422), while each slave listens on one pair (the master Tx), but the slave only activates the transmitter when addressed and send the message to the master Rx pair. I have sometimes forced to use this configuration with badly behaving Modbus RTU slaves, since there are now huge gaps between requests on the master Tx pair.

A loopback test with non-zero (non-broadcast) and no slave connected to the gateway will simply return the same bit pattern.

Of course, any real slave is disconnected during such ping tests.

Of course this is true for any real Modbus RTU to Modbus/TCP I(UDP) converter.

However, any dumb Ethernet/serial converter (knowing nothing about Modbus or any other serial protocol) works surprisingly well, as long as the higher level protocol only relies on the request and response header and does not try to detect any interframe gaps.

For the master side, this is not a big problem, a large number of systems are running all over the world.

For the slave side, the situation is much more demanding.

Since Moxa has already been mentioned in this thread,the Moxa MB3000 series converters do exactly that.

However, any (dumb) garden variety Ethernet to serial converters can be used at the master side, provided that the message encoding is done by the message header and not by any inter frame gaps.

Yes, but I do not have access to the code.

I have full control of the bus, but it's pretty easy just to measure it

Not time critical, we just want to check the performance

Nothing specified

Cheers

Klaus

Our own unit. Measuring the start of the master transmission to the end of the telegram from the slave

That's primarily the delay of the microcontroller in the unit.

I did answer. From Ethernet->Gateway->Modbus RTU and vice versa

UC 7112. It's basically a Linux computer with 2 ethernet and 2 serial ports. The Modbus TCP/IP SW was loaded into this

I am trying to see how fast the system would react, so for example how fast a repetition rate can be used in a round robin system using the gateway.

Cheers

Klaus

That could be an idea, I am just worried the PC won't measure this correctly

Regards

Klaus

The old PC would do the trick since the 100Base T4 does not have idle signalling and the task is reduced to just plugging on a scope, what I initially thought would be the way to measure the delay

Cheers

Klaus