MELSEC PLC – TCP Driver Issues After Long Downtime (Reads May Be Inconsistent at Startup)

[Alfred00]

Hi everyone,

We’ve developed a TCP driver that runs as a Windows service (created with sc create) to communicate with a Mitsubishi MELSEC PLC over TCP, handling both read and write operations.

We’re facing an unusual issue:
When the PLC has been powered off for a long time (e.g., powered down on Friday and turned on Monday morning), the TCP connection is successfully established, and write operations seem to work fine. Read operations technically work too, but we suspect they may not be returning the correct or expected values at startup.

For example, the PLC writes a flag to a specific variable that signals when we can begin our process flow — but after a long downtime, it seems that our driver either doesn't read that flag correctly or receives an outdated or invalid value.

If we manually restart the Windows service (via Services > right-click > Restart), everything starts working properly, and the flag is read as expected.

This issue only seems to happen after long power-off periods. If the PLC is only off for a short time (e.g., 30 minutes), the problem doesn’t occur, and communication is normal.

Unfortunately, I haven’t been able to investigate deeply yet because I can’t reliably reproduce the issue in a test setup. When it happens (usually Monday mornings), I have to immediately restart the service to avoid interrupting factory operations.

Additional context:
This PLC is also connected via serial to two COSMO devices (Air Leak Tester), which might be impacting its startup timing or readiness to communicate over TCP.

Has anyone seen similar behavior with MELSEC PLCs or inconsistent reads after extended downtimes?

Thanks in advance!

Edited July 24 by Alfred00

[Gambit]

I doubt it's a melsec issue if you reset the window service and it's working correctly again.

[Parky]

I agree, however, I do know that TCP is not the most robust type when re-booting, indeed Kepware some years ago reccomended using UDP on the Q series.

I had difficulty with TCP & Kepware & so did another supplier so used UDP.

[Gambit]

Yes but that had more to do with the super long timeout before closing the port automatically, But if you change the default setting that should be less of an issue.

But like you mentioned with UDP you avoid that all together. In this case it's getting wrong (old) data.