DF1 Half Duplex

When doing DF1 Half Duplex, you fill in the STN byte with the Node address of the CPU. What is the DST byte for? Where would you use this data?

Destination address, needed to route the data to proper location.

That's what I had gathered from what I have read so far but where you use this in example?
For example: If I am connected directly to a SLC5/03, what purpose would the DST byte have?

Route to where, from where? The CPU Node is already designated?

Jiri is far more knowledgeable in this area then I am but if not mistaken with DF1 half duplex it is a Slave-Master protocol that can have multiple processors.

It appears that DST (Destination Node) and SRC (Source Node) are expected pieces of information within an application message.

STN (Destination Station) is part of the half Duplex DF1 wrapper and is essentially a copy of DST. The STN doesn't appear in the Full Duplex wrapper as Full duplex (I believe) is a single node connection.

In essence, it seems that you would use this as a 'bridging' function, with the STN being the ID of the bridge and the DST being the ID of a device hanging off of the other side of the bridge.

But I am still trying to correlate this scenario to an actual AB hardware setup.

Bernie is exactly right that the STN byte is part of the Link Layer of the protocol, which just handles how data gets from one place to another. The Source (SRC) and Destination (DST) bytes are part of the Application Layer of the protocol, which handles how messages are executed and is the same in all of the older A-B "PCCC" networks.

Most of the time when you're using DF1 Half Duplex, you're not connected directly betwen a PC and a processor, or between two processors. DF1 Full Duplex provides better performance in those circumstances, which is why most point-to-point applications use it.

Master Polls and Master Commands use the Station (STN) byte to designate which of many possible (up to 254) listening DF1 Half Duplex stations should respond to a poll or command on the DF1 network.

The DST byte is used to determine which station should *execute* the command included in that packet.

The most important use for the different Station and Destination addresses is slave-to-slave messaging.

It works the same way as if two kids aren't talking to one another and demand that their Mom relay their messages. Even though each kid can hear the other one, they won't talk to one another but rather wait for the mother to repeat the data.

Inefficient, yes. But in a master-arbitrated system, it's the only way to go.

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.

Wow, interesting. I didn't catch that in the DF1 manual (which doesn't mean it's not in there...).
So when you setup a slave (Micrologix in your example) to send a MSG to another slave, the MSG instruction doesn't actually send a query on the wire since this could obviously collide with traffic already being exchanged with the Master and some other device, correct? It must somehow get embedded in the reply back to the Master directed to the other slave via the DST byte, right?
Does this not conflict with the Master's query and expected reply or is there some means of handling both situations?

DF1 Half Duplex slave devices only "speak when spoken to".

If they have a message command to send, they wait until the master device polls them and then send the message command to the master as a response.

If the message command is intended for the master, the master processes it and sends a "success" response for a Write command, or a "success, and here's the data your requested" response for a Read command.

If the message command is intended for another slave device, the master sends the message command to the other slave on behalf of the first slave. The reply from the second slave is likewise send back to the first slave by the master.

There are a lot of things I only understand in the DF1 protocol manual because I've seen them on the wire and had them parsed out by the FTE software.

Thanks for the info. That's good stuff.