Modbus Communication with Honeywell UDA2182 Fails Daily Around 12 Noon.

[Heckler511]

Hello fellow LabVIEWers,

I have an interesting problem for you all today.  I have around 10 Honeywell UDA2182s installed in my lab.  I'm communicating with all of them via Modbus Ethernet.

All 10 of these Honeywell devices work great expect that one fails every single day.  Going back and looking closer at the data being collected, I can tell that the failure always occurs around 12 noon and last about 20 minutes or half and hour, after which, the communication is usually returned.

On the LabVEIW side I'm using the Modbus I/O server feature found within the DSC module for communication.

I'm baffeled as to what could be causing this?  I've tried rebuilding the Modbus I/O server, I've tried changing out the communication card in the Honeywell UDA.  Still the same problem.  Does anyone have any other thoughts / advice?

Thanks!

Mike

[jyang72211]

what kind of failures are you getting?  Is there an error code?  Have you try putting some debug code in your program to gather more information for debugging?

[Heckler511]

I'm montoring the Modbus I/O server's bound variables in the Distributed System Manager and in the Historical Data view in MAX.  I know that the communication has failed because I get "Unknown" in the DSM and the data go blank in MAX.

Thanks for any thoughts!

[Roryriffic]

Hi Mike,

That sounds bizarre indeed! I have a few follow-up questions for you... Do you know of any timing setting on the Modbus or Ethernet network that might be causing the periodic server crash? What about any service that would start up around noon that take the system resources away from the computer (thus losing connection)?  Also, just to clarify, the Modbus Server doesn't physically go down, just the communication link between NI software and the server, correct?

Do you have any LabVIEW code running at the time of the crash, or are you only watching the variables in DSM?

[Heckler511]

Hi Rory,

After merciless seraching I found a typo in the Default Gateway setting on the particular device.  After two days the error seems to be fixed.

-Mike