Troubleshoot pylogix PLC Connection Checks Before Tag Reads

A 10 Hz historian reader needs to distinguish an unavailable PLC connection from a failed tag read before it starts or resumes data collection. With pylogix, the first read can establish the connection; treat a successful read as proof that the requested tag was read, not as the only possible test of connection health.

Use a lightweight check before starting the historian loop

The quickest approach is to attempt a read and inspect its status. pylogix connects implicitly on the first tag-read attempt, so a successful result can serve both as an initial connection check and as the first data acquisition. Continue only when the read status is Success.

That check couples two different conditions: network/session communication and the validity and accessibility of the requested tag. A failed read therefore does not prove that the PLC is disconnected. A misspelled tag or a tag whose external access is set to None can fail even when communication with the PLC works.

Before commissioning, use a known-good tag that the historian account or client is permitted to read. Record the status returned by the library, not just whether the call raised an exception or returned a value. Check: the expected tag produces Success and a plausible value before enabling the 10 Hz loop.

Separate connection health from tag validity

When a tag read fails, make a second check that does not depend on that tag’s name or access configuration. The available pylogix option is GetPLCTime(); inspect its status and treat Success as evidence that the PLC communication path is working.

A successful time query proves communication sufficiently for this check, but it does not prove every historian tag is valid or readable. Check: the health test and the production tag test report separate outcomes so an operator can tell an access problem from a communications problem.

Apply the 10-second retry without blocking acquisition logic

On a failed connection-health check, wait 10 seconds before the next attempt, as required for this reader. Keep acquisition disabled until a fresh check succeeds.

1. Attempt the known-good tag read at startup.
2. If it succeeds, write the value with its normal historian timestamp and enter the 10 Hz acquisition loop.
3. If it fails, call GetPLCTime() and inspect its status.
4. If the time query succeeds, report a tag-read/configuration fault and correct the tag or access configuration; do not wait for a network recovery that the health check does not indicate.
5. If the time query fails, mark the connection unavailable, wait 10 seconds, and repeat the health check.
6. Resume the historian loop only after communication is restored and the production tag read succeeds.

Keep the wait in the retry path rather than allowing a failed check to spin continuously. Preserve the failed status and the time of the last successful read so the operator can see the length of a data gap. Check: one failed health check produces one controlled 10-second pause, not repeated attempts at the normal 10 Hz rate.

Protect historian continuity during an outage

A pause in reads creates a gap in PLC-derived data; it does not recover samples that were never collected. Make the outage visible in the historian or its operational logs instead of silently treating the last value as current. Store the connection state, failed-read status, and time of the last good acquisition using the historian’s available mechanisms.

Do not repeatedly write a stale value as though it were a new PLC sample. If the historian must retain a value during an outage, distinguish that retained value from a newly read value and mark the interval as degraded or unavailable. Define separately whether a recovery should resume live collection only or attempt backfill; the connection check alone cannot provide missing historical samples.

Check: after a simulated or observed outage, the record stream shows the outage interval and the time at which valid reads resumed, without representing stale data as fresh.

Verify the recovery path end to end

Commission both branches of the decision path. First confirm the known-good tag returns Success and that the 10 Hz loop records valid values. Then test the distinction between tag failure and connection failure using controlled conditions approved for the machine: an invalid or inaccessible tag should fail its read while a successful GetPLCTime() identifies that communication remains available. Do not deliberately interrupt a production PLC network without authorization.

For the outage branch, observe that failed health checks stop acquisition, trigger the 10-second wait, and resume only after a successful health check followed by a successful production-tag read. Confirm timestamps and outage indication at the historian, not only in the client process. Check: the recovered stream contains new valid reads and clearly exposes the period with no PLC samples.

Answer common pylogix connection questions