[SOLVED] Modbus/TCP communications problems

[GHSP-tech]

I'm trying to get my T1K-EBC100 to work with a PLC from Opto22 via Modbus/TCP. So far all of the commands work except 15 (force multiple coils). I've worked with their tech support but have not been able to resolve the problem. At this point I'm making sure that I check all of the possible problem areas before digging any deeper, hence the inquiry here.

Here's what I know:

• If a coil is already set--either by another program or by funcion 05--the call to function 15 clears all of the coil bits, turning all the coils off.
• The tech at Opto22 was able to get one of their field I/O units (Opto22 brand) to work with the same Modbus/TCP function 15.
• Adjusting the number of coils (bit count), starting coil and other parameters in the control program has no effect.
• Packet sniffing on the network has turned up some interesting behavior from the PLC, namely a byte count of zero:

Code: [Select]

 Modbus/TCP
      transaction identifier: 1
      protocol identifier: 0
      length: 14
      unit identifier: 1
      Modbus
          function 15:  Force Multiple Coils
          reference number: 0
          bit count: 50
          byte count: 0
          Data

  0030  4b 1c 3b 62 00 00 00 01 00 00 00 0e 01 0f 00 00   K.;b............
  0040  00 32 00 03 00 00 00 00 00 00                     .2........

When I send function 15 from a LabVIEW ModbusTCP app, the byte count is non-zero and the coils behave as expected:

Code: [Select]

 Modbus/TCP
      transaction identifier: 0
      protocol identifier: 0
       length: 8
      unit identifier: 0
      Modbus
          function 15:  Force Multiple Coils
          reference number: 0
          bit count: 4
          byte count: 1
          Data

  0030  ff 04 bb 4e 00 00 00 00 00 00 00 08 00 0f 00 00   ...N............
  0040  00 04 01 01                                       ....

Is the implementation of the byte count field optional? That's the only difference that I can see between the two packets. The developer at Opto22 states that the library was developed against a standard Modbus device, and that they haven't had reports of this problem from other Modbus devices.

Both myself and the tech at Opto22 are stumped, so any input would be greatly appreciated.

*edit* Marked as solved.

[franji1]

Off the top of my head, a byte count of 0 is sounds completely wrong.  Also, the Unit ID should be 255 (0xFF) or possibly 0 (0x00).  Any other Unit ID implies that you are talking to a Modbus/TCP Gateway thru to multiple RTU devices, where the Unit ID is the specific RTU Unit ID.

The Opto 22 PLC is not sending valid data.  I would expect "has no effect" by the EBC100 is correct behavior since it is probably ignoring the packet given those two issues.

[GHSP-tech]

Success! After a bit of digging in the code, I found that the byte count was being generated but not being populated in the message string. One of the developers at Opto22 found the same solution, and now the field I/O works as expected with Modbus command 15.

The unit ID doesn't seem to affect the performance, but we're only using a single slave with the controller. Perhaps that could become a problem with multiple slaves on the same network?

[franji1]

After a bit of digging in the code, I found that the byte count was being generated but not being populated in the message string. One of the developers at Opto22 found the same solution, and now the field I/O works as expected with Modbus command 15.

Great!  Glad to hear you had help on the other side (it takes 2 to tango).