ML1400 Modbus to Epson Robot Issue

[Evan.rice44]

I am currently working on a project with an Epson Scara robot using an RC-90 controller communicating with a ML1400 Ser. B PLC. The robot controller comes with Modbus RTU and TCP standard so I decided to use a Micrologix instead of purchasing an Ethernet IP card and using a Compactlogix. I have tried to set the system up via Modbus TCP (using a MSG(following a method Bernie posted) to read then write using the DN bit of the read) but I can only get the PLC write to the robot and not Read. I the dealt with Epson tech support for hours but they were lost also, being that the problem seems to be on the PLC end. I downloaded a Modbus testing program (simply Modbus 8.1) to verify that and sure enough, the robot controller has no problem reading and writing to my PC.
I then tried to use Modbus RTU, thinking that would be easier to get SOMETHING working, I was wrong. I have tried changing everything I could think to do but I just cant seem to find what I'm doing wrong. I would really appreciate any help on this matter. I will post both programs (TCP setup, and RTU setup) and some screenshots on the robot setup environment.

Thanks Again

 

[Evan.rice44]

P.s.

I forgot to add, for all those who look at my logic and scratch their heads, I ended up having to use the MOV command before the read and after the read MSG to change the node number of the write message because I absolutely could not get it to read data from the Robot controller while the nodes were set the same. In fact, when the nodes were the same it would only read. When the read MSG was set correctly and the write MSG was set to 0 (zero) it would only write. Very confusing......

 

[Ken Roach]

I'm definitely scratching my head on this one. First, the Modbus RTU program.

In general, the MicroLogix 1400 doesn't use a buffer or queue for Modbus messages. They have to complete with a /DN or an /ER before you trigger the next one.

The .NOD element is the slave device address. The most common slave device address is 1. I don't think I've ever seen a slave device that responded to a device address of 0.

And remember you're changing the .NOD of the MG9:2 message control block, not the MG9:0 message control block. The first message (controlled by MG9:0 on Rung 1) is addressed to a slave at Node 10.

The logic as I read it will send Message 0 and Message 2, alternating, as fast as it gets responses. I don't tend to like doing that because it loads up the controller serial port, but in this case that port can't really do anything else so I suppose it's OK.

It makes no sense at all to me that you have a Modbus slave that appears to be responding to different slave messages. That's just not how they are supposed to work.

Is there more than one Modbus device on the serial network; i.e. is it an RS485 or other multidrop network ?

 

[Ken Roach]

On the Modbus/TCP side, the Unit Identifier is sometimes a challenge. I've had devices that would react differently depending on the function code (read vs write) and the Unit Identifier. One of them would respond to Reads only when the Unit Identifier was 255 (broadcast), but only to Writes when the Unit Identifier was 1.

With Modbus/TCP, the open source analysis program Wireshark is a fantastic diagnostic tool. You have to set up a hub (yes, a hub) or a switch with a mirror port if your PC isn't the source or destination of the traffic.

 

[Evan.rice44]

I'm definitely scratching my head on this one. First, the Modbus RTU program.

In general, the MicroLogix 1400 doesn't use a buffer or queue for Modbus messages. They have to complete with a /DN or an /ER before you trigger the next one.

1. That is how I understood it also. If you notice the way the logic is written, it does just that. The problem is if I dont change the node like I am doing, the scan just repeats because of an /ER bit after the specified timeout and never actually sends the message.

The .NOD element is the slave device address. The most common slave device address is 1. I don't think I've ever seen a slave device that responded to a device address of 0.

And remember you're changing the .NOD of the MG9:2 message control block, not the MG9:0 message control block. The first message (controlled by MG9:0 on Rung 1) is addressed to a slave at Node 10.

2. As for this part, I am changing the node for MG9:2 BEFORE MG9:0 because if I don't do this the i never actually get a /DN bit for MG9:0. I change the node MG9:2 back to a 0 (only after getting the /DN, not a /ER. This way it only writes if the read is sucessful) because if I don't, the write portion will timeout and give me an /ER and the whole thing repeats

The logic as I read it will send Message 0 and Message 2, alternating, as fast as it gets responses. I don't tend to like doing that because it loads up the controller serial port, but in this case that port can't really do anything else so I suppose it's OK.

It makes no sense at all to me that you have a Modbus slave that appears to be responding to different slave messages. That's just not how they are supposed to work.

3. I thought so also but I have tried everything else I could think of including changing the node on the robot controller to many different things with no luck.

Is there more than one Modbus device on the serial network; i.e. is it an RS485 or other multidrop network ?

4. Nope, this the only thing on that network. I am using the ethernet port to communicate with and monitor the plc and I'm using usb to do the same on the robot controller.

Normally both the read and write message would be using the exact same node address correct? As long as it is the correct address the slave is set at?