Expose a serial device over TCP

Scenario 1: expose a serial device over TCP

Use this to turn an RS-232/RS-485 meter, sensor or controller into a temporary serial device server.

1. Create endpoint A as the device's serial port and match its baud rate, data bits, parity, stop bits and flow control.
2. Create endpoint B as a TCP Server and choose a listen address and port, for example 4001.
3. Open Tools → Bridges… → New, select the serial connection as A and the TCP Server as B, then choose A ⇄ B.
4. Keep Transparent protocol, Forward immediately framing and One client at a time for TCP server clients.
5. Enable the bridge. Connect the remote application to gateway-address:4001, send a known request, then check both endpoints' Rx/Tx counters and the device response.

Let the remote client control the serial port with RFC 2217

The bridge supports RFC 2217 as well as transparent forwarding. Choose it when the remote side must change baud rate, data bits, parity, stop bits, DTR/RTS or Break while exchanging serial data. The bridge handles RFC 2217 negotiation and applies supported control requests to the serial endpoint; those negotiation bytes are not forwarded to the device as payload.

Use an RFC 2217-capable client or virtual COM-port tool. A plain TCP socket cannot use this mode, and SPU does not install a virtual-port driver. After connecting, change one serial parameter remotely and confirm the serial endpoint reflects it before running the real workflow.

Security: a TCP server exposes read and write access to a physical device. Bind to 127.0.0.1 when only a local virtual COM driver needs it. For remote access, explicitly listen on the network, restrict “Allowed clients” to trusted addresses or CIDR subnets, and allow the selected port through the host firewall.

Common checks after creating a bridge

• Both endpoint panes are open and show bridge badges. The manager should report Active rather than Degraded or Suspended.
• The direction matches the topology. A one-way bridge does not return responses automatically.
• Dropped counters should remain zero. A non-zero value means the sink is too slow, the buffer is too small or the source cannot be throttled. Fix the cause before merely increasing the buffer.
• Keep One client at a time for TCP servers by default. If several request/response clients must share the device, use Take turns together with idle-gap, delimiter or fixed-length framing. All clients share the port can interleave requests on the serial wire.
• Save the endpoints and bridge together in a .spu project for repeated use, and re-check the physical port assignments after loading it.