DF1 data does not match.

If anyone can offer a thought on this I would appreciate it.
I have one of my remotes that will not complete a message over radio. I have captured from both ends and the radio is not a factor, its sends exactly what it receives but I can't determine why this is being sent this way.



The site on the left works every time, the one on the right shows a second series of 1006 opcodes (DLE/ACK).
This, or whatever is causing this, is apparently enough to make the MSG instruction fail every single time .
This repeats without change each time its polled.

Would anyone who still remembers this protocol well enough ( ahem...Ken Roach) care to offer a comment on what is going on here?

The link is 9600 Half Duplex - CRC
The path is: L81 PLC (ethernet) - Prosoft PLX-51 (DF1 Serial) - Radio - Radio - 1785-KE - PLC5
I have several identical others on this same AP that work just fine, just this one location fails like this.

.

It's been a long while since I did detailed DF1 Half Duplex. I always get out the 1770-6.5.16 Protocol Reference Manual, and in particular get out Page 6-2, the cheat sheet for DF1 Half Duplex command codes.

I noticed that the timestamps on the left column have milliseconds, while the right column has just whole seconds.

The time between the last reply from the slave and the ACK (10 06) by the master is about 115 milliseconds on the left.

On the right, it's... maybe a full second. Or maybe a fraction of a second. The "extra" ACK is in the next second timestamp but we really don't know.

Did you capture this with Frontline Test Equipment, or with the PLX51's built in packet capture, or something else ?


"Why would a DF1 Half Duplex Master send an extra ACK, since it hasn't received any messages from the slave" is a fine question.

The Prosoft PLX-51 is the DF1 Master in this system, correct ?


Slave devices Station 27 (left) and 17 (right) are both PLC-5's with a 1785-KE, correct ?

When you say the "MSG instruction fails", do you mean one in the PLC-5 or in the ControlLogix ?

[Update: fix a couple of typos]

Shot in the dark, but does DLE+ETX (0x1003, MSByte first) mean anything by itself?

Because that is being received at the end of the last received message on the right, so perhaps the DLE+ETX is somehow treated as a second received message, and acknowledged with a DLE/ACK?

I though the last nibble was a checksum (1b+e5 add up to a multiple of 256, as does 11+ef), but the longer messages do not work that way.

Hmm, all of the long message end with [1003 xxxx].

I noticed the missing milliseconds as well, I would imagine its a setting in the radio I will have to look for.
Here is the capture as the PLX software displays it. Maybe these timestamps give a better image.



I was warned by the engineer at Prosoft that this only captures complete data that it can properly format and not mangled data it can't. So I also captured directly from the radio ports which is what I show in the previous text image. It doesn't look like its missing anything but the Prosoft doesn't like something about it either.

The text capture in the previous post is from the radio ports using their CLI port capture utility. I also have wireshark captures that show a repeating TCP reset on this as well so the whole train is not happy. But its identical to others so why is this one behaving differently?

The PLX-51 is indeed the master at address 254

The failing MSG instruction is in the L81 PLC , the polling master.

Both 27 and 17 are PLC-5 with KE modules. One (the failing one) is an E model with the AUI port but I'm not using the ethernet part. There are multiple KE's in both stations and they have different addresses.

I have the KE manual in front of me which shows some HDX traces using "line monitor" and these examples don't match it either.
.


.

drbitboy: DF1 Half Duplex is from the era where wiretime was precious and uses the absolute minimum of checksum bytes.

An "ACK" command is just the actual command (10 06) with no checksum because it's always the same two bytes.

A "Start of Header" command (10 01) is followed by the Destination Station Number, but no checksum byte. It is always followed by the Start of Transmission (10 02).

A "Poll" command (10 05) is followed by the Station Number and a 1-byte checksum that is just the 2's complement of the Station Number.

A real PCCC command that starts with 1002 and ends with 1003 is followed by the actual DF1 protocol configured checksum type, which in this case is a two-byte CRC-16 checksum.

The protocol is full of tricky stuff like that.

Oh, that's fantastic stuff ! The more data the better.

While I'm scratching my head about why STN = DST in that invalid command frame and what it means, have a look at how you can figure out which commands and responses are related to each other because they have the same Transaction Sequence Word (TNS or TNSW):

Ok, the "Illegal Command" is the Prosoft device interpreting the actual STS byte, rather than saying "I don't know what this command means".

