I resurrected this thread to mention a problem that my Fluke 125 helped solve today. A more expensive scope could have done the job, but my usual serial analysis tools didn't.
I had a MicroLogix 1100 connected as a Modbus RTU Master to a compact third-party thermistor monitoring block.
It should have been easy: this device has a three-wire RS-485 interface and uses totally normal Modbus Function 03 (Holding Register Read) functions for all the data. The MicroLogix 1100 was equipped with a 1763-NC01 cable that connects its isolated three-wire RS-485 port to a terminal block. 125 feet of good Belden 9841 shielded cable was connected.
Connected through a 1716-NET-AIC isolator, the PC software utility that comes with the thermistor block could communicate with it, but the MicroLogix couldn't. We were absolutely positively, totally certain that the Modbus addressing parameters were right in RSLogix 500. We tried a Modbus RTU master simulator (ModSim32), and it worked fine as well.
I connected a passive serial analyzer and the protocol looked just fine; the device was correctly responding, protocolwise, to the MicroLogix RTU Master poll, but the MicroLogix was still generating a Timeout error on the message instruction.
Finally it was time for the big guns; out came the Fluke 125.
Here's what the data capture looked like, at 5 ms/div capture so you can see both the poll and response:
What's the deal, we wondered, with the short response, then the approximately 7 millisecond delay, then the rest of the response ? Other Modbus RTU devices we tried didn't do that.
We zoomed in and examined the first data packet of the response.
A Modbus RTU poll response begins with the slave node address, the function code, and the response data length in bytes, followed by the response data and the CRC checksum.
When you get a close enough look at the data packet with the scope, you can pick out the Start bits, the 8 data bits, and the Stop bits to see that this first short data packet consisted of the values 1, 3, and 64. Since I was polling for Modbus Node 1, with function code 3, for 32 words (64 bytes), that's the correct response before the actual data values.
I suspect that this little device doesn't have much CPU power, so it responds to the Modbus RTU poll with the first three bytes, then catches its breath for 7 milliseconds, then sends the reply data itself.
The Modbus RTU specification says that any idle space of more than 3.5 byte widths is considered the end of the frame and the beginning of another. The MicroLogix serial port in Modbus RTU Master mode has an Inter-Character Time value you can set; the default value of 0 makes the port use the Modbus RTU 3.5 byte time. We incremented this value and found that a value of 10 milliseconds made communications between the MicroLogix 1100 and the analog block device work perfectly.
I was pretty sure I could solve almost any Modbus RTU or DF1 issue with my serial analyzers, but their timestamps aren't accurate enough to find this kind of delay inside a serial data string. The Fluke 125 (which did a good job showing the serial rate and max-min waveform values too) was an excellent tool for this troubleshooting issue.
