LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Suggestions on Resolving Error 20023?

I'm receiving Error 20023: Analysis: The following conditions must be met: 0 < f_low <= f_high <= fs/2.  I've set my sampling rate and cutoff frequencies to follow the guideline, I've used a waveform constant, and I'm still getting this error. Also, when I connect a Get Queue Status function, there is an error about input parameters (which I'm assuming to be about the filter). Any suggestions?

0 Kudos
Message 1 of 17
(1,840 Views)

Your samples per channel is 800k and your sampling rate is 80k, so you will take data for 10 seconds before anything gets sent to your consumer loop. That loop has a timeout of 2 seconds, so it'll timeout and return an empty waveform, which your filter can't use.

 

I'd recommend getting rid of the timeout altogether and setting your samples per channel to more like 8k or 16k so you'll get a block of samples several times per second instead of once per 10 seconds.

 

Your Get Queue Status function errors when you stop the upper loop because stopping the upper loop releases the queue before the lower loop can exit. You can probably just ignore that error (use Clear Errors.vi).

 

There are better ways of stopping loops than killing the queue and detecting the error, but your way isn't terrible or anything. Just means you have to kill the right errors. Try looking up "sentinel values" where you send an empty array to signal "I'm done", but for now focus on getting the producer/consumer figured out. (Again- your way of terminating the bottom loop is decent and is the simplest, but there are some other ways to skin that cat that may be a little better. Don't worry about it for now.)

Message 2 of 17
(1,813 Views)

If I needed the consumer loop to finish processing all the data in the queue after I press stop, wouldn't I need a timeout?

0 Kudos
Message 3 of 17
(1,800 Views)

No. In your system, when you press Stop, the upper loop will exit and it will immediately destroy the queue. You'll lose any unprocessed data, timeout or not. This is part of the reason for the sentinel value- it's much more controllable.

 

Try this: remove your timeout completely, then get the Y array component of the waveform data type, then wire it to an "Empty array?" node. If the array is empty, stop the loop. Your current setup returns empty arrays all the time, so that won't work. You must get rid of the timeout.

 

Now, in your producer loop, when you press Stop have it enqueue an empty waveform constant. Now you have a queue of data followed by one empty data element at the very end. When your consumer loop sees the empty element, it knows it's time to stop.

 

The last thing you need to do is to move your Merge Errors to before the Release Queue function. You need to wait until both loops have finished using the queue before you release it, otherwise you'll release it before the lower loop can finish processing its data.

 

Basically, the only time you ever need a timeout for a queue read is for when you need to do something else between queue reads (like checking another analog input, for example).

Message 4 of 17
(1,780 Views)

When you press Stop have it enqueue an empty waveform constant?

0 Kudos
Message 5 of 17
(1,748 Views)

Here, try it out with the few little mods I made.  Compare to your original, see what was changed.  Try to understand why, but come back if you get stuck.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 17
(1,721 Views)

Hmm, I'm still getting input parameter errors, but the difference I noticed is you send an empty array after the producer loop stops. Is that correct? 

0 Kudos
Message 7 of 17
(1,699 Views)

That's *one* of the differences.  I added comments around a few others.

 

I tried making minimal changes, but see that I overlooked some error sources that you had been ignoring (Queue status, Filter, FFT).  You probably have the Tools->Options setting for automatic error dialogs turned on (the default).  That's one of the dozen or so defaults I change on every LV installation. 

 

Anyway, here's another mod to take more of that stuff into account.

 

 

-Kevin P

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 8 of 17
(1,692 Views)

There still isn't anything in the queue, but my understanding is, when stop is pressed, the producer loop stops and sends the empty sentinel waveform. When this empty sentinel waveform is detected by empty array function, the consumer loop stops. Is this correct? Also, in order to initialize the chart and graph before any loop code runs, the initializations must be connected to the loop?

 

Instead of queue out between Enqueue and Remove Queue, would having queue out between Dequeue and Remove Queue work as an alternative? From my understanding, when I press stop,  empty waveforms would be detected for 2 seconds, after which the consumer loop would also end.

0 Kudos
Message 9 of 17
(1,681 Views)

Yes, you basically have it, except for the timeout part. You do NOT need a timeout and it WILL only hurt your code. It will not detect empty waveforms for two seconds; it will return the first empty waveform, then stop and never reach dequeue again, so the timeout will not come into play. The only time the timeout comes into play is if the top loop takes longer than 2 seconds to send data, at which point your code will stop working.

 

And technically yes you could put the Release Queue after the Dequeue function without having to merge the errors, however, it's good practice to not release a queue until everything that needed it is done with it. It would come up more if you were dynamically creating queues or something, but you're right it'll work here. Like I said more of a "best practices" kind of thing.

 

Last, about your initialization, you're right there too. You need a data dependency to guarantee they'll happen before your loop starts. A simple error wire will handle that:

 

BertMcMahan_0-1649876942459.png

 

Message 10 of 17
(1,674 Views)