S7-1200 TIA Portal Scale Data via RS-232 to Ethernet Converter

David Krause15 min read
S7-1200SiemensTutorial / How-to
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Reading Rice Lake Scale Data on a Siemens S7-1200 Through an RS-232 to Ethernet Converter

This reference walks through a field-proven configuration that pulls continuous weight data from a Rice Lake 400-series indicator (60,000 kg capacity) into a Siemens SIMATIC S7-1214 (CPU firmware 4.4 with TIA Portal V16) using a USR-TCP232-304 serial-to-Ethernet converter. The pattern is general: any S7-1200 with PROFINET/Ethernet interface (CPU firmware 4.2 or later recommended for Open User Communication stability) can be wired to any TCP-capable serial device server exposing a continuous-mode serial scale.

Why this works as a single application note. A common field failure is that TCON reports status 7002h (connection request queued) but TRCV never returns NDR (new data received) even though the scale streams data continuously. The cause is almost always one of four things: wrong TSAP/port on the converter, no AdHoc configuration on the receive block, serial parameter mismatch (baud/parity/data bits) between the scale and the converter, or the converter is set as TCP Client when the PLC needs it to be a TCP Server. Each is covered below.

1. System Architecture and Data Flow

The communication chain has three nodes and one protocol translation step:

Rice Lake 400 60,000 kg Indicator RS-232 output Continuous mode USR-TCP232-304 RS-232 ↔ TCP TCP Server (default) Port 20108, IP 192.168.0.200 SIMATIC S7-1214 CPU 1214C DC/DC/DC TIA Portal V16 TCON + TRCV (AdHoc) RS-232 / 9600 8N1 TCP/IP / PROFINET Frame: ST,GS,+012345.67,kg<CR><LF> (Rice Lake continuous output)

The PLC functions as the TCP client / active connection partner and opens a single socket to the converter, which is configured as a TCP server. The converter transparently forwards the bytes from the indicator's serial port into the TCP stream and vice versa. Open User Communication (OUC) is the Siemens-native way to handle this on the S7-1200, using the standard blocks TCON, TRCV, TSEND, and TDISCON from the "Communication" palette in TIA Portal.

2. Prerequisites

Item Specification Notes
Siemens CPU S7-1214C DC/DC/DC (or any S7-1200 with PROFINET) Firmware 4.2 minimum; V4.4 recommended for stable OUC. See S7-1200 Programmable Controller System Manual.
Software TIA Portal V16 Update 4 or later Required for current TCON_IP_v4 data type and improved TRCV diagnostics.
Scale indicator Rice Lake 400 series (e.g., 420, 480, 482) with RS-232 Must be set to continuous output mode. See Rice Lake 400 Series documentation.
Serial converter USR-TCP232-304 (USR IOT) or equivalent Must support TCP Server mode. Default port 20108. Web configuration at http://192.168.0.200. See USR IOT RS-232 to Ethernet converter.
Cabling DB9 male-to-female RS-232 straight-through Minimum 3-wire: TX, RX, GND. See Section 3 for pinout.
Network Same IP subnet for PLC and converter Static IPs strongly preferred; DHCP reservations acceptable.
Engineering PC PuTTY, Hercules, or Wireshark for line testing Used to validate the converter and scale are producing data before the PLC is involved.

3. RS-232 Wiring Between the Indicator and the Converter

Most industrial indicators expose a female DB9 RS-232 port. Use a shielded cable, keep it under 15 m, and tie the shield to ground at one end only (the converter end is typical).

Signal Indicator DB9 pin USR-TCP232-304 DB9 pin Function
TXD 2 2 (RXD) Indicator transmits → converter receives
RXD 3 3 (TXD) Indicator receives ← converter transmits
Signal GND 5 5 (GND) Common reference
RTS / CTS 7 / 8 7 / 8 Loop back or leave unconnected if scale does not use hardware flow control
Watch the label orientation. The indicator's TX pin goes to the converter's RX pin, and vice versa. A crossed (null-modem) cable on a serial device server is the most common single wiring mistake.

4. Configuring the USR-TCP232-304

Out of the box the converter runs a web configuration on http://192.168.0.200. The relevant parameters and the recommended values for this application are listed below.

