Program flow, best way to update GUI with data?

[JPrevost]

My program takes in a lot of async serial data, runs a checksum and checks it with the checksum in the datastream. If it checks out I would like to send the data array (2D) to the front panel for UI. If the data is bad I want it to NOT update the UI basically exiting the while loop, what's the best way to do this? As of right now when I get a bad checksum my program reads in the next byte in the serial buffer and checks to see if it's the start bit 55h, if it's not, it exits the case structure and after exiting the while loop it has to send out data to the UI so I get a lot of "crap". My temp solution was to use a shift register of the array so that if the checksum is bad it sends the last "good" packet of data to the front panel. The problem with this is that while the while loop is checking for the start/stop bytes "55AA" it might have to read in a LOT of bytes before coming up with the start of the next packet so while it's looking I get a lot of repeat data that shouldn't be displayed at all.

So the questions is this; Do I use notifiers, local variable, global, lv2 global, or occurance with local variable? I believe I'm going to have to go from an embedded while loop to a parallel. I'm familiar with this as this is already in the VI handling events . Any help would be appreciated.

One last tid bit of info, the data packets are 277 bytes, start and stop bytes, followed by 256 ram bytes from hardware, followed by some 10-bit AI, then the checksum. The serial rate is ~33.6kbps which works out to around 17 packets a second.

[JPrevost]

I think I'm going to try Queues. :ninja:

[JPrevost]

Man, nobody has any input .

JFYI, I taught myself how to use queues and it's doing great. Thank you Jon, you're a life savor .

[Khalid]

Without knowing the details of your setup, the first thing that comes to my mind is: why not use the Select function (from the Comparison pallette) and pass out an empty array (constant) when the checksum fails?

-Khalid

[i2dx]

i use locals (globals) if i have to update from one while-loop to an other, but normally i try to avoid such things.

if you want to update and it does not matter if you loose some values, use notifyers. use notifyers also, if you dont want to care about queues which "run full", but be aware, that you can loose some notifications

use queues, if you can't afford to loose a value, but be aware, that you have to poll the queues continiously, otherwise they can consume lots of memory, if they are filled continiously, eg. in a subVI

[JPrevost]

Without knowing the details of your setup, the first thing that comes to my mind is: why not use the Select function (from the Comparison pallette) and pass out an empty array (constant) when the checksum fails?

-Khalid

Passing an empty array causes the GUI (which is in it's own loop) to display default values. This is the data I was calling "crap" because the user gets confused and my eyes hurt when the gauges and charts go bonkers. Not to mention that the loop that sends the data is "looking" for the next start/stop bytes which means if I get a bad packet, it will then sometimes run the minor loop 270+ times before getting the next start/stop bytes. This means the GUI gets 270+ empty arrays screwing up the line charts (not xy graphs).

With queues I'm able to collect the valuable data and the GUI loop waits for the queue to have an element in it meaning low cpu usage and clean data being sent to the GUI.

i use locals (globals) if i have to update from one while-loop to an other, but normally i try to avoid such things.

if you want to update and it does not matter if you loose some values, use notifyers. use notifyers also, if you dont want to care about queues which "run full", but be aware, that you can loose some notifications

use queues, if you can't afford to loose a value, but be aware, that you have to poll the queues continiously, otherwise they can consume lots of memory, if they are filled continiously, eg. in a subVI

I was going to use globals and occurances but the queues seem to be working too well to change anything. Thanks for the bit about the memory, I'll keep an eye on it. I might go to notifiers although I don't want any dropped packets. Thanks

[Michael Aivaliotis]

Thank you Jon, you're a life savor .

Who's Jon?

Anyway, it seems like you solved your problem. I think the easiest solution would have been to use a case structure. You don't really want to update anything, so when data is bad, case-out the data updating code. Am I missing the point?

[AnalogKid2DigitalMan]

Jon is Jon Prevost, the OP. He answered his own query.

Pete figured it out

[JPrevost]

Who's Jon?

Anyway, it seems like you solved your problem. I think the easiest solution would have been to use a case structure. You don't really want to update anything, so when data is bad, case-out the data updating code. Am I missing the point?

I'll try casing it out and see if it performs any better. Thanks for that apparently obvious solution :headbang:

[mr2fastva]

Id use a throttled notifier. See the image below.