Configuring P2K-to-MATLAB Data Transfer over TCP/IP

A P2000 controller was reported to send data to MATLAB over TCP/IP, but the successful report did not record the endpoint settings or message format. Treat a connected socket as proof of transport only; define the PLC data points and wire format before commissioning the exchange.

Separate TCP/IP from EtherNet/IP

The phrase “generic Ethernet/IP client” can describe different things. TCP/IP provides a connection between endpoints, while EtherNet/IP is an industrial application protocol. MATLAB’s Instrument Control Toolbox TCP/IP interface and a PLC custom-protocol feature do not automatically share a data format just because both use Ethernet.

The reported MATLAB setup used an interface object with the P2000 IP address and port. A connection could be established, but the user could not yet send or receive useful data. That is a common boundary: network reachability does not define which PLC values to exchange or how bytes represent those values.

Check: Identify whether the MATLAB object is configured for TCP/IP and record the protocol feature selected on the P2000. Do not proceed on the assumption that a TCP connection is EtherNet/IP.

Check the P2000 software path

Productivity Suite version 2.4.0.16 was announced with a Custom Protocol over Ethernet (CPE) configuration and instruction that might support communication with MATLAB. A later report stated that a P2000 controller sent data to MATLAB over TCP/IP. The report did not document the exact CPE configuration or establish that every version and project uses the same procedure.

1. Read the installed Productivity Suite version and confirm that the project and controller support the Ethernet protocol feature you intend to use.
2. Review the installed version’s CPE configuration and instruction documentation. Identify the PLC-side connection role, remote endpoint settings, data mapping, and completion or error indications before editing the running project.
3. If the installed software predates the announced CPE feature, evaluate a compatible update using the vendor’s release notes and controller compatibility information before changing production equipment.

Do not copy settings from an unrelated protocol example. If the feature’s available roles or configuration fields do not match the MATLAB endpoint design, stop and resolve that mismatch before downloading changes.

Check: Confirm the installed software version and the documented CPE role and configuration fields for the actual controller project.

Define the values MATLAB will exchange

A generic client needs a defined set of PLC connection points, their data types, and the number of elements. Build that list before troubleshooting MATLAB code. For each value, record its direction (PLC-to-MATLAB or MATLAB-to-PLC), PLC address or tag as supported by the project, type, array length, and expected engineering meaning.

Then define the payload representation on both ends. Determine whether the protocol sends fixed-width binary values, text, or another documented representation; how messages are delimited or sized; and how multi-byte values are ordered. TCP carries an ordered byte stream, not application message boundaries, so the receiving side needs an agreed way to identify a complete message. Do not infer a MATLAB variable’s format from a successful connection.

When the PLC configuration exposes an input or output connection point, confirm which side of the exchange it represents from the product documentation. Do not assume that “input” means MATLAB input or PLC input; the reference point may be the PLC, the client, or the configured connection.

Check: Have one written exchange map showing each point, direction, type, element count, payload encoding, and message boundary. Resolve any field whose meaning is unclear in the P2000 or MATLAB documentation.

Match the endpoint roles and port

Configure one endpoint to listen and the other to initiate the TCP connection. Record the P2000 address, MATLAB host address, listening port, and which device initiates the connection. Both sides must agree on the same remote endpoint and port, and the network path must permit the connection.

The MATLAB help information mentioned in the setup discussion described port 80 as a default when a remote port is omitted. Do not rely on that default for a PLC link. Set the port explicitly on both sides according to the selected CPE configuration and MATLAB interface settings. A default port does not identify which PLC connection point carries input or output data.

1. Assign or verify the intended IP addresses and check that the controller and MATLAB host can reach one another on the network.
2. Set the listener role and explicit port in the PLC-side CPE configuration, using the installed product documentation.
3. Configure MATLAB with the matching remote IP address and port, and select the matching TCP/IP client or server role.
4. Check for another service using the port and confirm that network security rules allow the connection.

Check: Verify that both configurations show the same endpoint pair, port, and complementary client/listener roles before interpreting application data.

Commission one direction before adding the return path

Keep the first test small and one-way. Use a noncritical test value and a single mapped element where the documented CPE feature permits it. This isolates connection setup and payload interpretation from complications caused by simultaneous reads and writes.

1. Put the PLC-side protocol instruction into the documented state for opening or maintaining the connection, and monitor its documented status or error indication.
2. Connect from MATLAB using the configured endpoint. Confirm the connection state separately from the received data.
3. Change a known PLC test value and verify that MATLAB receives the intended value with the expected type and scale.
4. Repeat with a second distinct value, then test any additional mapped elements individually before scaling up.

If the connection succeeds but the value is absent or wrong, revisit mapping, direction, type, and framing before changing IP settings. If the connection fails, return to endpoint roles, addresses, port, and network reachability. Avoid making multiple changes at once; each test should distinguish one failure layer.

Check: Record the PLC test value, the MATLAB value received, and the protocol status indication. Proceed only when repeated changes arrive with the expected interpretation.

Add MATLAB-to-PLC writes as a separate test

Do not treat successful PLC-to-MATLAB transfer as proof that the reverse path is configured. Confirm that the P2000 project exposes the intended writable point and that the CPE documentation describes how incoming data maps to it. Use a dedicated test value rather than an output that can move machinery.

1. Enable or configure only the documented MATLAB-to-PLC direction and map one test point with the agreed type and element count.
2. Write a known value from MATLAB and inspect the corresponding PLC value and status indication.
3. Test the permitted operating range and update behavior before connecting the received value to control logic.
4. Define how stale, invalid, or disconnected data will be detected and handled in the application.

For production control, add interlocks and data-validity handling appropriate to the process. Do not allow an unverified network value to directly command a hazardous motion or process change.

Check: Confirm the PLC test point changes only when MATLAB sends the expected value, and confirm the application response to a lost or invalid update before enabling operational writes.

Verify the full exchange before releasing the machine

End-to-end acceptance requires more than a green connection indicator. Exercise every mapped point in both required directions, confirm data types and element counts, and test connection loss and recovery. Record the actual address, port, role, mapping, and payload format so the next shift can reproduce the setup.

• Verify ordinary values and boundary values against the expected PLC and MATLAB representations.
• Confirm that messages remain correctly separated when updates are repeated, rather than relying on one successful transfer.
• Disconnect or interrupt the link in a controlled test and confirm the documented status response and safe application behavior.
• Restore the connection and confirm transfer resumes without stale values being mistaken for fresh data.

As a temporary restore, retain the simplest verified one-way transfer and keep untested writes out of control logic. The permanent repair is a documented, version-compatible CPE configuration with an agreed data contract, explicit endpoint settings, and tested failure handling.

Check: Release the exchange only after both required directions, repeated updates, and loss/recovery behavior pass against the written acceptance list.

Frequently asked questions