Parameter Value Reason
Work Mode TCP Server Converter waits for the S7-1200 to connect.
Local Port 20108 USR default; matches the S7-1200 TCON RemotePort.
Baud Rate 9600 Match the indicator serial setting. 19200 is acceptable if the indicator is configured for it.
Data Bits 8 Standard for Rice Lake continuous output.
Parity None Default for the 400-series continuous format.
Stop Bits 1 Standard "8N1".
Flow Control None Three-wire RS-232 is sufficient for the 400-series continuous mode.
Pack Time / Length Length = 0 (transparent) Avoids the converter buffering messages; the PLC wants the raw byte stream.
IP Address 192.168.0.200 / 255.255.255.0 Static, in the same subnet as the PLC.
Gateway 192.168.0.1 Only required if the converter must be reached across subnets (it does not for this application).
Verify the converter independently before touching TIA Portal. Point PuTTY at 192.168.0.200:20108 in raw TCP mode. You should see a frame appear every weighment cycle (typically 100–500 ms in continuous mode). If nothing appears, the problem is wiring, the indicator's serial menu, or the converter itself — not the PLC.

5. Rice Lake 400-Series Continuous Output Format

The 400-series indicators in continuous mode emit one ASCII frame per weighment. A typical stable gross reading looks like:

ST,GS,+012345.67,kg<CR><LF>

Field-by-field:

Field Meaning Values
1 Status ST = stable, US = unstable (motion), OL = overload
2 Mode GS = gross, NT = net
3 Weight value Signed, fixed point: +012345.67 (10 characters)
4 Unit kg, lb, g, oz, t
5 Terminator 0x0D (CR) followed by 0x0A (LF)

The complete frame is 21 to 24 bytes depending on unit length. CR LF is the deterministic delimiter the parser should anchor on.

6. TIA Portal V16 Project Setup

  1. Create a new project in TIA Portal V16 with the exact CPU order number, e.g. 6ES7214-1AG40-0XB0.
  2. In Device View, open the CPU properties → Ethernet addresses and assign a static IP (e.g. 192.168.0.10) and subnet mask (255.255.255.0).
  3. Confirm the CPU's PROFINET interface is connected to the same physical switch as the converter.
  4. From the right-hand Instructions palette, expand Communication > Open User Communication and drag the TCON, TRCV, TDISCON, and TSEND blocks into the program (e.g., OB1 or a dedicated FB). Each will get its own instance DB.

7. TCON Connection Parameter Block

TCON takes a TCON_IP_v4 structure as the CONNECT input. Configure it as follows for the S7-1200 to act as the active partner that opens the socket to the converter:

// TCON_IP_v4
tconParams.InterfaceId       := 64;                  // Local PROFINET interface (HW ID)
tconParams.ID                := 1;                   // Connection ID (1..4095, unique)
tconParams.ConnectionType    := 16#0B;               // 0x0B = TCP/IP
tconParams.ActiveEstablished := TRUE;                // TRUE = PLC is the client
tconParams.RemoteAddress.ADDR[1] := 192;            // 192.168.0.200
tconParams.RemoteAddress.ADDR[2] := 168;
tconParams.RemoteAddress.ADDR[3] := 0;
tconParams.RemoteAddress.ADDR[4]   := 200;
tconParams.RemotePort        := 20108;               // USR converter port
tconParams.LocalPort         := 0;                   // Auto-assign (any)
TSAP is only for ISO-on-TCP / PROFINET. Do not enter a TSAP for a plain TCP connection; the TCON_IP_v4 structure has no TSAP field. Some older S7-1200 firmware versions expose a different parameter block ("TCON_PARAM" for CPU 1.x); V16 with firmware 4.x uses TCON_IP_v4.

Call TCON in OB1 (or in a startup FB) and gate the call with a one-shot REQ edge so the connection is only requested once.

// Connection start (rising edge from HMI or first scan)
"instTCON"(REQ := "startComm",
           ID  := 1,
           CONNECT := "cfgConn".tconParams,
           DONE => "statConn".done,
           BUSY => "statConn".busy,
           ERROR => "statConn".err,
           STATUS => "statConn".status);

