LabVIEW cannot use a DirectSOFT 5 project as its runtime communications driver; it must communicate with the running DL205 PLC through a supported driver, OPC server, or other supported interface. Keep PLC logic in the PLC where possible, and select the LabVIEW data path only after identifying the existing hardware, software versions, and where control logic actually runs.
Check whether DirectSOFT is being mistaken for the runtime interface
Read the current control path: identify which application downloads PLC logic, which application reads and writes PLC data, and which device carries that traffic. DirectSOFT 5 is the PLC programming environment in this setup; it is not the bridge that LabVIEW should connect through. LabVIEW needs a runtime communications path to the DL205 PLC or to an application that already exposes PLC data.
| What you find | What it means | Next check |
|---|---|---|
| Logic executes in the PLC; Lookout Direct only displays or commands it | Preserve the PLC program and replace the supervisory interface/data path. | Inventory the PLC communications hardware and available drivers. |
| Lookout Direct executes control logic or calculations | Replacing the HMI alone will not reproduce the existing control behavior. | List each external calculation, interlock, and command before migration. |
| DirectSOFT is assumed to be the communication server | The programming tool and runtime data interface have been conflated. | Determine what currently communicates with the PLC and through what interface. |
Do not rewrite the PLC program simply because the operator interface changes. First separate PLC-resident logic from Lookout Direct functions; only the latter require recreation if they are not provided elsewhere.
Read the existing PLC communication path
Record the exact DL205 CPU and installed communication modules, the physical connection in use, the active driver or server, and the software versions on the LabVIEW and Lookout computers. Confirm whether the current Lookout Direct installation communicates directly with the PLC or exposes data through another service. These observations determine whether an existing interface can be reused or a separate server is needed.
- Inspect the PLC rack and identify the CPU and Ethernet module. The ECOM100 Ethernet module was proposed for the DL PLC connection, but confirm that this is the module actually installed.
- In the current runtime configuration, identify the PLC device entry, driver, network address, and data items used by the HMI. Read these from the actual project and device configuration rather than copying assumptions from a different installation.
- Check the installed Lookout Direct edition and whether it exposes an OPC server or supports the proposed shared-variable connection. Record the installed LabVIEW version and the available client interfaces.
- Compare the server's supported device, protocol, and item types with the PLC and LabVIEW client capabilities. Resolve any version or feature mismatch before changing production controls.
An Ethernet connection only establishes the physical network path; the PLC, server, and LabVIEW client still need a compatible application-level driver/protocol and matching data definitions. Read the server connection status and a known PLC value before concluding that Ethernet alone provides interoperability.
Choose one supported LabVIEW data path
Use the first path that matches the equipment and software already installed. Do not assume the options are interchangeable: they place the driver, server, and network configuration in different parts of the system.
| Path | When to evaluate it | What to verify |
|---|---|---|
| OPC server between PLC and LabVIEW | Evaluate a server such as KEPDirect if its installed version supports the actual DL205 connection and LabVIEW can act as a compatible OPC client. | PLC driver/module support, server connection state, OPC item quality, client compatibility, and network/DCOM configuration if the components run on separate Windows computers. |
| Lookout Direct as an existing interface | Evaluate this when Lookout Direct is already installed and its edition exposes data that LabVIEW can consume. | Whether the installed edition acts as the needed driver or OPC server, the supported client interface, and cross-computer security/configuration requirements. |
| Direct LabVIEW driver or protocol | Use only when a driver or protocol implementation explicitly supports the PLC and installed LabVIEW environment. | Supported CPU/module, protocol, read/write data types, and driver/client version compatibility. |
The available historical guidance identified Modbus and OPC as possible LabVIEW communication routes and suggested KEPDirect with an ECOM100 as one likely route. Treat that as a candidate to validate against current product documentation, not as confirmation that every ECOM100/DL205/LabVIEW combination works. A direct LabVIEW driver for the DL PLCs was not identified in that guidance.
Test whether Lookout Direct can bridge the existing installation
If Lookout Direct already communicates with the PLC, test its installed capabilities before purchasing or deploying another server. A historical approach used the full Lookout product as a driver and bound LabVIEW shared variables to Lookout objects; that report specified LabVIEW 8.0 or later. It does not establish compatibility for current versions or for every Lookout Direct edition, so verify the exact installed features and client binding support.
- On a non-production test, read one known PLC value in Lookout Direct and verify that it changes when the PLC value changes.
- Check whether Lookout Direct exposes that value through OPC or the shared-variable mechanism supported by the installed LabVIEW version.
- Bind a LabVIEW test client to the exposed item and compare its value and update behavior with Lookout Direct.
- Test a write only with a designated nonhazardous test point and an approved operating condition. Verify the PLC sees the command and that the expected interlocks remain effective.
If the bridge works, it may avoid adding a separate OPC product, but it also makes the running Lookout installation part of the LabVIEW data path. If the LabVIEW and server processes are on different computers, network and DCOM configuration can become a separate failure point; isolate it before treating a failed read as a PLC fault.
Locate logic before replacing the operator interface
Compare the current Lookout Direct application with the PLC program and assign each control action to its execution location. Preserve sequence, interlock, alarm, and command behavior. If Lookout Direct performs logic, recreate and test that behavior in LabVIEW or move it to an approved PLC implementation; do not assume an HMI screen migration carries logic with it.
- List each PLC tag or value used for display, command, alarm, and calculation.
- Identify which operations are PLC ladder logic and which execute in Lookout Direct.
- For each externally executed function, specify inputs, outputs, permissives, failure response, and operator indication before implementing it in LabVIEW.
- Keep DirectSOFT available for PLC maintenance/programming as required; do not treat the LabVIEW project as a replacement for the PLC project.
Changing the supervisory interface can alter command timing, startup state, or behavior after a client disconnect. Keep machine-critical interlocks and deterministic control in the PLC unless the design has been deliberately reviewed and validated for another location.
Prove reads and writes before cutover
Use a test PLC or a controlled maintenance window to qualify the complete path before making LabVIEW the production interface. Begin with read-only data. A successful network connection is not sufficient: the server must report a healthy device connection, the client must receive valid item values, and those values must track the PLC.
- Read a known PLC status value in the existing interface, the selected server, and LabVIEW; compare the values at each point.
- Change a safe test value at the PLC or through an approved test procedure and confirm that the update reaches LabVIEW. Check item quality/status as well as the displayed value.
- Test a single approved write to a nonhazardous target, then confirm the resulting PLC value and expected control response.
- Interrupt and restore the client/server or network path in the test setup. Confirm the displayed fault state, recovery behavior, and that stale data cannot be mistaken for live PLC state.
- Review every function previously performed by Lookout Direct and verify its replacement behavior, including alarms and interlocks, before removing the old interface.
If a read fails, determine whether the PLC connection is healthy at the server before changing LabVIEW bindings. If the server reads correctly but LabVIEW does not, focus on the client interface, item naming, version compatibility, or network/DCOM configuration. If the server itself cannot read the PLC, check the installed module, device configuration, and documented driver/protocol support.
Restore production with a staged cutover
For a temporary restore, retain the known-working Lookout Direct interface and PLC logic while testing the LabVIEW path separately. Do not remove the current driver/server or enable production writes until the new path passes the read, write, disconnect, and logic checks.
- Back up the PLC project, Lookout Direct configuration, and relevant LabVIEW/server configuration.
- Configure the validated communications route and start with read-only monitoring.
- Compare displayed values and alarms against the existing interface, then test approved writes under controlled conditions.
- Recreate and validate any Lookout Direct-resident logic before transferring operator duties to LabVIEW.
- Cut over only after the responsible controls engineer approves the test results; keep a defined rollback to the known-working interface.
For permanent repair, document the selected driver/server, module, software versions, PLC data map, and recovery behavior. If the old Lookout setup is removed, first verify that no required PLC access or control function depends on it.
Frequently asked questions
What happens if I open the DirectSOFT 5 project from LabVIEW?
LabVIEW does not communicate with the PLC by using the DirectSOFT project as its runtime driver. Keep the project for PLC programming and connect LabVIEW to the running PLC through a supported interface.
What happens if the DL205 is connected over Ethernet?
Ethernet supplies the network path, not by itself the application-level driver or protocol. Confirm the installed module and supported PLC/server/client combination; ECOM100 was proposed as a candidate, not a universal guarantee.
What happens if Lookout Direct already reads the PLC?
Check whether the installed Lookout edition exposes OPC or another interface LabVIEW can consume. A historical shared-variable approach used full Lookout and LabVIEW 8.0 or later, so validate it against the versions and features on the shelf.
When should I stop the cutover and contact official support?
Stop before enabling production writes if the exact PLC module, driver/server version, OPC client compatibility, or data-item behavior remains unclear, or if control logic cannot be accounted for. Contact the official support channels for the PLC communications product and LabVIEW/OPC interface with the recorded model numbers, software versions, connection status, and test results.