I was troubleshooting a system last week in which an SLC-5/04 master was polling four MicroLogix 1000 slaves over leased-line modems. The MicroLogix controllers would periodically (every 30 seconds or so) send a MSG instruction back to the master.
The master was addressed as Node 3, and the slaves were Nodes 4,5,6 and 7.
One of the MicroLogix (#5) wasn't getting it's data back to the master. The Active Node bit for Node 5 was true in the master's Active Node Table, which meant it was communicating. But the data didn't show up in the master's data table.
While analyzing the traffic, I'd see the poll to Node 5, and I'd see Node 5's response with the MSG Write command. But then I'd see the MSG Write repeated on the network.
It took me a while to figure out what was going on. When the MicroLogix MSG instruction was written, the target node (this is the DST byte) was designated as Node 1. This is a pretty common node number for master stations, right ?
But remember this master station is Node 3. So the master was taking the MSG command that I thought was going to be processed by the master, and was re-transmitting it to a non-existent Node 1 becausee that's what the DST byte told it to do.
I've used DF1 slave-to-slave messaging in the past to go online with controllers miles away from my programming terminal. It's pretty handy, if you have the patience to tolerate the delays and if your original designer was wise enough to configure a low-bandwidth system like report-by-exception or periodic reporting.
A couple of years ago I invested in Frontline Test Equipment's suite of serial protocol analyzers. The price was a little steep (for me) but it has been the difference between success and failure in troubleshooting telemetry systems several times. It is very highly recommended if you do a lot of serial comms work.