picoScan100: PLC Integration Notes

1 - Scope and Approach

The picoScan100 is a 2D LiDAR sensor with several data interfaces. For a PLC, the best choice is the CoLa command protocol over a plain TCP/IP socket. Every mainstream controller can open a TCP client socket, so no vendor-specific driver is required.

This article is built around four deliberate choices:

2 - Which Interface to Use

The picoScan100 exposes multiple interfaces. Knowing what each one is for prevents a common mistake: trying to stream high-rate scan data over a protocol meant for commands, or vice versa.

3 - Configure the Device First

Do not configure the sensor from the PLC. Set everything up once through the on-board web server, then let the PLC only read at runtime. This keeps the PLC program small and avoids writing parameters on every restart.

4 - Connection Handling and CoLa B Framing

4.1 The polling loop

The PLC is the TCP client. It opens one connection to <device-ip>:2112 and keeps it open. On each poll it writes a request telegram, then reads the answer telegram on the same socket:

connect(device_ip, 2112)                 // once; keep the socket open
loop every cycle:
    send( frame("sRN LMDscandata") )     // request
    reply = receive_one_telegram()       // answer: "sRA LMDscandata ..."
    parse(reply)
on error or timeout:
    close(); reconnect()                 // supervise the link

4.2 CoLa B telegram structure

CoLa B wraps every payload in a fixed, length-prefixed frame. This is the key advantage over CoLa A: you always know exactly how many bytes to read, so you never have to scan for a terminator.

A complete request for the scan data telegram looks like this on the wire:

02 02 02 02            ; start
00 00 00 0F            ; payload length = 15 bytes
73 52 4E 20 4C 4D 44   ; "sRN LMD
73 63 61 6E 64 61 74 61 ;  scandata"
05                     ; checksum = XOR of the 15 payload bytes

4.3 Command types you will see

4.4 Reading a telegram robustly

Because TCP is a byte stream, one read may return a partial telegram or several concatenated telegrams. Do not assume one read equals one telegram. Use the length field to reassemble:

receive_one_telegram():
    wait until buffer has ≥ 8 bytes          // start (4) + length (4)
    verify buffer[0..3] == 02 02 02 02
    len = big_endian_u32(buffer[4..7])
    wait until buffer has 8 + len + 1 bytes    // header + payload + checksum
    payload  = buffer[8 .. 8+len-1]
    checksum = buffer[8+len]
    verify xor(payload) == checksum
    remove the consumed bytes from the buffer  // keep any remainder
    return payload

5 - Telegram Reference

These are the telegrams a PLC typically reads. Each is requested with sRN <name> and answered with sRA <name> <data>. Field-by-field byte layouts are in the Telegram Listing section of the operating instructions; parse against those.

5.1 SCdevicestate: the health check

Request sRN SCdevicestate. Treat any non-ready state as a reason to hold or invalidate the measurement values you are using downstream. This telegram is described in the Telegram Listing section of the picoScan100 operating instructions.

5.2 LMDscandata: keep it under the MTU

The scan-data telegram can grow large. If it exceeds the network MTU (typically 1500 bytes) it is split across several TCP segments, which makes reassembly slower and more error-prone on a PLC. Keep it small at the source with these device settings:

This telegram is described in the Telegram Listing section of the picoScan100 operating instructions.

5.3 perpendicularDistanceResult: the stale-value trap

This telegram is described in the Telegram Listing section of the picoScan100 operating instructions.

5.4 FieldEvaluationResult: zone states

Returns a free/occupied state per evaluation group. Because groups are created and numbered in SOPASair, keep a mapping in the PLC from group index to physical zone so the states are meaningful to the rest of the program. This telegram is described in the Telegram Listing section of the picoScan100 operating instructions.

5.5 LIDinputstate / LIDoutputstate: digital I/O

Read the current input and output pin states with sRN LIDinputstate and sRN LIDoutputstate. This lets the PLC see the sensor's I/O without extra wiring; useful when a zone result is also mapped to a physical output pin. These telegrams are described in the Telegram Listing section of the picoScan100 operating instructions.

6 - Vendor-Specific Notes

The protocol is identical on every controller; only the socket API differs.

6.1 Siemens S7-1500 / S7-1200 (recommended)

Use Open User Communication. The native picoScan100 example establishes the socket with TCON_IP_v4 and moves data with TSEND_C and TRCV_C:

Drive TSEND_C.REQ with a one-shot to send a request, and keep TRCV_C.EN_R enabled to collect answers into a receive buffer. Then apply the length-prefixed reader from §4.4 on that buffer.

6.2 Siemens S7-300 / S7-400 (legacy)

Older systems use a CP (e.g. CP343/CP443) with AG_SEND / AG_RECV and the FB54 TCP function block. The CoLa payload is identical; only the transport blocks differ. Mentioned for completeness; prefer Open User Communication on new projects.

6.3 Beckhoff TwinCAT 3

Use the Tc2_TcpIp library. Open the socket with FB_SocketConnect (remote port 2112), then FB_SocketSend the request and FB_SocketReceive the answer, feeding the bytes through the same length-prefixed reader. Supervise the link and reconnect with FB_SocketClose / FB_SocketConnect on error.

6.4 Mitsubishi (GX Works2 / iQ)

Use the built-in Ethernet socket services: SP_SOCOPEN to connect, SP_SOCSND to send, SP_SOCRCV to receive, and SP_SOCCLOSE to close. The same framing and reassembly rules apply.

6.5 Rockwell / Allen-Bradley

Studio 5000 can use raw TCP through the socket object with MSG instructions (connect / write / read / close).

7 - Best Practices & Common Pitfalls

8 - Troubleshooting