hello everyone,

I need your help. i send modbus telegrams from Docklight to Modbus devices, but these devices do not reply.
parameters on devices are so set in this way:
9600 bps Baudrate, even parity.

Parameters in Docklight are set like:
9600 bps Baudrate, even parity, 1 stop bit, 8 data bits.

i can see the sent telegrams on the oscilloscope but nothing comes out from the modbus slaves.

i also have tried with all the available parameters but successless.

who can help?

thank a lot in advance.

 

The lack of any response indicates a likely lack of functioning communications hardware (assuming you are not testing your own Modbus master code).

I would suggest following Dr. Leo Marvin's advice: Baby Steps (What About Bob, 1991)

Baby Step 1
Do the slaves actually have Modbus?

Modbus is frequently an option and sometimes there's a connector without functioning hardware/firmware behind it. It pays to make sure that each individual slave is actually Modbus capable, that it has the hardware and firmware on-board and that the port is enabled for Modbus.

Baby Step 2
Protocol: RTU or ASCII?

You mention 8 bit data words which is Modbus RTU's word size. Are you sure the devices talk Modbus RTU and not Modbus ASCII, which uses 7 bit data words?

Baby Step 3
comm hardware layer
You don't mention which comm hardware you are using. RS-232 is point-to-point. RS-485 is multidrop. Are you using RS-485 for your multiple slaves? RS-232 will never communicate to multiple slaves.

Baby Step 4
You mention "Modbus devices", plural; that is, multiple or many.

Presumably they are all Modbus slaves, because Masters do not talk to Masters.

I strongly suggest connecting to a single slave only and getting communications working with that single slave before adding other slaves.

In fact, proving that communications works on a work bench with both the master and slave local to one another is useful before the slave is moved to a remote location at which point it is discovered that comm doesn't work for any of a number of reasons, but at least you know comm does work.

Problems that can occur over a distance that can stop 485 comm that are less likely to occur on a workbench:

- junction box issues, flooding, broken wires, mis-wiring, broken shield continuity, multiple shield ground points

- common mode ground loop

- noise on the data lines

- 2 wire RS-485 needs 3rd wire ground

- some implementations of 2 wire RS-485 use case/earth ground reference creating common mode issues

- stub/wye wiring (from multi-drop on the network to actual receiver) reflections create false data bits and errors
Multidrop issues

- incorrect termination resistor on one or more slaves that are not at the physical ends of the network

- bias

- excessive driver loading

- slave failure, long master time out

- replacement slave's node address duplicates another slave's node address

- one slave's failed driver (fails to tristate) can bring down the entire network

Baby Step 5
Modbus Master

The description of Docklight software on the Download.com site does not include the word Modbus. The description of Docklight is
"Docklight RS232 Terminal--RS232 Monitor is a development tool for serial communication protocols (RS232, RS485/422 and others). Docklight allows you to monitor the communication between two serial devices or to test the serial communication of a single device."

Docklight might parse for Modbus but I couldn't find the word Modbus on any of several pages of the Flachmann & Heggelbacher (publisher's) site.

If you are using Docklight because you are developing a Modbus master protocol, then all sorts of issues can arise. I'm not much help because I'm not a software developer, I'm a user.

If you a user and need to get your Modbus network running, then you might want to use a generic Modbus Master application, because a generic Modbus master does the grunt work of parsing a Master message properly, including generating a correct CRC or LRC value and usually provides some feedback like timeout or exception. WinTech's Modscan32, Simply Modbus or Modpoll are commonly used generic Modbus masters.

Baby Step 6

Check the 485 driver connections; 2 wire RS-485 A/B driver lines can be backwards

Different manufacturers label the (+)/(-) or A/B data lines one way, others label it the opposite. If (+) is not wired to (+) and (-) is not wired to (-), 485 will not work. Connecting backwards won't damage the drivers, but comm won't work. Try swapping A/B driver lines because they could be labeled opposite of one another.

Baby Step 7
Which slave are you addressing?

A Modbus slave is silent unless spoken to.

If the master does not address a particular slave, you'll never get a response from that slave. If there is no slave with a given address on the network there will be a response to a Master query to that slave address.

A message addressing slave 00 is broadcast message to which no slave will respond. So don't address slave 00.

Note that some slaves do not recognize a slave node address change unless power is cycled to the slave. (same thing can apply, needing a power cycle, to the serial comm parameters: baud rate/parity/word size

Baby Step 8
terminating resistors
I don't think I've ever had a master and a slave on the bench fail to communicate in the absence of terminating resistors.

Terminating resistors should be used for field installations, but I don't bother with them on the bench with 1m of cable between devices.

I once worked on a multidrop network that had never worked because terminating resistors were installed on each slave node, dragging down the drivers.

Baby Step 9
Master Polling

I strongly suggest attempting to read a known (non-zero) value before attempting to write data.

Make the master time-out at least 1 second. Some slave device processors just do not respond immediately to a poll.

Let us know what you find.

 

Correction: WinTech Modscan32, not WinZip.

 

Thank you a lot David,

the Docklight SW is the modbus master in my system.

so between the PC where Docklight is running and the Modbus there are two modules: usb to serial converter and a driver which converts the serial bus signal to modbus signal and also in the opposite direction. The problem was quite HW, the drive works in Half-duplex and need to be informed from the docklight, when to send and when to receive. so the docklight should be configured to give out a signal called RTS.

this signal will be transmitted over usb-serial bus to the driver in order to enable the transmitter while sending and to disable it while receiving.

this HW setup was missing in my first attempt. i just connected the TX/RX/ Gnd lines of the serial bus to the driver.

 

Yours was a great step by step procedure to find out where the problem was. I will save -treasure- this description for my usage, since I have found many of the problems described here. Thanks a lot for sharing.