Wiznet makers

Summary

The plc-comm-slmp-cpp-minimal project implements Mitsubishi Electric MELSEC SLMP Binary 3E and 4E communication for embedded C++ systems, including ESP32-class boards and WIZnet W6300-EVB-Pico2. It lets a compact controller read and write PLC devices without a PC, HMI, or OPC gateway. On the W6300-EVB-Pico2, the W6300 supplies the wired Ethernet transport while the RP2350 builds SLMP frames, validates PLC profiles, decodes responses, and manages reconnect behavior.

What the Project Does

MELSEC PLCs expose internal devices such as data registers, relays, timers, counters, and link registers through SLMP, or Seamless Message Protocol. An external controller can therefore exchange production data with the PLC without changing the PLC into a generic Modbus device or inserting a protocol-conversion gateway.

The project provides a compact C++ client for this communication model. Its public APIs support typed device access, PLC-specific profiles, fixed transmit and receive buffers, TCP or UDP transports, response end-code handling, monitor operations, extended device routes, and reconnect logic. The repository targets constrained embedded systems rather than desktop-only applications.

A typical WIZnet-based data path is:

Sensor or machine controller → RP2350 application → SLMP Binary 3E/4E frame → W6300 Ethernet → MELSEC PLC

The reverse path carries PLC device values, completion codes, and protocol errors back to the embedded application.

For example, an embedded node can periodically read D100, publish the value to another subsystem, and write a result to a permitted PLC register. The library’s high-level interface represents addresses with strings such as D100:U, where the suffix identifies the expected value type. It also provides lower-level operations for module buffers, link-direct devices, and other routes that cannot be expressed as ordinary PLC addresses.

Why Binary 3E and 4E Matter

A 3E frame contains the routing fields, request length, monitoring timer, command, subcommand, and command data needed for normal request-and-response communication. It is generally appropriate when one client sends one request and waits for its response before issuing the next.

A 4E frame adds a serial number to correlate requests and responses. This becomes important when a device pipelines requests, handles multiple outstanding transactions, or shares processing between asynchronous tasks. The serial number allows a response to be matched to the correct request instead of relying only on arrival order.

Binary encoding matters because numeric fields and device data are transmitted directly as byte values. Compared with ASCII representation, this reduces frame size and removes hexadecimal text conversion from both endpoints. The practical result is lower bandwidth consumption and less parsing work when a controller repeatedly reads large register blocks.

Mitsubishi Electric documents that the SLMP 3E and 4E message formats correspond to the QnA-compatible 3E and 4E formats used by MC Protocol. This compatibility allows existing external devices designed around those MC Protocol frames to communicate directly with SLMP-compatible equipment.

Where WIZnet Fits

The repository includes a maintained example for W6300-EVB-Pico2, a board combining an RP2350 microcontroller with the WIZnet W6300 Ethernet controller. The example uses wired Ethernet and UDP to poll D100:U, detect a cable or transport failure, apply exponential reconnect backoff, and report recovery after communication resumes.

The W6300 is not responsible for interpreting MELSEC device addresses or SLMP commands. Those functions remain in the C++ library on the RP2350. Its role is the network layer:

• Establishing a physical 10/100 Ethernet link
• Providing IPv4 and IPv6 network capability
• Handling hardware TCP/IP functions and socket resources
• Moving SLMP request and response packets between the MCU and PLC
• Giving the embedded node a wired interface suitable for control cabinets and fixed machinery

WIZnet describes the W6300 as a hardwired IPv4/IPv6 TCP/IP controller with high-speed host interfaces. The W6300-EVB-Pico2 integrates it with the RP2350 so the application processor can concentrate on PLC addressing, protocol state, validation, and machine logic.

This division is relevant to PLC manufacturers because protocol support is only one part of interoperability. A device also needs a transport that can remain connected in electrically noisy plants, recover predictably after cable interruptions, and operate within a small MCU memory budget. A hardware Ethernet controller makes it practical to place SLMP support inside sensors, drives, remote I/O modules, test fixtures, and protocol bridges rather than requiring an industrial PC.

