UCON Driver TCP/IP Stops Collecting Data

[LB_10959792]

I have a UCON driver that is collecting scale data over TCP. The driver will work for a long time then suddenly stop working and begin displaying the data as "bad". When I connect to the device with putty I still receive the string data it is supposed to be receiving, but the driver is not collecting it or displaying any errors. When I reinitialize Kepware it begins working again. This happens randomly, it could be days or months before this will happen but it is a problem that I need to reinitialize since we are using Kepware for our data historian. I have tried using a stop character in the string received and have recently just tried stopping after a certain number of bytes, but I don't feel that is the problem since the stop character is always the same termination character.

• What would cause the UCON driver to stop sending/receiving TCP messages without any errors? 
• Is there an error log somewhere for UCON drivers?
• Is there any way to correct this?

Kepware version V6.4.321.0

[VladimirN]

Have you looked at this guide - "User-Configurable (U-CON) Driver": https://www.ptc.com/~/media/kepware-store/en/manuals/user-configurable-ucon-manual 

[LB_10959792]

Yes that is how I set up the driver. What part are you referring to that will answer my questions?

[cmorehead]

@LB_10959792 

The KEPServerEX Event Log would be the first place to look for clues as to why your instance is suddenly stopping. There are also communication diagnostics in the KEPServerEX application that can be enabled. The third-party tool called Wireshark can also be very helpful. I recommend opening a support ticket with Kepware to assist in troubleshooting your specific instance. Here is a link to the login page where a ticket can be opened:

Log In | My Kepware

Thanks,

*Chris

[LB_10959792]

I forgot to mention that I checked logs and the diagnostics. The logs are useless. It just says it disconnected with no error codes or anything useful. Diagnostics just stop. It literally stops communicating so I don't understand how wireshark could be helpful besides showing the packet where it stops communicating, but that doesn't help. Honestly it looks like the driver itself gets stuck somewhere in code execution or does not have the proper erorr handling to restart the driver if it doesn't like something. I will contact tech support at this point since it doesn't seem to be a problem other people have run into.