The commands highlighted in orange are decoded like this:


I don't know why the Destination and Reply are the same in this packet, or why it thinks it's replying (to itself ?) that it just got an illegal command. I will have to look at the rest of the packets more closely, particularly the Master's commands highlighted in white.

Maybe it's complaining about the extra DLE ACK (10 06) ?

Decoding DF1 by hand is a lot more complex than Modbus, which is why the guys at Frontline Test Equipment earn their money.

The longer commands from the Master, highlighted in White, are all a PLC-5 Typed Read command asking for N7:30, Length 10.

Are you 100% for absolutely certain that data table file N7 is at least 40 elements in length, so the PLC-5 can respond with the values of N7:30-39 ? It seems it would have to be, because the reply highlighted in green has 10 words of data in it.

I have an analyzer from FTE, but only one so I can't catch them together - these are miles apart. I can set it up on a location if that would help you.
It looks to me that the captured text based capture I provided in the beginning doesn't match what the Prosoft data displays

This disturbs me...
I see in the text capture :
1001
1006
1005
1002
1006
1006

But the Prosoft capture goes
1001
1006
1006
1005
1002
1006
1002
1006


I am not fully recovered from a cold so I wont be coming back tomorrow, but I can get it first thing Monday (unless it's the plague). Or if you insist I will come in tomorrow just for that capture. I'm desperate to get this explained and fixed. I am at your disposal.

.

I usually read your telemetry threads with interest, but they're so complicated I don't often dive all the way in. As I've said, I used to do this for a living so I know enough to be dangerous and love the troubleshooting challenge. But I don't want to hold myself out as the sure-fire guru and have you rely on me when I can't dedicate enough time to help.

Can you get a longer capture of data, in either format, from the working-correctly PLC-5 so we can compare them ?

You mentioned that "There are multiple KE's in both stations and they have different addresses."

Can you explain a little more about that ?

Are they all on the same DH+ network in the station, or connected to individual PLC-5 controllers instead of being networked together on DH+ ?

Are there any PLC-5's that are connected directly to a radio with their Channel 0 serial ports ?

Are there any 1785-KE modules that might have been decommissioned or disconnected from a DH+, but are still connected to a radio ?

WILD CONJECTURE:

The double -ACKs and the and the DST=SRC and the Illegal Command reply suggest that maybe there's a 1785-KE out there connected to the radio network and configured for Station 11 (octal), but it's not connected to any PLC-5.

1785-KE's generally pass a DF1 message through "transparently", to the PLC-5 whose DH+ Station address is the octal equivalent to the DST address in the DF1 packet.

The 1785-KE has its own DH+ Station address, which of course has to be different from all the other devices on the DH+ network. If a 1785-KE and a PLC-5 both had the same DH+ address, they would conflict and you would get a big obvious red light on the DH+ port and neither one would work.

If a 1785-KE receives a message to its own DH+ Station address, the only kinds it can understand are Diagnostic Counter or Configuration messages.

Again: it's wild conjecture, but the data you show is consistent with a DF1 radio network that has two devices at the same DF1 address, but one of them can't process a PLC-5 Data Table Read. The two apparently duplicate "10 06" ACK messages arrive exactly 30 or exactly 40 milliseconds apart.

I suppose the easy way to troubleshoot that would be to disconnect the PLC-5 you think your master is reading N7:30 from, and see if something else still responds (especially with that Illegal Command reply).

Sanity Check: DF1 Nodes versus DH+ Stations

I need a sanity check since it's been a while since I worked with PLC-5 and DH+. If I get something wrong below, or if your understanding is different, please tell me.

The DF1 protocol manual generally uses the word "node", while older DH+ manuals generally use the word "station". I think it's safe to say they are synonyms, but I tend to limit "Station" to DH+ because in my head that calls to mind the 1770-SC Station Connector boxes, or the RSLinx Station Diagnostics.

DF1 Node numbers are definitely decimal, 0 - 254.

The Master does have a node number (unlike Modbus). Often it's 0. In your case I think it's 254.

DH+ Station numbers are definitely octal, with sixty-four possible Station numbers between 00 and 77. I like to remind myself that they're not decimal by pronouncing the individual digits; "11" is "one one", not "eleven".

In the DF1 protocol analysis, we're looking at hex values in the data stream that address the 1785-KE modules as Stations 0x11 and 0x1b.

In decimal, those are DF1 Nodes 17 and 27.

I will do my best to refer to them either only by their DF1 Node numbers when we are discussing and analyzing the DF1 traffic, or explicitly as a "DF1 Node number" or a "DH+ Station number", or "DH+ Station number XX (octal)".

I just got a notification that my new oven arrived today ! Gonna get on home.

But before I go, today I learned that you can create a Custom cell format in Excel and manually type in "hh:mm:ss.000" and creates a millisecond timestamp you can do add/subtract on. Something new every day !

Here's the protocol capture from the Prosoft DF1 Master location, with annotations on the timing.

Do you think this suggests two different devices connected to the serial port of that Prosoft DF1 Master via radio with the same Station 11 (octal) address ?

What if this works only by coincidence because they're over radio, or on different DH+ networks that take different amounts of time (30-50 ms difference) to process a message. That could explain why they don't try to talk over one another by replying at the same time to the Master's messages.

I can't come up with a better guess about why there's that "Same Source and Destination" illegal command response than it's an orphan 1785-KE. A PLC-5 that didn't have N7:30-39 would respond correctly to the Master but probably a different error code.

Additional questions:

If you can provide a general arrangement diagram or description of the radio network, that would be great.

Is the Prosoft module a PLX51-DF1-ENI, or a PLX51-DF1-MSG ? My guess is that it's the MSG version.

Do you have logic in the ControlLogix that captures the Error codes from its Ethernet message to/through the PLX51 ? If so, what is the error code for the message to Node 17 that fails ?

Feel better soon !

TheWaterboy: What you mentioned as "disturbs you" is what makes me think there's a duplicate DF1 Node on the radio network.

Attached is another annotated screenshot comparing the timing and sequence of two data captures: left side is captured by the built-in data monitor of the PLX51 Master, right side is the output of the radio serial monitor feature at the Node 0x11 (17 decimal) Slave.

The two messages highlighted in purple are the ones I think are transmitted by the "duplicate" device, which is why they don't appear on the traffic captured at the remote radio you are examining.

What I cannot explain is why the timing seems off; you see the blue and green arrows that should be ordinary back-and-forth traffic that cross.

Maybe it has to do with how the radios key up and negotiate with one another, maybe it's to do with the speed at which the "duplicate" device replies compared to a 1785-KE that is routing a message to a PLC-5 over DH+ and getting a reply.

Also unexplained is why the "illegal command" message has the same Source and Destination bytes.

I could be completely barking up the wrong tree here, of course. I'd love to see what the Master traffic looks like if the DF1 Node 17 (PLC-5 DH+ Station 11 octal) gets disconnected at the 1785-KE serial port. If the "illegal command" message and the failed MSG instruction in the ControlLogix are still seen, then that suggests very strongly there has to be a duplicate DF1 node device on this radio network.

But I don't want to hold myself out as the sure-fire guru and have you rely on me when I can't dedicate enough time to help

Click to expand...

I reserve these direct appeals for when I have given up hope and need a bigger gun . I know you have an affinity for this and I also know you moved on to better and more interesting things, but sadly that's what most who know this stuff well have also done, so help at this depth this is difficult to find. Like these PLC's I myself am vintage so I can sympathize. Once this is worked out these PLC5's can begin to go away in favor of the 5380 and ethernet but till I get them talking well I cant start that process. AB support is unwilling to locate the elder statesman of DF1 assuming there is still one in their employ.

Can you get a longer capture of data, in either format, from the working-correctly PLC-5 so we can compare them ?

Click to expand...

Sent several things as PM. The Wireshark captures might not be a good thing to publish even with our new $80k firewall.

You mentioned that "There are multiple KE's in both stations and they have different addresses.Can you explain a little more about that ?

Click to expand...

There is an in use, fairly reliable but end of life radio (Esteem 192C) in place on one KE module (or direct to CH0) and the new radio (MDS Orbit MCR) is on a separate module. Each system is completely separate except of course for the remote PLC. Different freq, different polling PLC(a PLC5 on old one and an L81 on the new one) and different KE module with a different address (node, station, whatever ). I am assuming that the KE modules are "smart" enough to keep them separated. Maybe they arent?

Are they all on the same DH+ network in the station, or connected to individual PLC-5 controllers instead of being networked together on DH+ ?

Click to expand...

On the remote end: same PLC5, same DH+ network, all in the same 7 slot rack.

Are there any PLC-5's that are connected directly to a radio with their Channel 0 serial ports ?

Click to expand...

Not on this radio system, there are some on the old radio system and so there is a KE for the new system in the same rack.

Are there any 1785-KE modules that might have been decommissioned or disconnected from a DH+, but are still connected to a radio ?

Click to expand...

No chance of that.

The double -ACKs and the and the DST=SRC and the Illegal Command reply suggest that maybe there's a 1785-KE out there connected to the radio network and configured for Station 11 (octal), but it's not connected to any PLC-5.

Click to expand...

I can't argue, but I am not aware of it at all. And it only responds partially but repeatedly? How weird would that be.

The 1785-KE has its own DH+ Station address, which of course has to be different from all the other devices on the DH+ network. If a 1785-KE and a PLC-5 both had the same DH+ address, they would conflict and you would get a big obvious red light on the DH+ port and neither one would work.

Click to expand...

Thinking that I had KE problem on this location I tried 3 different rev C KE modules and they all created the flashing red DH+ light on the plc 5 when installed even though the addresses I set were the same as the one removed (always address 70 or above). I thought that was just a version conflict but since the original rev B version worked... well didn't cause a red LED... I left it in. . . . That gives me pause...

...The two apparently duplicate "10 06" ACK messages arrive exactly 30 or exactly 40 milliseconds apart.

Click to expand...

That would be the ACK timeout setting of the PLC51...

Again: it's wild conjecture, but the data you show is consistent with a DF1 radio network that has two devices at the same DF1 address

Click to expand...

Heres some more wild conjecture... Can the communication to/from a PV600 to/from its local PLC5 make its way across the radio network? All the PV600s are on the same DH+ network as thier radios and if they all have the same station address, which is very likely, could they inadvertently reach out... or be reached out to? i.e. if I have a PV with address 11h(17d) that is responding to something on the DH+ network intended for another PLC.

The Master does have a node number (unlike Modbus). Often it's 0. In your case I think it's 254.

Click to expand...

That is correct - 254.

I will do my best to refer to them either only by their DF1 Node numbers when we are discussing and analyzing the DF1 traffic, or explicitly as a "DF1 Node number" or a "DH+ Station number", or "DH+ Station number XX (octal)".

Click to expand...

The PLX51 requires a decimal address for the DF1 node address in its MSG, the PLC addresses are Octal and the Opcodes for the address are Hex. Makes this so much easier to trace doesnt it.

I just got a notification that my new oven arrived today ! Gonna get on home.

Click to expand...

A nice 6 burner Viking that requires a 1 inch gas line?

If you can provide a general arrangement diagram or description of the radio network, that would be great.

Click to expand...

Polling Master (L81) - Ethernet fabric - Hilltop - PLX-51 ENI - MSD Orbit MCR (Serial Port)- MCR Orbit MCR (Serial Port) - 1785 KE - PLC5

Is the Prosoft module a PLX51-DF1-ENI, or a PLX51-DF1-MSG ? My guess is that it's the MSG version.

Click to expand...

It's the ENI version in bridge mode.
Something to file away in your library is that the timestamps in the PLX51 are referenced to the boot time, not the RTC. Not a big deal when you are looking at a single transaction, but when you are trying to sort through a mess, an accurate timestamp would be really nice to have. So dumb...

Do you have logic in the ControlLogix that captures the Error codes from its Ethernet message to/through the PLX51 ? If so, what is the error code for the message to Node 17 that fails ?

Click to expand...

No but I can watch it live and its 16#001 and 16#0204 Connection Failure

I could be completely barking up the wrong tree here, of course. I'd love to see what the Master traffic looks like if the DF1 Node 17 (PLC-5 DH+ Station 11 octal) gets disconnected at the 1785-KE serial port. If the "illegal command" message and the failed MSG instruction in the ControlLogix are still seen, then that suggests very strongly there has to be a duplicate DF1 node device on this radio network.

Click to expand...

I will try that today and see where it takes me. You have given me some new thoughts I'll be back with whatever I find. If you glean any new info from the captures I sent, let me know. And again, many thanks for even stepping up.

.