CompactLogix DF1 as DH485 stops

[g.lilly]

Greetings all.
I hope this isn't an answered issue. I didn't find anything specific to the problem in previous posts.

Here is my issue, I have a 1769-L32E controller that is dedicated to collecting status and data from a collection of remote PLC controllers and transfer to a central server. Most of the remote PLC controllers communicate over Ethernet via SLC Read/Write MSG Commands. However, I have about 6 PLC's that this controller talks to over a DH458 network via the DF1 port.

What I"m experiencing is that over time, the DH485/ DF1 stops communicating periodically with no visible faults or errors. All of the MSG commands associated with the DF1 port just stop communicating with an ER condition. The only way I currently have to reset the communications is to go to the unit and cycle power to it.

What I would like to know is:

1. Does anyone know how to detect DF1 port errors?
2. Does anyone know how to reset the DF1 port programmatically?
3. Does anyone know if it may be a Hardware / Firmware problem?

As I said, it's a 1769-L32E Firmware Rev: 18.11

When I do the communications, I stagger the MSG command execution so as to attempt to complete one message before trying to issue another. I have error detection and handling to control the flow.

Also, I have at least one other controller that does the same basic function with another group of machines and this one has no problems on the DF1 / DH485 port.

Regards,
G. Lilly

 

[g.lilly]

Also, I should mention... the "ER" status of the MSG block instruction indicates:
"Error Code: 16#001F"
"Error processing connection related service"

Thanks.
G

 

[bernie_carlton]

I think you may have to change from "staggering the MSG command execution so as to attempt to complete one message before trying to issue another" to absolutely ensuring that one message is finished (.DN or .ER) before beginning another. You may be overrunning buffers.

 

[g.lilly]

Thanks for the reply Bernie.

I guess I understated in my post what I'm doing.
In my code, I have state logic that monitors the ER and DN bits of the MSG blocks as they execute along with a Watchdog Timer (the timer has a fairly long timeout). The sequence does not advance to process the next machine (PLC) until the current one completes (DN or ER).

The reason I said "attempt to complete" is because I can't guarantee that I haven't thought of all possible scenarios that could cause the buffer to overflow, but I'm pretty sure I have.

BTW, do you happen to know of a way to detect the condition in code and reset the buffer if this occurs?

Thanks,
Greg

 

[bernie_carlton]

No, I don't, which is whi I also very carefully monitor the .DN and .ER bits. I believe at least one is supposed to turn on at some point after each MSG is triggered.

 

[dmargineau]

Ladder logic monitor the MSG .ER bit and if true re-trigger the instruction's execution logic.