Koyo DL06 MODBUS RTU comms

A

Thread Starter

adrianp

What we have found is that we can successfully read from with the protocol convertor (albeit slowly). But when we want to write to the other slave on the modbus network, we have to unplug the protocol convertor.

As soon as we unplug it, we can communicate successfully.

Using 1 Koyo DL06 as a Master (node 2), 1 Koyo DL06 as a Slave (node 3) and a protocol convertor as another Slave (node 3).

Using standard timeouts on the Koyo.

Have tried crossing the comms wires.
 
A man cannot serve two masters. Nor MODBUS. Are you sure something like this isn't happening?

> What we have found is that we can successfully read from with the protocol convertor (albeit slowly). But when we
> want to write to the other slave on the modbus network, we have to unplug the protocol convertor.

> As soon as we unplug it, we can communicate successfully.
 
Good idea, but it is something else.

What we now realise is that only every other read (of the protocol convertor) is successful. The count of SP117 errors of the read is half that of the number of reads taking place.

I could live with the errors if it didn't slow the communications down so much. That 500ms delay is killing us.

All suggestions gratefully received.
 
Sounds like your protocol converter is slow to process packets and needs some additional scan delay between packets or transmissions from other devices. This can normally take 2 forms:

1. When the slave receives any packet (be it a request from the master or a response from a different slave on a 2-wire network), it must process the packet and determine if the packet it intended for it. If it does this too slowly and the packet was simply a response from the other slave, the next packet (possibly from the master to this slave) might be missed.

2. When the slave sends a response packet to the master, and if the next request is from the master to the same slave, and if the slave is slow to turn itself around for receiving data, then it may miss one or more starting bits of the subsequent request. This will trash the whole packet and the slave will not respond to it. But it is still receiving and therefore (after the timeout from the master) the next subsequent request will be successful. This is the most common scenario for seeing 50% success rates ("fast" master and "slow" slave). Try adding some scan delay on the master side to allow the slave to turn itself around for reception after it transmits a response packet.
 
Delaying the reads by 0.5 seconds cured the problem. It turns out that the protocol convertor has a bug in it and they are issuing a firmware upgrade.

Thanks for your help.
 
Top