8. TRCV with AdHoc Mode

This is the most important section for resolving the "connection is up but I get no data" failure. AdHoc mode is required whenever the application cannot predict the message length in advance — which is the case for a free-running continuous serial stream.

Configure the TRCV instance as follows:

Input Value Meaning
EN_R TRUE (always) Enables the block. Use a periodic enable if you want pull-based behavior.
ID 1 Same connection ID as TCON.
LEN 0 AdHoc mode. The block returns whatever is in the receive buffer at the moment of the call.
DATA ARRAY[0..511] OF BYTE or STRING[254] Receive buffer.
// TRCV in AdHoc mode
"instTRCV"(EN_R := "statConn".done AND NOT "statConn".trcvBusy,
           ID   := 1,
           LEN  := 0,                                 // 0 = AdHoc
           DATA := "rcvBuf".bytes,                   // BYTE array
           NDR  => "statConn".ndr,
           ERROR => "statConn".rcvErr,
           STATUS => "statConn".rcvStatus,
           RCVD_LEN => "statConn".rcvLen);

Each successful receive sets NDR := TRUE for one scan and returns the bytes copied into DATA, with the byte count in RCVD_LEN. The application code must:

  1. Append the received bytes to a circular / line buffer.
  2. Scan the buffer for the CR LF (0x0D 0x0A) terminator.
  3. When a complete frame is found, extract the weight value and clear the consumed bytes.
  4. Reset NDR in the next cycle (the block does this automatically when re-triggered).
Trap to avoid: if the LEN parameter is non-zero, TRCV waits until exactly LEN bytes have arrived before returning. With an unknown-length scale stream, this deadlocks. LEN = 0 is the AdHoc mode that fixes the original symptom of "status 7002, no data" once the connection is up.

9. State Machine for Frame Assembly

Because the PLC can be called faster or slower than the indicator transmits, a small state machine is the cleanest implementation:

IDLE WAIT_CONN RECEIVING FRAME_OK ack consumed

States:

  • IDLE → first scan; jump to WAIT_CONN.
  • WAIT_CONN → call TCON. Stay until TCON.DONE = TRUE.
  • RECEIVING → call TRCV every cycle. On NDR, append to lineBuf.
  • FRAME_OKCR LF detected. Parse fields. Hand the value to the application. Return to RECEIVING.

10. Parsing the Weight Value

Once a complete frame is in lineBuf (terminated by 0D 0A), the parser must isolate the third comma-delimited field. A clean SCL implementation uses a small state counter:

