LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Example VI from "knowledge.ni.com" not working

Solved!
Go to solution

Hi

 

I am trying to design a VI of my own, and a big part of it is data collection. In my design I'm borrowing heavily from an example VI provided by NI at https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NBJSA2&l=en-IE (scroll down to the attachment in the page).

 

However that example VI does not work. This makes it very difficult to use it as a reference.

If you run it you will notice the "processed data" graph remains blank, and the queue wire connecting the loops shows as  "not executed" when probed.

 

Could someone please check that example VI and see what's wrong with it so that I can have a functioning VI to use as a reference for my design?

 

(Is anyone around here involved in that knowledge base website? That VI needs to be replaced with a fixed version.)

0 Kudos
Message 1 of 9
(2,420 Views)

I messed around with it a bit and I think the issue is the case structure on the bottom loop.

 

That is the extent of my knowledge, I can't really tell what the exact issue is.

0 Kudos
Message 2 of 9
(2,409 Views)
Solution
Accepted by GuiMR

Swap the cases on the case structure in the bottom loop. You want to write the data when it doesn't timeout. Not sure why that example is incorrect.

0 Kudos
Message 3 of 9
(2,406 Views)

Thanks!

 

So I should take everything in the "True" case and move it into the "False" case?

 

(Just confirming, I'm really new at this.)

 

 

Also, how do we contact someone about this wrong example? Others might have this same issue because of it.

0 Kudos
Message 4 of 9
(2,397 Views)

Hi,

The Processed Data plot being in the TRUE case is not an error. It simply means the programmer wants to display that data only when there is an error in the Queue or when in Timeout.

The Error I believe lies in the small while loop in the right. It checks the Status of the Queue, if the Pending Insert value ==0, that loop Stops and the Release Queue after the loop releases the reference. At this point the Dequeue Element in Consumer Loop cannot find the Queue reference and gives error 1122 (refnum became invalid) and no data is dequeued. Even if you switch cases you will not have the data(or may be will have for one run of the VI).

If you do not need to monitor the status of the Queue simply remove that loop or sequentialise the Closing of the Queue.

Hope this helps
CONSUMERLOOP.PNG


0 Kudos
Message 5 of 9
(2,368 Views)

@GuiMR wrote:

Thanks!

 

So I should take everything in the "True" case and move it into the "False" case?

 

(Just confirming, I'm really new at this.)

 


Yes, that's essentially what you need to do, but it is easier than that. If the True case is showing just right click on the structure and select Make this case False.

0 Kudos
Message 6 of 9
(2,353 Views)

@DeXteR_INIT wrote:

Hi,

The Processed Data plot being in the TRUE case is not an error. It simply means the programmer wants to display that data only when there is an error in the Queue or when in Timeout.

The Error I believe lies in the small while loop in the right. It checks the Status of the Queue, if the Pending Insert value ==0, that loop Stops and the Release Queue after the loop releases the reference. At this point the Dequeue Element in Consumer Loop cannot find the Queue reference and gives error 1122 (refnum became invalid) and no data is dequeued. Even if you switch cases you will not have the data(or may be will have for one run of the VI).

If you do not need to monitor the status of the Queue simply remove that loop or sequentialise the Closing of the Queue.

Hope this helps
CONSUMERLOOP.PNG



That loop on the right has absolutely nothing to do with the issue. It doesn't run until the top loop has stopped (THINK DATAFLOW). It is there so that all of the data gets removed from the queue before closing the queue. This is not necessarily the approach that I would take, but the bottom loop will exit on the error created when the queue is closed after the data has all been removed from the queue. 

 

The cases in the bottom loop are most definitely backward. You cannot process data if there is no data to process, and there would be no data to process if the queue timed out.

0 Kudos
Message 7 of 9
(2,350 Views)

Thanks guys, this was really helpful!

 

Here's an extra question: using that loop structure I'm pretty sure all the user input fields get read when things start (for example the "sample rate" setting) but never get read again during the reading, meaning I can't make adjustments on-the-fly.

 

I noticed that if I try to drag the sample rate input thingy into the producer loop I get a wire error.

 

How could I implement a way to be able to adjust the sample rate on-the-fly in this double loop setup?

0 Kudos
Message 8 of 9
(2,304 Views)

@GuiMR wrote:

 

Here's an extra question: using that loop structure I'm pretty sure all the user input fields get read when things start (for example the "sample rate" setting) but never get read again during the reading, meaning I can't make adjustments on-the-fly.

 

I noticed that if I try to drag the sample rate input thingy into the producer loop I get a wire error.

 

How could I implement a way to be able to adjust the sample rate on-the-fly in this double loop setup?


The answer to this question depends on what you mean by "on-the-fly." You cannot change the rate without stopping the task, so there will be some lost data. The attached vi shows one way you can do this using an Event structure in the top loop. Notice that I used the Timeout case of the Event structure for the main data acquisition code. Depending on your requirements you may want to adjust the timeout. I also initialized that error shift register in the bottom loop. Without initializing that shift register you will not be able to run the program twice without closing it and opening it back up. 

0 Kudos
Message 9 of 9
(2,293 Views)