Application Note

ManualsBrandsFluke ManualsPortable OscilloscopesFluke 123

Application Note

From the Fluke Digital Library @ www.fluke.com/library

Ken Roach is a technical

consultant for Rockwell Auto-

mation. He works from the

company’s Seattle office and

supports that office’s sales

engineers and managers in the

installation of Rockwell Auto-

mation’s advanced products.

“They know how to sell them.

They know how to price them.

I know how to plug them in

and make them work,” Roach

explains.

Roach recently solved a

perplexing Modbus RS-485

communications-timing

problem using a Fluke 125

ScopeMeter test tool. The Fluke

125 is a battery-powered,

three-in-one instrument that

combines a 40 MHz digital

storage oscilloscope, two true-

RMS digital multimeters and a

dual input TrendPlot

™

recorder.

In particular, it includes an

automatic network health test

feature. “I often need to get

down to the signal level on

communication networks and

take a close look at the bits and

bytes that are going by on the

electronic level”, Roach reveals.

“That’s where we encountered

the Fluke 125 and its features

for troubleshooting industrial

control and communications

systems.”

The problem

Roach describes the situation

he faced this way: “I had an

Allen-Bradley MicroLogix 1100

Controller (PLC) connected as a

Modbus RTU (remote terminal

unit) master to a compact third-

party thermistor monitoring

block. Troubleshooting should

have been easy because the

What: Fluke 125 ScopeMeter

Test Tool

Tests: Modbus RS-485 health test

Who: Ken Roach, Technical

Consultant, Rockwell Automation

Testing Functions

Case Study

Fluke ScopeMeter

125

helps solve a Modbus

RS-485 timing problem

monitoring block has a three-

wire RS-485 interface and uses

totally normal Modbus Func-

tion 03 (Holding Register Read)

functions for all the data.”

The MicroLogix 1100 was

equipped with a 1763-NC01

cable that connected its

isolated three-wire RS-485

port to a terminal block. One

hundred-twenty-five feet of

Belden 9841 shielded cable

was then connected to the

thermistor monitoring block.

Connected through a

1716-NET-AIC isolator (an

RS-232 to RS-485 signal

converter), the PLC software

utility that comes with the

thermistor block could commu-

nicate with the block, but the

MicroLogix 1100 could not. “We

were certain that the Modbus

addressing parameters were

right in RSLogix 500 (the PLC

programming software), so we

tried a Modbus RTU master

simulator (ModSim32). It

worked fine,” Roach reveals.

Next, Roach connected a

passive, binary, serial analyzer,

and the analyzer showed

absolutely nothing wrong. “It

showed, byte one, byte two,

byte three, byte four, byte

five…,” Roach says. “The device

was responding correctly,

within the protocol, to the

MicroLogix RTU master poll

(request for information).” Still,

the PLC continued to gener-

ate a “Timeout” error on the

message instruction. In other

words, the poll was received

by the thermistor monitoring

block, but the PLC was timing

out during the response.

Summary of content (3 pages)

PAGE 1
Fluke ScopeMeter 125 helps solve a Modbus RS-485 timing problem ® Testing Functions Case Study Who: Ken Roach, Technical Consultant, Rockwell Automation What: Fluke 125 ScopeMeter® Test Tool Tests: Modbus RS-485 health test Application Note Ken Roach is a technical consultant for Rockwell Automation. He works from the company’s Seattle office and supports that office’s sales engineers and managers in the installation of Rockwell Automation’s advanced products. “They know how to sell them.
PAGE 2
The solution “My usual serial analysis tools didn’t do the job,” Roach explains, “so I turned to the Fluke 125. What it revealed that the serial analyzer had failed to reveal was a relatively long pause—about 7 milliseconds—between byte three and everything else. It was something that the customer pointed to right away and said, ‘What’s that?’” (See Figure 1.) 500ms/Div Figure 1. This data capture at 5 ms/div reveals both the poll and the response. Notice the delay of approximately 7 ms in the response.
PAGE 3
Conclusion A Modbus RTU poll response begins with the slave node address, the function code, and the response data length in bytes. Typically, these data are followed by the response data and the CRC checksum. A close look at the data packet in Figure 2 allows one to see that this first short data packet consisted of the values 1, 3, and 64. That is the correct response before the actual data values for the polling of Modbus Node 1 with function code 3 for 32 words (64 bytes).