11-11-2020 03:11 PM
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!
Solved! Go to Solution.
11-11-2020 03:19 PM - edited 11-11-2020 03:25 PM
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!
11-11-2020 04:08 PM
Thank you GerdW, I did the changes and it works much smoother now. Very helpful!!
11-12-2020 01:07 AM - edited 11-12-2020 01:09 AM
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:
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…)
11-16-2020 04:38 PM
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?