Plugging a serial barcode scanner, RFID reader or industrial weighing scale into a modern control network can often cause a frustrating bottleneck. The physical wiring is perfect, the baud rates line up, and yet the SCADA screen is filled with chaotic numbers rather than a clean data value such as 350 kg.
The data corruption is due to a fundamental protocol incompatibility. You want to read a Modbus string over an industrial protocol that structurally doesn’t support variable length text. To solve this you need to know how to abstract the ASCII logic away from the PLC layer.
Quick Navigation
🔍 Quick Troubleshooter: What is your symptom?
Interactive Diagnostic: The String Fragmentation Problem
Enter a short string (e.g., “-2.5”) to visualize how Modbus forces 8-bit text characters to pack and fragment across 16-bit numeric holding registers.
Modbus Reg 40002: 2E35 (Chars: .5)
The Core Problem: Why Modbus Hates Raw Text
System integrators when trying to execute a Modbus read string instruction are working against the architecture of the protocol. The Modbus data model demands strict simplicity. It only supports 1-bit boolean values (Coils) and 16-bit integers (Holding/Input Registers) natively. There is no holding register “String”.
Since an ASCII character is exactly 8 bits, you need to mathematically pack 2 ASCII characters into a single 16 bit register to send text. If the barcode scanner outputs a 40 character string the PLC must read 20 consecutive registers. Asynchronous serial communication also uses specific start and stop framing bits that are precisely defined in the EIA/TIA-232 serial communication standards. Without active edge-processing, these serial frames are not converted to Modbus TCP (over IP packets).
| ASCII Character | Hexadecimal Value | Impact on PLC Memory Mapping |
|---|---|---|
| Space (” “) | 0x20 | Wastes 8 bits of payload; requires strip logic. |
| Negative Sign (“-“) | 0x2D | Cannot be interpreted natively; requires manual Two’s Complement conversion. |
| Carriage Return (\r) | 0x0D | Acts as an invisible delimiter, often causing buffer misalignment if ignored. |
Raw ASCII vs. Modbus ASCII Protocol: Clearing the Confusion
One dangerous pitfall in system integration is to mix the communication protocol with the data payload. An engineer reading in an instrument manual that it “Outputs ASCII data via RS232” will often set the PLC driver to the Modbus ASCII protocol.The message is not getting through.
An industrial scale sending plain text (e.g. WEIGHT=50kg) is sending Raw ASCII. The data is unstructured. However, the Modbus ASCII protocol is a strict communication standard that uses ASCII characters to encode strict frames, requiring specific start characters (such as a colon :) and an LRC (Longitudinal Redundancy Check) checksum.
| Protocol Characteristic | Raw ASCII (e.g., Weighing Scale) | Modbus ASCII Protocol |
|---|---|---|
| Data Structure | Unstructured text strings | Strict Master/Slave framing |
| Frame Start/End | Varies (often CRLF: 0D 0A) | Starts with Colon (:), Ends with CRLF |
| Error Checking | None natively | Mandatory LRC Checksum |
Common Devices that Output Raw ASCII (Case Study: Weighing Scales)
Raw ASCII output is pervasive in brownfield environments. RFID readers, serial barcode scanners, and analytical lab equipment are common. To incorporate these devices into a SCADA system, engineers have to reverse engineer the exact hexadecimal footprint of the payload.
Each manufacturer will format their ASCII text differently. They add leading spaces to align, they add explicit + or – signs, and they end with different delimiters. The raw hexadecimal payload needs to be captured and converted to standard Int/Float values actively before it arrives at the master network.
| Device Model | HMI Display Intent | Raw Hexadecimal Payload Received |
|---|---|---|
| Ningbo KeLi (Floor Scale) | 350 kg | 02 20 20 20 20 20 20 33 35 30 20 20 20 33 35 30 0D |
| Shimadzu (Analytical Balance) | -3.516 g | 20 20 20 2D 33 2E 35 31 36 20 20 47 53 0D 0A |
| Generic Barcode Scanner | A102B | 41 31 30 32 42 0D 0A |
The Hard Way: Manual String Parsing in PLC Logic
Without hardware abstraction programmers have to do manual string parsing inside the PLC. Using instructions like ASCII_TO_HEX, MID and FIND in Studio 5000 or TIA Portal creates a ton of CPU overhead and incredibly fragile code logic.
The toughest bottleneck is variable-length payloads and delimiters. For example, a weighing scale may return " 5kg\r\n" (7 bytes) one time and " 125kg\r\n" (9 bytes) the next. To avoid mixing old and new data in the PLC buffer, the programmer has to write continuous loop instructions that scan the incoming data array for the specific Hex values of 0x0D and 0x0A (Carriage Return / Line Feed), manually trigger a buffer flush to write the buffer to a string, and then extract the substring.
| Ladder Logic Instruction | Required Action for ASCII Strings | Impact on PLC Performance |
|---|---|---|
| FIND / SEARCH | Constantly scanning memory arrays for 0D 0A to know where the string ends. | Massive increase in PLC Scan Time. |
| MID / SUBSTRING | Extracting only the numeric characters and dropping the spaces (0x20). | Fragile; crashes if string length changes unexpectedly. |
| ASCII_TO_HEX (ATH) | Converting the isolated characters into a usable Integer for SCADA. | Requires multiple memory tags and data type conversions. |
The Smart Solution: RAW/ASCII to Modbus TCP Gateways
Relying on software logic to circumvent fundamental hardware protocol limits is inefficient. The modern standard, widely discussed in forums and endorsed by groups like the International Society of Automation (ISA), is to push protocol normalization to the network edge.
Standard “transparent” serial servers fail here. They merely convert the physical medium (RS232 to Ethernet), blindly dumping the raw ASCII hex bytes onto the Modbus network. Resolving this requires an active microprocessor middleman: a Programmable Edge-Parsing Gateway.
Step-by-Step Tutorial: Parsing a KeLi Floor Scale
For a real-life implementation of efficient edge parsing at the hardware level, we will consider the Valtoris Programmable Modbus Gateway. In this case we need to read a 350 kg value from a KeLi floor scale and map it to a Modbus TCP holding register.
Step 1: Identifying the Raw RS232 Output
First, we capture the raw hexadecimal payload from the scale. The KeLi instrument outputs a continuous stream: 02 20 20 20 20 20 20 33 35 30 20 20 20 33 35 30 0d.
Figure 2: Capturing the raw RS232 ASCII string from the weighing instrument. The actual weight data is “350”.Step 2: Flashing the Custom Configuration File
Because every scale manufacturer uses a different protocol, standard web-interface dropdowns are insufficient. Instead, Valtoris gateways use a programmable script engine. Using our configuration tool, you simply download a specific parsing rule file (e.g., httpd.txt) into the gateway. This file instructs the gateway’s microprocessor to actively strip the 0x20 spaces and extract the numeric values from the payload.
Figure 3: Flashing the parsing configuration file directly into the gateway. One hardware device can adapt to multiple protocols simply by changing this file.Step 3: SCADA Integration via Modbus TCP
When the configuration file is loaded, the gateway acts as a normal Modbus TCP Server. The SCADA system connects to Port 502 and reads the parsed data directly from the Holding Registers.
Figure 4: Verifying the parsed data using Modbus Poll. The 32-bit integer “350” is successfully read without any ladder logic.What if the scale reads a decimal? Like-3.516 g? The gateway converts the core numeric value (3516) to a standard Modbus Integer. Then the SCADA or HMI scaling properties can easily handle the decimal placement and linear scaling (dividing by 1000), keeping the Modbus transmission clean and stable.
Key Features to Look For in an ASCII/Modbus Converter
When selecting a gateway to handle complex string parsing for industrial equipment, ensure the hardware supports these critical functions to maximize engineering efficiency:
| Critical Feature | Why It Saves Engineering Time |
|---|---|
| Programmable Script Engine | Adapts to any non-standard ASCII protocol using downloadable configuration files (httpd.txt) instead of rigid firmware limitations. |
| Automated String Stripping | Actively removes whitespaces, Carriage Returns (CR), and Line Feeds (LF) at the edge, protecting PLC buffers from overflow. |
| Turnkey Modbus TCP Conversion | Converts complex variable-length payloads into clean 16-bit/32-bit Modbus Holding Registers queryable on Port 502. |
| Optical Isolation | Weighing instruments are prone to electrical noise. Hardware isolation protects your primary LAN and PLC from voltage spikes. |
Frequently Asked Questions
How do I read a variable-length barcode string via Modbus RTU?
Because Modbus RTU requires rigid register mapping, you cannot natively read variable-length strings without risking buffer misalignment. You must use an edge gateway equipped with a “Delimiter Parsing” feature (usually matching Carriage Return \r) to buffer the string until complete, then map it to a fixed block of holding registers.
Why does my PLC display overlapping characters from previous barcode scans?
This is a classic buffer flush failure. Because Modbus strings are variable in length, a shorter string (e.g., 4 characters) written over a longer previous string (e.g., 8 characters) will leave the last 4 characters of the old string in the PLC memory. An edge gateway prevents this by automatically clearing the buffer using CRLF delimiter recognition before sending the new payload.
Can a standard transparent serial server parse ASCII strings?
No. Standard transparent serial-to-Ethernet servers only handle physical media conversion. They pass the raw hexadecimal bytes of the ASCII characters directly into the Modbus network unaltered, resulting in corrupted, unusable values on your SCADA screen. Active string parsing requires specialized edge firmware.
How do I clear the serial buffer for CRLF delimiters (\r\n) in a PLC?
In a standard PLC environment without a gateway you will have to write continuous loop instructions that scan the incoming data array for the hex values 0x0D and 0x0A and manually trigger a buffer flush. This has a huge effect on PLC scan times.
What causes a “String Length” mismatch error in SCADA OPC UA tags?
If your serial device outputs a string like “12345\r\n” (7 characters total including the hidden delimiters) but your SCADA tag is strictly defined to expect a 5-character string length, the OPC server will misalign the buffer on the next read cycle, throwing an intermittent length or configuration error.
Stop Wasting Engineering Hours on Ladder Logic
Regular transparent servers are unable to parse ASCII strings. Stop writing complex parsing loops in your PLC. Send your weighing scale’s protocol manual to our engineering team and we will provide a programmable gateway pre-loaded with your exact parsing configuration file.
Request a Custom Parsing Solution