Implementation Notes

W6300 Ethernet and SLMP Transport

File: examples/wiznet_w6300_evb_pico2_polling_reconnect/wiznet_w6300_evb_pico2_polling_reconnect.cpp

Wiznet6300lwIP g_eth(W6300_PIN_CS);
WiFiUDP g_udp;
slmp::ArduinoUdpTransport g_transport(g_udp);

uint8_t g_tx_buffer[160] = {};
uint8_t g_rx_buffer[160] = {};

slmp::SlmpClient g_plc(
    g_transport,
    slmp::PlcProfile::IqR,
    slmp::TargetAddress{
        0x00U, 0xFFU,
        slmp::module_io::OwnStation, 0x00U
    },
    g_tx_buffer, sizeof(g_tx_buffer),
    g_rx_buffer, sizeof(g_rx_buffer)
);

This code separates the network implementation from the SLMP client. Wiznet6300lwIP brings up the W6300 interface, ArduinoUdpTransport adapts the UDP object to the library’s transport contract, and SlmpClient receives fixed application-owned buffers.

The fixed buffers are significant for embedded product design. They avoid hidden dynamic allocation during normal requests and make the communication memory budget visible at compile time. The selected IqR profile also enables PLC-specific guards before a request is transmitted.

Reading a MELSEC Register

File: examples/wiznet_w6300_evb_pico2_polling_reconnect/wiznet_w6300_evb_pico2_polling_reconnect.cpp

slmp::highlevel::Value d100;

const auto err =
    slmp::highlevel::readTyped(g_plc, "D100:U", d100);

if (err == slmp::Error::Ok) {
    Serial.printf(
        "D100:U=%u\n",
        static_cast<unsigned>(d100.u16)
    );
}

readTyped() converts the human-readable device specification into the corresponding SLMP request, sends it through the selected transport, checks the response, and returns the result in a typed value container.

This code exists to prevent application logic from manually assembling frame bytes for every read operation. PLC manufacturers and device vendors still need to understand the underlying frame format, but a typed API reduces repeated implementation errors involving device codes, byte order, data widths, and response lengths.

Link Recovery

The W6300 example checks both physical link state and network readiness before attempting PLC communication. When an operation fails with a transport or protocol error, it closes the SLMP transport and increases the retry delay up to a configured limit.

That behavior is more representative of a deployable industrial node than a demonstration that assumes Ethernet is permanently available. A PLC integration product must distinguish between at least three conditions:

1. Physical Ethernet link loss
2. IP or socket transport failure
3. A valid SLMP response containing a PLC error code

Treating all three as the same generic failure makes commissioning and maintenance unnecessarily difficult.

Why SLMP Is Important for PLC Manufacturers

It creates a usable device ecosystem

A PLC becomes more valuable when third-party devices can exchange data with it without proprietary middleware. SLMP gives sensor vendors, robot suppliers, inspection-system developers, embedded gateway manufacturers, and software vendors a documented path to MELSEC device memory and controller services.

For a PLC manufacturer, this expands the number of products that can connect directly to the controller. The protocol becomes part of the platform strategy rather than merely a communication feature.

It reduces integration friction

Machine builders often need to connect equipment from several suppliers. When the PLC exposes a stable Ethernet protocol, an external device can access defined registers directly instead of requiring a custom ladder-programmed ASCII protocol for each project.

This reduces duplicated engineering in the PLC program, shortens commissioning, and gives both sides a repeatable diagnostic model based on commands, subcommands, and end codes.

It preserves compatibility across product generations

The relationship between SLMP 3E/4E frames and QnA-compatible MC Protocol frames is important for installed equipment. A manufacturer can evolve CPU hardware and networking products while retaining a communication model already used by HMIs, SCADA drivers, gateways, and custom machine controllers.

Industrial users generally expect automation assets to remain serviceable for much longer than consumer electronics. Protocol continuity protects the customer’s integration investment and lowers the risk of adopting a newer PLC family.

