Can an L82 send a msg out of the serial port of an L61?

OK here's an nice twist to this.
I connected a cellular modem to the remote ML1400 so I can see the serial channel diagnostics from the remote site.

Using DF1 Radio modem protocol (just to minimize traffic) I can see the "messages received" and "messages sent" counter increment perfectly each time I send a request from the source.

So... it seems that the remote is seeing the request and responding to it, but it's not getting back to to the source. Whiskey Tango Foxtrot ? Radio must be the issue - that packet trace led me astray.

I'm scratching my head about why you see "DLE ENQ" = 10 05, described in the NetDecoder as "master enquiry", by itself.

DLE ENQ is in fact a "master enquiry" more commonly called a "Poll".

In Half Duplex, it is always followed by two more bytes, the Slave Station Address and a 1-byte BCC error check. Even if you are using CRC error checking for everything else, the DLE ENQ has a 1-byte error check.

A DF1 Half-Duplex Master sometimes sends actual PCCC commands, but it can also simply Poll, asking the designated slave if it has something to send. In a system like yours, I would expect that to represent a "retry". Again, a Half Duplex Master always sends DLE ENQ STN BCC, not just DLE ENQ.

When a device is configured as a DF1 Full Duplex device, it does send DLE ENQ all by itself without any slave node or error check byte. It's a re-inquiry sent to prompt a device to transmit the answer to the last request it got.

I am not super-clear on how DF1 Radio Modem differs from DF1 Half Duplex. It was my understanding back when I did this stuff more often that DF1 Radio Modem simply omitted the DLE ACK packets from the Half Duplex protocol, assuming instead that they got through.

Are you 100% sure that both ends of this link are set up for DF1 Radio Modem ?

My understanding is that DF1 Radio Modem is the equivalent of Ethernet UDP. The commands are sent with no expectation of an ack response. I have a trace that confirms this. It just sends..... then nothing. If I get a response, it's immediate and complete. So its faster but less "durable".

Yes I'm sure they both are set the same, I can see them both at the same time thanks to the cellular radio I have attached to it.

These DLE ENQ packets almost have to be the MDS Orbit radio responding in some fashion. They happen too fast for the transit time of a complete send/receive over radio operation don't they?

The current command path for this station as captured is remote-AP-SAFnode-Remote.
Tomorrow I am moving this test PLC to a location that is not forwarded by an SAF node to see if that works better. Will still be remote-AP-remote.

If that is an improvement I will try polling from the AP directly and test that too. Can't rely on that solution since the AP is on a mountaintop and the backhaul is microwave subject to rain failure.

But even if all that is true, this is a wierd trace with no explanation. I'm not sure I can use RadioModem with the PLC5's that I will have to deal with once this works, so HDX M/S will be what I have to use.

If your communications are not acknowledged I would send a heartbeat and test for that on both ends. Heartbeat would be at some predetermined time where the process needs to know if the communications is still up to make a decision. Otherwise the other end would being doing stuff you would not want to happen if communications are down.


Maybe count messages?
Maybe increment a counter in a message and look at this count to see if the other end has missed a command or message?
Resend a message with that count if the other end has not seen that message?


There are many ways to do this but if your looking to full proof communications these are some of the ways that I have used in past to make sure I was operating on correct data.

I have a strategy for the occasional comm failure but I need to get them to comm reliably in the first place.

OK, so we've verified that the devices are definitely using DF1 Radio Modem.

Does NetDecoder have a DF1 Radio Modem analyzer option, or just DF1 Half Duplex or DF1 Full Duplex ?

Where are you intercepting the data for the NetDecoder; on an RS-232 link, or a "tap" or repeater of some kind ?

I realize that the "DLE ENQ" frames don't have a node number attached to them, but can NetDecoder show you which side of the RS-232 connection transmitted them ?

DLE ENQ, separated by time from anything else, suggests DF1 Full Duplex and a re-transmit request.

Breakthrough... I hope.

Both Using Radio Modem
I'm using the serial tap that was provided with NetDecoder.

But I've had a breakthrough - I moved my test radio to a position closer to the AP that doesn't require an SAF node to complete the path and the comms work perfectly. 500ms response time.

Hopping through the SAF node is my issue!

GE from Rochester was on site a week ago telling me that my problem was that I could not have more than one SAF node that could hear each other. This despite multiple white papers describing the benefits of multiple SAF nodes that can self heal. mesh etc...

SO OK, I repointed my entire system to use only one SAF node and still no progress. Move it closer to the AP and eliminate the SAF from the route and perfect.

I'm gonna be all over GE about this now. the weird responses must be from the SAF node forwarding data to the remote destination and my local radio interpreting it as something it should send back to my PLC... that's why it was so fast.