Help with PLC driver, how to recover from NAK

Trying to automatically recover (no power cycle) on a PLC device.

Allen-Bradley MicroLogix1000.

When I get into a bad mode - communication drop etc. Every command I send responds with:
0x10 0x15

According to my documentation 0x0F is supposed to be NAK. But I get no other data so I'm assuming the documentation is flawed. Or is that ENQ with an extra bit?

What is the recovery of this? If ENQ, I should be able to simply send again.

I have tried ACK the message, NAK the message, ENQ the message sending the command again, and just waiting for more data. Nothing has worked.

If I cycle power the command works with correct response etc.

Any help or insight would be appricated.

smirk

"0x10 0x0F" is definitely "DLE NAK". This is the universal reply code sent by DF1 full duplex devices when they did not understand the command packet.

A likely way to diagnose this is going to be to capture exactly what you sent to the MicroLogix 1000 just before it stopped responding to your DF1 commands.

Are you polling the MicroLogix particularly fast? I can imagine this might be an indication of a full incoming message buffer; recovery via power cycle is a symptom of overflow in many systems.

Are you using DF1 Full Duplex or DF1 Half Duplex ? Are there modems involved in your system (maybe you're dropping the address or CRC if you don't have a long enough handshaking delay) ?

Thanks for the response.

Yes we found out that the Allen-Bradley DF1 Protocol and COmmand Set Reference Manual has at lest the NAK listed incorectly (4 times if you include the binary representation) on section/page 2-6
http://www.ab.com/manuals/cn/17706516.pdf

Full Duplex mode

The command I send is "diagnostic status" it responds with a large packet (which I don't parse - just check CRC). I responsde by sending

DLE ACK

If I send the command again. the PCL controller returns

10 15 which I tripple checked is hex and DLE NAK.

Any attempts to send further command give the same response.

I've tried other commands like "unprotected read" instead of the same "diagnostic status" thinking that diagnostics might not be valid any more. Still DLE ACK.

I have some concern about the accuracty of the A-B Reference and was wondering if there is any other on-line (or otherwise) documentation on the DF-1 protocol. For our current application we can hardcode much but ultimatly we would like have a class library that is bit more flexible. For that we would need more detail on what the commands are supposed to do.


Thanks again,
Smirk

Update:

Problem solved!!!!!!!!!!!

Seems some of my experiementation with recovering from NAK etc was flawed since the command packets were not properly formed.

Well, fixed that and retried the earlier test and wow, everything is working now.

handling of in-message DLE working as well. Best I can tell, my synchronous use of full duplex protocol is rock solid and reliable even when sending 1000's of commands in quick succession.

Smirk

Why do PLC programmers confuse Christmas with Halloween ?

Because 31 Oct = 25 Dec.

(groan)

I made the exact same mistake that the writer of that table on Page 2-6 of the DF1 protocol reference did; I converted in my head from "fifteen" to 0x0F, when I should have been thinking "one-five hexadecimal".

Hex 0x15 is the code for NAK. It's that way in DF1, and in ASCII, and in about every international data alphabet ever.

I am flabbergasted that this error has been in the DF1 protocol manual for all this time... my copy is from 1991. I've been pressing them to issue a new edition for years because the old one lacks some SLC and MicroLogix function codes, but that error is a good enough reason by itself to issue an addendum at least.

I'm glad you got your diagnostic commands worked out and that your DF1 implementation works well.

Ken,

In reviewing my last post, I forgot to properly thank you.

Your clue on overflowing was the impetus that got me my solution.

If I slowed down the communication enough, the micrologix seemed to reset itself (not giving constant NAKs). There were some function calls that still gave NAKs consistantly. Closer inspection revealed some errors etc. So, i double and triple checked my function calls, then re-visited the earlier attempts/solutions and found that when given proper commands, It worked. So, no, delays weren't needed, I just had to eat the first ACK and then _wait_ for the response.

Thanks for the help

Smirk