// Pseudo-SCL parser
FOR i := 0 TO lineLen - 1 DO
    IF lineBuf[i] = 16#2C THEN           // ','
        commaCnt := commaCnt + 1;
    ELSIF commaCnt = 2 THEN              // Inside the value field
        IF lineBuf[i] = 16#0D THEN       // End of frame
            EXIT;
        END_IF;
        valueStr := CONCAT(valueStr, CHAR_TO_STRING(CHAR#lineBuf[i]));
    END_IF;
END_FOR;

// Convert "+012345.67" to REAL
weightReal := STRING_TO_REAL(valueStr);
weightKg   := weightReal;               // kg as-is for this indicator

Edge cases that must be handled:

  • US (unstable) — the indicator still emits a value; reject values flagged US in the application logic to avoid latching a moving value.
  • OL (overload) — status OL should clamp the reading to the rated capacity (60,000 kg for this scale) and raise a maintenance alarm.
  • Unit changes — if the operator switches units on the indicator, the parser still extracts the numeric portion, but the engineering conversion must be updated. Lock the unit on the indicator if possible.

11. Complete Program Skeleton (SCL)

FUNCTION_BLOCK "fbScaleComm"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR
    tconInst   : TCON;        // instance DB auto-generated
    trcvInst   : TRCV;
    tdisInst   : TDISCON;
    tconParams : TCON_IP_v4;
    state      : INT;         // 0=IDLE, 1=WAIT_CONN, 2=RECEIVING, 3=FRAME_OK
    rcvBuf     : ARRAY[0..511] OF BYTE;
    lineBuf    : ARRAY[0..63] OF BYTE;
    lineLen    : INT;
    ndrOld     : BOOL;
    weightKg   : REAL;
    status     : WORD;
END_VAR
BEGIN
    CASE state OF
        0:  // IDLE
            state := 1;

        1:  // WAIT_CONN
            tconInst(REQ := TRUE,
                     ID  := 1,
                     CONNECT := tconParams,
                     DONE => , BUSY => , ERROR => , STATUS => status);
            IF status = 0 THEN
                state := 2;          // 7000h means established and idle
            ELSIF status = 16#7002 THEN
                ;                    // pending, keep waiting
            ELSE
                ;                    // log error
            END_IF;

        2:  // RECEIVING
            trcvInst(EN_R := TRUE, ID := 1, LEN := 0, DATA := rcvBuf,
                     NDR => ndr, ERROR => , STATUS => status, RCVD_LEN => rcvLen);
            IF ndr AND NOT ndrOld THEN
                // Append rcvBuf[0..rcvLen-1] to lineBuf
                ndrOld := TRUE;
                // Scan lineBuf for 0D 0A; if found, state := 3
            ELSIF NOT ndr THEN
                ndrOld := FALSE;
            END_IF;

        3:  // FRAME_OK
            // Parse lineBuf into weightKg
            // Reset lineLen := 0
            state := 2;
    END_CASE;
END_FUNCTION_BLOCK

12. Status and Error Code Reference

When the connection or receive fails, the STATUS output of the block identifies the cause. The most relevant codes are:

STATUS Source Meaning Field action
0000h TCON / TRCV Job complete, no error None
7000h TCON / TRCV No job active Normal idle
7001h TCON / TRCV Job processing (first call) Wait
7002h TCON / TRCV Job queued, waiting for partner Check IP / port / cable / converter mode
80A1h TCON / TDISCON Connection terminated by partner Check converter power and socket state
80C0h TCON Connection ID already in use Use a unique ID per connection
80C1h TCON Maximum number of connections reached (S7-1200: 8 for OUC, varies by CPU) Reduce number of open sockets
80C3h TCON Connection aborted Scale or converter went offline
80C4h TCON Connection establishment error Wrong remote IP / port; firewall on switch
80C7h TCON Configuration error Verify ConnectionType = 0x0B and InterfaceId
80CBh TCON TCP connection error Partner closed; check for keep-alive
80CEh TRCV AdHoc mode: receive buffer too small for data pending Increase DATA buffer size
80D0h TRCV Connection terminated while receiving Reconnect via TCON

A full list is published in the SIMATIC S7-1200 Programmable Controller System Manual, section on Open User Communication error codes.

13. Troubleshooting Matrix

Symptom Likely cause Fix
TCON status stays at 7002h indefinitely Wrong IP, wrong port, or converter not in TCP Server mode Ping the converter. Set PuTTY to 192.168.0.200:20108. Set converter to TCP Server.
TCON reports 80C4h Port 20108 blocked or used by another service Change the converter local port; update TCON RemotePort to match.
TRCV never sets NDR LEN ≠ 0, or no bytes reaching the converter Set LEN := 0 for AdHoc. Validate bytes with PuTTY first.
Frames look corrupted (e.g., ??S?T,?G?S,...) Baud rate / parity / data bits mismatch between indicator and converter Match the converter serial parameters to the indicator menu exactly (typically 9600 8N1).
Only partial frames received (no CR LF ever) Converter is set to a fixed packet length and is dropping the last bytes Set converter packet rule to transparent / length = 0.
TRCV returns 80CEh Receive buffer smaller than pending data Increase the DATA array size to 256 or 512 bytes.
Status ST in the parser but value is wrong Field index off-by-one (e.g., includes unit string) Anchor on the second comma; strip at CR.
Connection drops every few hours Switch port powersaving, or converter idle timeout Disable EEE on the switch port; set the converter keep-alive > 0.
Scale sends data but PLC also receives what the PLC sent Half-duplex loop: PLC TSEND and TRCV sharing the same socket on some converters in TCP Client mode Disable TSEND for read-only flows; use TCP Server on converter and TCP Client on PLC.

14. Verification and Commissioning

  1. Converter reachability — From the engineering PC, ping 192.168.0.200. Expect < 1 ms on a managed switch.
  2. End-to-end serial loopback — Open PuTTY raw TCP to 192.168.0.200:20108. Force a weighment on the indicator. A new line of ASCII should appear every cycle.
  3. PLC online monitoring — In TIA Portal, go online and watch TCON.STATUS and TRCV.NDR. TCON.STATUS should settle to 0000h after one or two cycles; TRCV.NDR should pulse TRUE on each received chunk.
  4. Watch table parse — Add the parser's lineBuf and weightKg to a watch table. Force a few weighments and confirm the parsed value tracks the indicator display.
  5. Stability test — Leave the system running for at least one shift with motion on the scale. Watch the connection status and the weightKg value. Any drift toward US status or sudden zeros indicates a framing problem.
  6. Alarm mapping — Wire ST vs US to a Boolean tag, and OL to a maintenance alarm. Confirm these surface correctly in the HMI.

15. Performance and Timing Notes

The S7-1200 user-program cycle is the bottleneck for how quickly the application can react to a new frame. Typical values:

Parameter Typical value Notes
OB1 cycle time 1–10 ms Add I/O only; OUC blocks do not extend scan time significantly.
Indicator continuous output period 100–500 ms Configurable on the 400-series "FORMAT" menu; 10 Hz is typical.
TCP round-trip (LAN) < 1 ms Negligible versus the indicator's own cadence.
Worst-case buffer fill between TRCV calls ~5 frames Use a 256-byte buffer to absorb OB1 pauses during HMI heavy traffic.

If the application is reading fast-changing values, use a time-stamped capture (S7-1200 RD_SYS_T in the same cycle as the parser) so downstream consumers know exactly when the weight was sampled at the indicator.

16. Safety and EMC Considerations

  • Route the RS-232 cable physically separate from VFD power cables; cross at 90° angles when necessary.
  • Tie the cable shield to functional earth (FE) at the converter end only, using a low-impedance bond (short pigtail or 360° clamp).
  • If the scale is in an Ex or harsh industrial area, fit a surge protector (e.g., Phoenix Contact DT-LAN-ARGO) on the Ethernet side of the converter.
  • Use a managed switch with port-level MAC/IP filtering to prevent a rogue device on the plant network from injecting false weight frames.
  • For load cells used in lifting or personnel applications, the weight path must be considered a safety function. This OUC integration is for informational/process data only; safety-rated weighing requires a SIL-rated indicator and dual-channel architecture.

17. Frequently Asked Questions

Why does TCON report status 7002h but TRCV never receives data?

Status 7002h means the connection request is queued. The TCP socket has not yet been established, usually because the remote port is wrong, the converter is in TCP Client mode instead of Server, or a firewall is blocking port 20108. Validate with PuTTY first, then re-check the TCON_IP_v4 RemoteAddress and RemotePort parameters.

What is the correct LEN setting on TRCV for a continuously streaming scale?

Use LEN := 0. This puts TRCV into AdHoc mode, which returns whatever bytes are currently in the receive buffer and is the only correct setting when the message length is unknown, as with a free-running continuous serial stream.

How many simultaneous TCP connections can an S7-1200 handle for Open User Communication?

The exact number depends on the CPU model and firmware. The S7-1214 supports up to 8 active OUC connections in firmware 4.x. Larger CPUs (1215, 1217) support more. See the S7-1200 System Manual for your specific order number.

Can the same S7-1200 also send commands to the Rice Lake indicator?

Yes. Add a TSEND block with the same connection ID to transmit poll or tare commands. Many 400-series indicators support an "on demand" or "poll" serial mode where the host issues a single ASCII character (commonly P or W) and the indicator replies with one frame. Configure the indicator's PRNT or SERI menu accordingly.

Should I use TSEND_C/TRCV_C or separate TCON/TRCV blocks?

TSEND_C and TRCV_C combine connection establishment with send/receive and are simpler for short-lived request/response exchanges. For a long-lived connection that continuously streams data into a parser, the discrete TCON + TRCV pair is preferred because it gives independent control over reconnection and a clean place to insert the AdHoc receive logic.

Back to blog