LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wifi communication with a µc: trying to avoid conflicts

Hi all.

 

I'm taking over the development of an application that serves as a user interface to control a distant platform.

On this platform there is a µc with which I have to communicate by Wifi to get all sort of data (Battery, Power, attitude etc) and control a few actuators on it.

 

Problem is the communication has been badly handled and I am having a lot of conflicts between what I send and what I'm supposed to receive.

Typically, a request will be "?H" (but also "?M" "?S" "?B") and answer to this will be a serie of data structured like

[Error Code, CRC, H (If request was ?H), DATA REQUESTED]

But the program uses tons of parrallels loop that aren't synchronized nor organized in any way and these loops often call the wifi vi with their own commands as input. Result is I receive too often the "wrong" answer : Requested ?H, but receiving the answer to ?S.

It's difficult to share any code at all as it wouldn't be working anyway, but below are a few pictures to illustrate what I'm struggling with. 

 

The guy has been using semaphores in the wifi vi to avoid conflicts, but it's been proven ineficient.

I tried to reduce the number of time this VI was called everywhere (by increasing the loops delays), but still, no good results.

 

I'm trying to find a solution without having to re-do everything, being myself not very well experienced yet, that would take me way too much time. Any suggestions other than "burn your computer and start over", are very welcome 😄

 

I have to put a trigger warning somewhere, this code uses an excessive amount of shared variables. The connection ID and semaphore are initialized at the beginning.

WifiBridge.png

 

TCPExecCMD.vi :

ExecandRead.png

 

TCPReadString:

ReadCharacter.png

 

And here is an example that illustrate globally what the program does in term of parrallel calls:

Example.pngExample results.png

 

 

If you have any suggestions...

 

Thanks a lot in advance,

Vinny.

 

0 Kudos
Message 1 of 2
(725 Views)

PS: I'm also considering getting rid of the semaphore.

The wifibridge VI having its execution state as "Non-Reentrant", it should anyway avoid simultaneous Write/read on the TCP line, no ?

0 Kudos
Message 2 of 2
(722 Views)