This page documents two approaches to plotting SICK S300 data in LabVIEW. An example program that uses the second approach is stored in this Git repository.
- SICK S300 sensor (any model)
- System plug that’s compatible with your S300
- One USB to RS422/485 converter (this one is used here)
- 24 VDC power supply
- LabVIEW (base package or higher)
Wire the system plug as follows:
Configure the S300 for continuous data output
Configure the S300 sensor for “Continuous data output” and your desired baud rate. This is done from the “Measured data output” tab in the device window in CDS.
Ensure the S300 is sending telegrams
The easiest way to verify the S300 is sending telegrams is to just read some data from the port.
You might find that you need a delay after opening the port to allow some data to accumulate.
I think I’ll add the delay to a subVI.
After running this VI you should see some ASCII symbols in your string indicator.
Parsing the distance data
This page discusses two approaches to parsing S300 distance data in LabVIEW.
Approach 1 – Convert ASCII to hex
One way to parse the distance data is to first convert the data from ASCII to hexadecimal. For me the motivation behind this approach is typically data presentation. When I want to make the data human readable – for debug purposes, for example – I do it this way.
One way to convert the data to hex is to use a subVI that looks something like this:
The above subVI has one input and one output. The input is first converted to a byte array, and then each byte is converted to a hex string one at a time. The argument “%02x” tells the “Format String” VI that each byte should be converted to hexadecimal and padded with two zeros. For readability and to match the formatting in SICK’s manual, I insert a space between each byte.
The subVI can be added to the block diagram as follows:
After running the above VI, the string indicator should look more like this:
If you’re getting a framing error
By now you might have noticed you’re sometimes getting a framing error (error – 1073807253) when you run your program.
The error occurs because we’re sometimes closing the COM port before the read task is complete. You could ignore this issue for now, or you could put a while loop around the “VISA read” VI and use a case structure to ensure we only read from the port when the number of bytes at the port is greater than zero. The while loop ensures the “VISA read” VI stops executing before the “VISA close” VI attempts to run.
And to retain the data being written to the string indicator from one iteration to the next, I’ll add a shift register to the while loop and use the “Concatenate Strings” VI.
How to find the distance data
After converting to space delimited hex form, the data should make more sense. First look for the telegram header. From SICK’s documentation, the header is the four byte sequence “00 00 00 00”. And since the sensor is in “Continuous data output” mode, the header will be followed by the two byte sequence “00 00”.
The distance data is the large block of data that begins immediately after the four byte sequence “BB BB 11 11”. (See the first two blue blocks in Figure 17.) The CRC is sandwiched between the last byte of distance data and the next telegram’s header (yellow box).
From Figure 17 you can see that a simple way to parse the distance data is to use the “Match Pattern” VI as follows:
Since the distance data always begins immediately after the byte sequence “BB BB 11 11”, the byte sequence “BB BB 11 11 ” is used as the “regular expression” input to the first “Match Pattern” VI. The “after substring” output is then passed to the second “Match Pattern” VI. The CRC will immediately precede the header of the next telegram, so the byte sequence “00 00 00 00” is used as the regular expression input to the second “Match Pattern” VI, and the “before substring” output is passed to the “distance data and CRC” string indicator. In addition, when the “match substring” output of the second “Match Pattern” VI matches the “regular expression” input, we set the “Stop?” Boolean to stop the while loop.
This subVI can be invoked as follows:
The above VI runs until it acquires the distance data and CRC from exactly one telegram – then it stops.
In space delimited hex form, a LabVIEW string consisting of just the distance data and CRC should be of length 3252.
It’s also important to realize that when the data is in the above form, the msb and lsb of each distance value are interchanged. So, for example, the first 16 bits in Figure 20 should be interpreted as follows:
So the distance measurement is 512 + 128 + 32 + 2 + 1= 675 centimeters.
Angular resolution and scanning range
To check your sensor’s resolution, open the device window and view the “Resolution/scanning range” tab.
The SICK S300 has a scanning range of 270° and the first beam of a scan is considered to start at -45°.
Since the value of 675 centimeters from Figure 22 is the first measured value after “BB BB 11 11”, its associated angle is -45°. And since the angular resolution of my S300 is 0.5°, the second distance measurement is 670 ∠ -44.5° centimeters, the third is 666 ∠ -44.0° centimeters, and so on. The last distance measurement in Figure 20 is 18 ∠ 225° centimeters.
Approach 2 – Parse without converting to hex
Approach 1 is useful for learning and/or debugging but computationally inefficient since the data can be parsed without first converting to hex.
Backslash codes display
If I run the VI in Figure 7 the string indicator should once again look something like this:
As before this data is not human readable. However, if I right-click on the string indicator and select \ Codes Display, I can see the data as it is actually represented in memory.
Using backslash code display, I can rewrite the VI in Figure 18 to parse the S300 data without first converting to hex.
I can now remove the VI in Figure 9 from the VI in Figure 19 as follows:
I will also add error checking to this VI and then move it to a subVI.
The subVI in Figures 28 and 29 can be invoked as follows:
Plotting the data
The following subVI can be used to plot the distance data read by the main VI in Figure 30.
The subVI in Figures 31 and 32 is added to the main VI as follows:
After configuring the COM port and baud rate with controls instead of constants, the front panel might look something like this:
The Git repository for the VI in Figure 34 can be found here.