Troubleshooting VTScada MicroLogix 1200 Serial Access

On the panel, the VTScada tag did not return the expected PLC value; changing the PLC address produced 512 in the driver tag and 5 in the COM serial tag. The decisive check is COM-port ownership: this MicroLogix 1200 connection worked with VTScada or RSLinx/RSLogix 500, but the applications could not communicate with the PLC at the same time over the same serial port. Stop changing addresses until you have confirmed that only one application owns the port.

Read the VTScada and RSLinx symptoms

Use the connection behavior to separate a PLC or tag problem from a workstation serial-port conflict:

The reported test is particularly useful: stopping RSLinx let VTScada work; starting RSLinx and opening RSLogix 500 did not establish communication until VTScada was closed. The always-run-service option was reportedly unchecked. That rules out neither another RSLinx process nor other COM-port software, but it points first to exclusive port access rather than PLC logic.

Separate COM-port ownership from address errors

On a direct serial setup, the computer’s COM port is the physical resource. Applications that open it independently can compete for that resource; one client may prevent the other from opening the port or may disrupt communications by sending its own requests. An address change cannot solve an application-level port lock.

For a DF1 serial connection, the PLC and client configuration must agree on the serial channel and protocol, and the PLC station address must match the configured target. The supplied troubleshooting notes identify a PLC address of 1 and suggest a distinct VTScada address such as 2 or another unused value. These are setup guidance for this case, not a substitute for checking the PLC channel configuration and the driver’s addressing fields. Do not put the client address into the PLC-address field.

The notes also mention and DH-485, but do not establish that both describe one active serial configuration. Confirm the protocol and channel values in RSLogix 500 and select the matching VTScada driver settings. Do not switch protocol choices merely because a tag displays a number.

Match VTScada to the MicroLogix 1200 channel

Record the PLC’s actual serial configuration before editing the VTScada device. The screenshots are not available as readable configuration data here, so use the PLC project and online channel settings as the source of truth for the parameters that must match.

1. Close VTScada and stop RSLinx Classic. Check that RSLinx is not configured to start automatically or run as a service, and verify that no other application has the target COM port open.
2. In RSLogix 500, connect to the MicroLogix 1200 and inspect the serial channel configuration. Record the selected protocol, station address, and serial communication settings shown there.
3. In VTScada, select the driver appropriate to that protocol and configure the serial interface with the same channel communication settings. Set the PLC target address to the PLC’s configured address; the case guidance gives 1. Use a distinct, unused client address where the driver requires one; the case guidance suggests 2.
4. Run only VTScada and test the connection. If it fails, close VTScada before testing with RSLinx so the two tests do not compete for the port.

Do not guess baud rate, parity, error checking, or other channel values. Read them from the controller configuration and confirm that the serial cable/interface matches the selected connection. If the values agree and a single client still cannot communicate, inspect the COM-port selection, cable path, driver status, and PLC communication diagnostics before changing addresses again.

Move the connection onto Ethernet with a NET-ENI

A 1761-NET-ENI provides a serial-to-Ethernet path for this MicroLogix 1200 setup. The reported working arrangement was laptop to NET-ENI to MicroLogix 1200, with VTScada communicating successfully. The configuration change moves VTScada from direct COM-port access to Ethernet; configure each application’s communication path and driver to match the actual interface.

1. Install and configure the NET-ENI in the communication path between the laptop network and the PLC serial connection.
2. Configure the interface’s network settings and serial-side communication to match the installation. Read the assigned network address and serial settings from the device and PLC; do not reuse guessed values.
3. Configure the VTScada driver for the Ethernet path and target the configured interface address. If RSLinx or RSLogix 500 also needs access, configure its path separately for that Ethernet interface rather than opening the laptop’s COM port independently.
4. Test VTScada data first, then test the engineering software path. Confirm actual PLC values in each application rather than judging success by a changing driver-status tag alone.

The successful VTScada test through the NET-ENI establishes that this topology can work. It does not by itself prove that both VTScada and RSLinx were tested concurrently, so validate simultaneous operation in the actual configuration before relying on it.

Verify live PLC data without blaming ladder logic

Use a known changing value to separate communications from application logic. The troubleshooting notes identify S2:4 as a free-running clock value that changes without user ladder logic. Read it in RSLogix 500, then read the same address through VTScada. If RSLogix updates but VTScada does not, focus on VTScada’s device path, address, or tag definition. If neither client updates when used alone, return to PLC channel settings, wiring, and interface diagnostics.

After the communication path works, validate the actual process tags against the PLC data table. Internal status bits can be clearer SCADA targets than physical I/O or timer/counter structures. The supplied example uses B3:0/0 as the internal bit driving O0:0/0; expose the internal bit when it represents the control state you need to monitor. Check timer and accumulator values deliberately, since their data structures may require the correct element/member mapping in the SCADA tag.

• Confirm the tag points to the intended PLC address and data type.
• Compare the VTScada value with the same PLC address in RSLogix 500 while using only one direct-serial client at a time.
• Change a known test condition and confirm the expected update; do not accept a static or unexplained value such as 512 or 5 as proof of valid process data.

Avoid fixes that only change the display

Changing the PLC address repeatedly wastes time when the port is already occupied. Likewise, restarting one application can appear to fix the problem simply because it releases the COM port for the other. Use a controlled test: close one client fully, verify the other connects, then reverse the test.

Do not infer the meaning of 512 or 5 without the VTScada driver diagnostics and the tag definitions. Determine whether each displayed number is a data value, status value, or configured tag result before using it to diagnose PLC addressing. Also avoid assuming that an Ethernet converter has resolved the issue until the configured VTScada path and actual PLC data both verify.

Stop changing configuration when the PLC channel values, target address, driver selection, and exclusive-port test all agree but the connection still fails. Capture the VTScada driver diagnostics, the RSLogix 500 channel configuration, the COM-port/interface details, and the failing tag definition, then escalate to official VTScada or Rockwell support. If the machine depends on these values for operation, keep it in its approved safe state while communications remain unverified.

FAQ