Modbus TCP issues

Hello,

I've been struggling with this for a few days. I'm running a Micrologix 1400 Series B controller and I'm trying to connect via Modbus TCP to an Omega temperature controller. Their literature says that they do support Modbus, and I can successfully connect to the controller via Modbus Poll (free download).

However, I can't get it to work in RS Logix 500. The connection will time out on me. When I send the command, I see the yellow Tx light illuminate on the controller, but the green Rx light never turns on.

When connected in Modbus poll, I see the Rx light illuminate whenever the Tx illuminates.

Attached is my .RSS file and some screen shots. I'm fairly certain it's configured properly. Note that I've tried many different addresses unsuccessfully. And I'm 100% certain the device IP and port addresses are correct (since I can connect via Modbus poll).

Ideas?

In Modbus Poll, you're only reading a single register.

In the MicroLogix, you're reading 11 registers.

Try also changing the Unit ID in the MSG instruction to 0 or 1. I've worked with Modbus/TCP devices in the past that had a problem with Unit ID 255.

The Unit ID in your Modbus Poll frame is Unit 1.

You're correct using the Modbus address "40040" to get the offset byte 0x27.

The document I grabbed to refresh my memory on Unit ID's was this one from Acromag, via Prosoft.

http://www.prosoft-technology.com/kb/assets/intro_modbustcp.pdf

Also: Welcome to the Forum. Your first post was packed with concise but detailed information, references and examples. Stick around !

First get a copy of ModScan. It's indispensable. Use it to check the communications with the Omega controller. Once that's done the rest should be self-explanatory.

Good luck,

Yosi

Thanks, Gents. Unfortunately I'm still stuck. I tried a couple of different unit identifiers. Ken, in the manual you posted I see that the unit identifier should only matter in an RTU/serial application. Seems like it's ignored across TCP (p. 5)?

Yosi, the Modscan looks very similar to Modbus Poll that I was using before. I can see the traffic through each application. I was wondering if there's a way I could get it to listen to the PLC rather than my controller? How would I do that?

I tried to have the MSG instruction send to my PC LAN IP address, and the Modbus application listen to the PLC IP address, but this didn't work.

-Keith

Haven't worked with Micro in quite awhile, but what fires B3:7/0 to begin the message instruction?

I'm just toggling B3:7/0 manually for now.

Anyone know how Micrologix forms the string to send to the slave device? If using CIP messaging, it'll use the data entered in the MSG instruction and put it into an RIX data file. For Modbus TCP it requires an RI data file, but when I look in the data table it only contains the IP addres and port number (in hex). It doesn't contain anything else like the slave ID, function code etc.

Yesterday I found a bug in the CIP messaging where if the Attribute ID is >99, Micrologix won't allow it. To get around this I had to manually issue a MOV command to put different values in the RIX data file.

Maybe something similar is going on here with Modbus??

Sometimes the only thing to do is get down and dirty with a protocol analyzer.

Fortunately Modbus/TCP is easy to analyze with Wireshark.

Install and run Wireshark on your PC and capture the traffic from Modbus Poll to give yourself a reference on what works.

Capturing the traffic from the MicroLogix is a little more complex; you will need an old-fashioned Ethernet Hub, or a managed switch with a mirrored port.

The fact that your Modbus Poll couldn't accept the message from the MicroLogix 1400 is a little worrisome, as it opens the possibility that the MicroLogix has something generally wrong in its network configuration.

The backup method for proving out the MicroLogix 1400's functionality is to run your Modbus/TCP utility and point the message at your PC. I've done this before with the slave version of ModScan32 (um.. ModSim).

Hey Ken,

Thanks for the idea. Wireshark is brand new to me, so please forgive my ignorance. I think I do see something interesting, however.

When doing the normal Modbus Poll to Omega, I see normal back and forth communication. When I tried the same thing with the PLC, I see that it times out in the PLC as normal, but in capture #4495 it appears that it's trying to go to the wrong IP (192.168.1.255 rather than what I want, 192.168.1.4).

Any ideas here?

Again including my .RSS file (LAD 20) and the two Wireshark captures.

Thanks!

No. 1660 shows Rockwell broadcasing.

Let's be sure we know the players:

192.168.1.1 MicroLogix 1400 Series B
192.168.1.3 Dell PC
192.168.1.4 Newport/Omega controller


The "MicroLogix to Omega" capture shows unusual traffic, with the Dell PC querying the identity of the MicroLogix every few milliseconds.

Normal RSWho browsing sends a packet like that every 1 second. So having it hammer the MicroLogix like that is weird.

Frame 4495 is your Dell PC sending a UDP packet to a broadcast address. This is probably some unrelated discovery protocol.

Frame 1660 is an ordinary ARP command... I'm not sure what it means in this context.

Could you try changing the MicroLogix IP address to something other than 192.168.1.1 ?

I'm concerned because that's very often the Default Gateway address for this private subnet, and there might be some conflict with the MicroLogix getting traffic that's supposed to go to a network gateway.

As far as I can see, the Modbus/TCP message is never even getting started from that MicroLogix; it's not even attempting to open a TCP connection to Port 502.

When you took these captures, were you connected to the MicroLogix over RS-232, or over Ethernet ?

Players are correct.

I'm communicating over Ethernet, through AB 1783-US8T Stratix 2000 unmanaged switch.

Changed IP address/RSLinx driver to 192.168.1.10 and get same results.

The Error code is pretty generic, d9
"Reply not received before user specified timeout"

New Wireshark file.

I know it's trying to send something because my amber Tx light lights up on the Omega controller.