LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial Communication with SPS30

Solved!
Go to solution

Hi all, I have been trying to communicate with my SPS30, and so far it has been successful but my program is a bit buggy and I can't seem to figure out the issues before I move on to actually parsing the data. So, pretty much what happens is that I need to send Hex bytes to the SPS30, and it uses a protocol called "SHDLC" frame layer. It sends out a start byte and an end byte "7E" and in between is the communication bytes. I think the problem is that I am using the termination char 7E and as soon as it sees the first 7E it stops reading the rest of the data and times out. This lags out the VI and I can't stop the VI until the event loop times out. I created push buttons for now just so that I know that I sent out data but later on I will change it accordingly. Any help is much appreciated, thank you!

VI snippet.png

0 Kudos
Message 1 of 5
(226 Views)
Solution
Accepted by topic author Dvlasenko

Hi Dvlasenko,

 

why do you need to initalize the serial port in each iteration?

Why don't use a simple U8 constant to set the TermChar? (You may switch to hex display mode.)

Is your string typecasting even giving the expected output? (No, it isn't.)

 


@Dvlasenko wrote:

I think the problem is that I am using the termination char 7E and as soon as it sees the first 7E it stops reading the rest of the data and times out. 


Just read twice: the first read will give the first TermChar, the second one the "real" message…

 

Another common problem are "default if unwired" tunnels, especially when used for references!

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 2 of 5
(223 Views)

Thank you GerdW, I did the changes and it works much smoother now. Very helpful!!

0 Kudos
Message 3 of 5
(201 Views)

HI Dvlasenko,

 


@Dvlasenko wrote:

it works much smoother now.


To get it run "smooth at all" you should implement the communication protocol with all its details!

 

The protocol just sends replies to commands of a server (your VI), so it is very easy to sync the data stream.

The SHDLC protocol not just uses 0x7E as start/stop byte marker, but also includes 3 (or 4) bytes at the start of each message as header. One of those bytes holds the length of the message, so you can use 0x7E as TermChar and:

  1. Send your MOSI request.
  2. Read 1 byte to get the the initial 0x7E start byte.
  3. Read 4 more bytes to get the header, including the Lenght byte indicating the message length before byte stuffing.
  4. Read 500 bytes (more than expected) to get the remaining message data including the trailing 0x7E stop byte.

Simple and very reliable…

 

(All 4 steps should be done in a subVI so your main VI is less cluttered! Two more subVIs for byte (un)stuffing…)

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 4 of 5
(170 Views)

Hi GerdW,

I am having a difficult time grasping how to use byte stuffing and checksum for the VI. I am not sure where to start (I am new to LabVIEW) or how I can properly parse this data. Should I use "Scan From String" in order to parse the data?

0 Kudos
Message 5 of 5
(145 Views)