Given that RS 485 is nothing but a differential mode classic RS 232 link, it should be fairly easy to use a scope and look at every byte sent at a time and get the address from that information. Or use a modern scope with serial decoding. Easier and usually more reliable. And dirt cheap. You can use one of the lowest cost Rigol scopes. Or something similar.

I assume that you are familiar with the restrictions re common mode voltage and such things. If a unit fails to communicate, the reason quite often is a problem with ground connection between the units. A violent violence, so to speak, of the restrictions can also be the reason why your drive's RS 485 interface got damaged.

Are the units solidly tied to common ground? Not only via the RS 485 cable.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

1. I'm too lazy to read the drive manual to determine how the slave node ID is established - software programming or hardware. Many devices still use a physical means of setting the serial communication settings: slave ID, baud rate and parity. If this series of drives uses physical means, then find the rotary/DIP switches or the jumpers and determine the selections.

2. Physically search the area around the drive for a label indicating the slave node ID. I've been known to put adhesive labels on the slaves with the serial setup data (drive ID, baud rate and parity), when it's not mechanical switch or jumper selected. When you're done fixing this, you might attach a label with the critical comm settings to each of the drives, for the next guy.

3. If the drive's RS-485 port is bad, then the faulty drive can not return an exception/error code, so in the absence of a reply the Modbus master has to time out. I'd look for a Modbus comm error log to see which slave node ID is causing the time-outs.

4. There are Windows communications sniffer programs that sniff the traffic and display it. They sell adapters to tap into the 485 line.

Watching the traffic come to a halt as the master times out is one way, then seeing which slave is not responding.

5. Read through the TouchScreen Modbus master code to determine what the slave IDs are for the devices its talking to.

6. The Modbus Function Code 11(hex, 17 decimal) that is called "report slave ID" does not report the RS-485 multidrop slave node ID, rather it reports the manufacturer assigned code for specific device type.

Thanks for the swift responses people.

Ok with regards to the oscilloscope i am not in possession of a scope however if it is the last resort i will look into purchasing one.
Now with regards to the communication failure, the drive itself is damaged meaning; it is not showing any indication of powering on (via power LED) even though rated voltage is present at it's supply terminals. I have also connected the LC11 programming interface and am getting no display; so that VFD unit is totally shot.
with regards to the grounding question the interconnecting RS-485 cables have no shielding or grounding. Only 2 wires are used.

I have reviewed the drive programming literature and can determine that the slave address is a Parameter that can be set using the LC11 programming interface (within the range of 1-247), It is not set via DIP switches.
I have also inspected all the drives and there is no tag pertaining to slave addresses (there are 3 slave devices and 1 master).

I have come up with a plan and would like some advice on whether it is a viable option;
There are 3 slave devices 2 of which are functional and 1 is non functional. I do not readily have at my disposal any device which will allow me to sniff the RS-485 communication data, however i plan to use the LC11 programming interface keypad to navigate through the parameters of the 2 presently functional VFD's and identify their respective Slave addresses.
Since i am not getting anything on the LC11 programming interface for the damaged VFD it is impossible to upload the programming parameters from the VFD to the LC11 and copy over to the replacement.
I am going on the premise that the Chinese builder (hopefully) used sequential slave addresses. Theoretically if i get the present slave addresses of the functional ones to be 3 and 4 then I intend to program the replacement VFD with the slave address 2 initially, and if unsuccessful i intend to use the address 4. Can anyone see any potential issues with my intended course of action?

Sounds like a good plan to me. It’s a reasonable sssumption that the nodes are sequential addresses.

Whilst companies like IFTools provide very good RS485 sniffers, there's nothing stopping you from using an RS485-USB device and some sort of terminal console (I'm not sure if Hyperterminal is still supported on Windows machines, PuTTY might work) to sniff the packets from the HMI. This will at least give you the range of Modbus device addresses in use, and hopefully you can work out the dead drive's address in conjunction with the others.

FTDI makes a chipset commonly used for RS-485 to USB, probably the cheapest way of sniffing the RS485 line.

EDMS Australia

There's always the bray terminal (easy to find, just type the words). I use it frequently and it can do all sorts of tricks. Like outputting files in Hex or ASCII. Wide range of baud rates. I really like it. Even paid for it. But you don't have to. It is still free.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

If you have a RS-485 to 232 converter (assuming you have an RS-232 port on a PC), you can download a trial version of ModSIM. The ModSIM software will show the MODBUS communications and you can see the RTU IDs that are being polled.

The pick up a copy of Modbus Master
to test what you discover.

Keith Cress
kcress - http://www.flaminsystems.com

The program that runs this unit has an address in its configuration of IO over the network. The network configuration will have a address of each unit. Usually dip switches or dials are used to set addresses in drives usually on the comms module on the drive.

Multiple places to look for an address.

Thanks again for the assistance from all.
I was able to ascertain the slave address from documenting the communication parameters from the neighboring 2 VFDs (others being 2 and 3). I input 1 for the replacement drive and duplicated the remainder of communications settings and it worked.

Great! Thanks for the feed-back.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

Gunnar!!

I looked for Bray Terminal, and ended up losing hours of my life on this website: https://alternativeto.net/ Some really useful little applications in there.

Dammit Scotty!

Keith Cress
kcress - http://www.flaminsystems.com

As Gunnar says "Given that RS 485 is nothing but a differential mode classic RS 232 link "
I have often used a laptop with serial port in terminal mode to monitor communications.
I just forget how I connect it exactly but one of the RS-485 wires makes no sense at all, the other works well. it only takes a couple of minutes setting baud rate and No of bits etc.