Troubleshooting Lookout Direct PLC Link Drops After

Lookout 4.5.1 in a Windows XP virtual machine loses PLC data updates after 15–30 minutes, while HMI commands can still change DL-205 coils; cycling the link’s enabled checkbox restores operation temporarily. Treat that as a partial communications failure, not proof that the PLC or the entire link is offline.

Keep the checkbox cycle as a temporary restore

The observed recovery is specific and repeatable: open the DL object, open its communications-link configuration, clear Link enabled, select it again, and close the dialogs. Data updates return after this cycle. It is a useful way to restore monitoring during troubleshooting, but it does not identify or repair the cause of the failure.

Record the time of each failure and recovery, whether commands still work, the SP4 indicator behavior, and whether the HMI resumes updating. Avoid treating repeated toggling as a permanent solution: a recurring loss can leave operators viewing stale process values without an obvious alarm. If production depends on those values, follow the site’s approved response for unreliable HMI data while investigating.

Before changing the configuration, capture the current link settings and note which link belongs to Lookout. The installation uses separate links for Lookout and DirectSOFT5, so do not combine them as a quick test or alter the DirectSOFT link without a reason. Check that the checkbox cycle restores the same expected values and communications behavior each time.

Separate failed data updates from successful commands

The key diagnostic clue is asymmetric behavior: the HMI stops showing changing PLC data, but commands continue to change connected coils. A working command path does not prove that the data-update path is healthy. Treat reads, displayed values, status indication, and writes as separate observations and test each one.

Do not silence the problem because commands appear to work. Confirm that an HMI value actually tracks a PLC value that is changing, and compare the PLC-side value with the display rather than relying on a button press or a single status indicator.

Check the link configuration before changing the VM

Open the Lookout DL object and inspect the communications-link configuration that is being cycled. Confirm that the intended link is enabled and that Lookout is assigned to its separate link rather than the one used by DirectSOFT5. Compare the settings with the known working configuration; do not guess at protocol, port, addressing, or timing values.

Note whether Lookout and DirectSOFT5 are still using separate links, whether the configured link is enabled, and whether the failure occurs after a similar run period. Preserve the original settings so a test can be reversed. Change one item at a time and observe both updates and commands after each change.

Do not interpret DirectSOFT5 running without problems as proof that Lookout’s configured link is healthy. The two programs use separate links in this installation, and success in one application does not verify the other application’s configuration or live update behavior. Check the Lookout link itself before attributing the fault to the PLC.

Inspect bridged networking before switching to NAT

The XP guest uses a bridged connection to the physical network adapter, and Windows reports “limited or no connectivity.” That message makes guest-network configuration a relevant check, but it does not by itself prove that the PLC link failure is caused by VirtualBox. Check the guest’s actual network settings and reachability using the methods available for the configured connection before changing modes.

NAT did not detect the PLC link in this setup. Do not switch to NAT expecting it to repair the existing connection; if testing NAT, first determine whether the application needs a manually configured destination or other network settings. Do not invent or copy an address, subnet, gateway, or PLC endpoint value. Read the actual settings for the VM network and the PLC connection, then compare them with the network design for the machine.

After a network change, verify that the guest can reach the PLC using an appropriate approved diagnostic method, then verify that Lookout updates values. A guest connection indication alone is not end-to-end proof: the application must exchange data with the intended PLC through its configured link.

Reproduce the 15–30-minute failure without losing evidence

The reported failure appears after 15–30 minutes of operation. Use that interval as a watch window for this installation, not as a guaranteed failure timer. Maintain a timestamped record from startup until the next failure so you can distinguish an intermittent link drop from a display or network issue.

1. Start with the current Lookout and VM network configuration documented. Confirm that the link is enabled and that the HMI displays values changing in the PLC.
2. Observe the HMI values, the SP4 indicator, and command behavior independently. Note when each changes or stops updating.
3. At failure, compare a known-changing PLC value with the HMI display and test whether commands still change the intended coils, using the approved operating procedure.
4. Record the exact time and state of the guest network connection. Avoid changing multiple settings before capturing these observations.
5. If needed to restore service, cycle Link enabled off and on as described above, then record whether data updates resume and whether commands still work.

Repeat only under operating conditions where stale HMI data and test commands can be managed safely. Stop testing if the HMI’s unreliable values could cause an unsafe operation or if the approved procedure does not permit the test.

Verify each recovery before returning to normal monitoring

After cycling the link or making a controlled configuration change, check the complete behavior rather than the checkbox state alone. Confirm that a changing PLC value appears to update in Lookout, that the SP4 indicator behaves as expected for its configured function, and that commands continue to affect the intended coils. Record whether all observations recover together or only some of them.

Keep watching beyond the immediate recovery. Because the failure was observed after 15–30 minutes, verify operation over a comparable period before treating the recovery as durable. If the same stale-data condition returns, the checkbox cycle remains a temporary workaround; preserve the log and configuration notes for diagnosis rather than repeatedly resetting the link without investigation.

End-to-end verification requires agreement between the PLC’s changing data and the Lookout display, plus an independent check of command operation. A healthy-looking network status, enabled checkbox, or successful command alone is insufficient. Return the HMI to normal use only under the site’s operating rules for confirming data validity.

Escalate with the link and network facts in hand

When the fault recurs, provide official support for the Lookout product and the PLC/communications equipment with the product versions, configured link settings, VM network mode, guest connectivity status, timestamps, SP4 behavior, and results of separate read and command checks. Include whether toggling Link enabled restored updates and how long they remained available.

Do not change to NAT, merge the application links, or alter unidentified communication parameters just to suppress the symptom. Stop and escalate if the HMI remains stale after the controlled recovery, the failure affects safe operation, or you cannot verify that displayed values match the PLC.

Frequently asked questions