It supports both simple and concurrent clients

Binary 3E is suitable for small devices using a sequential request-response loop. Binary 4E supports transaction identification through its serial number, which is useful for higher-performance clients with several outstanding operations.

Supporting both allows a PLC vendor to serve small MCU-based modules and more complex supervisory systems through related frame formats rather than forcing every client into the same execution model.

It exposes more than generic register reads

A PLC-native protocol can represent controller-specific device families, routing information, module access, remote operations, monitoring functions, and structured error results. The project demonstrates this breadth through normal device reads, module-buffer access, link-direct access, monitor registration, self-test, remote password handling, and PLC end-code inspection.

Modbus TCP remains useful as a broad interoperability protocol, but it does not inherently describe MELSEC-specific device names or advanced controller services. SLMP is therefore important when a manufacturer wants external products to use the PLC’s native data model instead of reducing every controller function to generic coils and registers.

It enables embedded products without a gateway PC

A minimal C++ implementation allows SLMP to run inside a small controller. That makes direct PLC communication possible in products such as:

• Vision-light controllers
• Barcode and RFID readers
• Smart torque tools
• Environmental monitoring nodes
• Test fixtures
• Specialized remote I/O
• Drive and actuator interfaces
• Edge data collectors

The included W6300-EVB-Pico2 target demonstrates this architecture on an RP2350-class MCU with wired Ethernet rather than on a full operating system.

Practical Tips / Pitfalls

• Select the exact PLC profile before sending commands. Device ranges, supported operations, frame behavior, and routing capabilities differ between MELSEC families.
• Use 3E for straightforward sequential polling. Select 4E when the application genuinely needs transaction identifiers or concurrent outstanding requests.
• Validate every write address against the PLC program. Mitsubishi Electric warns that unsafe online changes and writes to protected or system areas can cause equipment malfunction or accidents.
• Keep the polling period slower than the combined PLC scan, network, and application processing budget. Aggressive polling can consume PLC communication resources without improving useful control response.
• Separate transport errors from PLC end codes. A received error response proves that network communication worked even though the requested PLC operation was rejected.
• Design reconnection as an application state, not a blocking loop. Link loss, PLC restart, cable replacement, and switch recovery are normal lifecycle events in industrial equipment.
• Add authentication, network segmentation, and write interlocks around control functions. Native PLC protocols should not be exposed directly to untrusted networks.

FAQ

Why should a PLC manufacturer support Binary SLMP 3E/4E?

It provides a compact, documented way for external devices to access the PLC’s native data model over Ethernet. This encourages third-party integrations while retaining MELSEC device addressing, routing, error reporting, and controller-specific operations that generic register protocols cannot fully represent.

How does the W6300 connect SLMP to the RP2350 platform?

The W6300-EVB-Pico2 connects the RP2350 to the W6300 through the board’s Ethernet host interface. In the repository example, firmware configures the W6300 network layer and passes a UDP client into the SLMP transport adapter. The SLMP library then builds and parses protocol frames while the W6300 carries the packets over wired Ethernet.

What role does W6300 play in this project?

The W6300 provides the physical Ethernet and network transport used to reach the PLC. It does not interpret D100, select the PLC profile, or process SLMP end codes. Those responsibilities belong to the RP2350 application and the plc-comm-slmp-cpp-minimal library.

Can beginners use this project?

A developer should understand C++, IPv4 addressing, PLC device memory, and basic MELSEC Ethernet configuration. The high-level API makes individual reads and writes manageable, but safe deployment also requires knowledge of PLC scan behavior, device permissions, reconnect handling, and machine interlocks.

How does SLMP compare with Modbus TCP?

Modbus TCP is widely supported and simple, but it exposes a generic coil-and-register model. SLMP maps directly to MELSEC device families and supports Mitsubishi-specific routing and controller operations. Use Modbus TCP for broad vendor-neutral interoperability; use SLMP when an external product needs deeper and more natural integration with MELSEC PLCs.