LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200279 occured at Acquisition.lvlib: Acquire.vi

Just remembered you are LV16, so saved for LV12 format - here are the two most important VIs (I think)

Download All
0 Kudos
Message 11 of 16
(492 Views)

What I see is an easily-corrected misunderstanding about queues.  You have a producer loop (with the DAQmx Read function) and a consumer loop (where you do processing, graphing, etc.).   Good so far.

 

However, you've created 2 distinct queues.  The producer writes to one, the consumer reads from the other.  With nothing there to read (and an infinite timeout), the consumer loop stalls out.

 

The solution is simple.  Create only 1 queue and branch the queue refnum wire to go to *both* loops.  Now the consumer reads from the same queue that the producer writes to.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 12 of 16
(489 Views)

Ah, I see - sorry about the error, I saw a post from someone else who did the two queues and thought I should do the same

 

Do you mean to split the refnum branch after the *obtain queue* or the *dequeue element*

 

I tried both and neither seem to work?? sorry I am such a dunce 😞

Download All
0 Kudos
Message 13 of 16
(487 Views)

I meant for you to do it like "split1".

 

However, this time I noticed a different problem I missed before that helps explain the failure to run.  There's a green boolean wire coming *out* of your consumer loop and *into* your producer loop.  By LabVIEW's rules of dataflow for execution, that means the consumer loop must run to completion before that data gets offered up to the producer loop.  And the producer loop cannot begin until it receives that data.  Meanwhile, the consumer loop is waiting infinitely on a queue that it wants the producer to fill.  Thus, everything is hung.

 

Remove that data dependency (delete the boolean wire that connects the loops) and the loops will be able to run.  You can come back later to think about your intended purpose for that boolean and come up with another suitable way to terminate your loop.

 

FYI, you're set up for some future heartache with your inconsistent treatment of error wires.  Some are wired, some aren't, some are used for loop termination, some aren't.  Once you get basic functionality going, this will be another important area for improvement.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 14 of 16
(480 Views)

Dear Kevin,

 

You are definitely my favourite person in the world right now, it amazes me how helpful people are on here to complete strangers. Go humanity!

 

Great, I will wire as per split1 - and then remove the boolean when I am at work tomorrow see if that fixes things.

 

However, it introduces a huge issue in my VI - as the whole point of the VI is to run acquiring data continuously, and stop once a person has made a movement....

 

I had the stuff detecting movement in the read/ acquire loop originally but then it was suggested that having the read and analyse stuff in the same loop was what was making it lag/ get that error message. If I remove that boolean from analyse--> read terminating everything it wont be able to do its main function.

 

I will have a play with this tomorrow but (if you feel like it, don't feel obliged) do you have any suggestions on how to stop my producer (and the other consumer2 writing data) based on analysis in my consumer1? Error wires - but done properly? Some sort of global variable? A tyedef? (I dont really know anything about the last two things but heard of them). Will play when at my computer tomorrow but any suggestions would be so welcome. I am *this* close to finishing this program that took me 3 months to write (because I am such a newbie)!

0 Kudos
Message 15 of 16
(474 Views)

My suggestion is something I'd generally consider "not great" advice.  But with you being pretty new to LabVIEW, I want to focus on small things that'll work.

 

Right now, the boolean condition that terminates the consumer loop will then let the data Queue get released.  Once the Queue is released, the next time the producer loop calls the Enqueue function, it'll throw an error that will terminate the producer loop too.   So you're pretty much already there.  Except.

 

Except that this is generally a "not great" way to do things.  You'll get another error after the producer loop ends when you try to release the same Queue a 2nd time.  If something happens such that the producer loop terminates first, it isn't clear whether the consumer loop will terminate.  Dequeue errors are presently being ignored in the consumer loop.

 

I think you're about to get a taste of success, but be aware that a number of land mines remain buried in the code, particularly in the realm of error handling.  Don't mistake "works several times in a row" with "is robust now."

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 16 of 16
(469 Views)