07-11-2017 04:03 AM
Hello,
I am having some trouble reliably obtaining data from multiple queues. I have three instruments connected via usb that I am polling at 129Hz each. I am enqueuing the responses from each instrument into their own queue and then dequeuing all three to combine them into one data packet.
I have two major issues with my code:
1) Only 2 of my queues seem to get combined into my final data packet. As far as I can tell, the dequeuing logic is identical so I can't understand what's going on.
2) Sometimes I obtain partial results, with much of the data missing.
The following two links are samples of what the data output looks like illustrating the two issues i'm facing;
https://pastebin.com/eNXxWAN1 (This looks ok, but is missing the data from the third queue)
https://pastebin.com/snZG4smB (This contains one partial dataset, one full, and still missing data from the third)
I have included a 'tag' in the data indicating which queue it comes from (01P2, 02P2, 03P2), and it shows that it is not one queue in particular that gets missed out.
I observe the same behaviour when I reduce the frequency down to 33Hz, and looking at Resource Monitor whilst my code runs convinces me that 'speed' is not the issue here.
Can anybody help me figure out what has gone wrong?
I have included the two vi's responsible for generating and recording the data. Sorry for the long post, but I think there's quite a lot of relevant information.
Thank you!
07-11-2017 04:15 AM - edited 07-11-2017 04:19 AM
Hi jm,
there is so much in your VI that is "questionable"…
- Why do you only read those queues when GetQueueStatus is unequal to zero on "# elements in queue"? You should read them always!
- Why is your logic that complicated? Are you often using inverted logic? (Why do you compare for "equal to zero" and execute stuff, when the result is FALSE? Why not compare using "unequal to zero" and execute on TRUE?)
- What's the purpose of obtaining and releasing a semaphore within microseconds?
- Why are there so many local variables?
- Why are there so many different "stop" buttons?
- Why do you open queues inside a loop each iteration? Why don't you release them?
- Why is the code so "unorganized"? Use more subVIs when you execture the same code three times! (In such cases you should attach subVIs too…)
- much more…
07-11-2017 04:26 AM
Hi,
I am new to labview, and was thrown in at the deep end with continuing someone else's project - that goes someway to explain my poor practices. That said, I will try to take on board your criticisms.
1) I am reading the queue when there is something to read. Please can you explain why I should not be doing this?
2) I am not sure what to say re. my logic being complicated... Inverted logic is a bad habit of mine, that I know.
3) The Semaphore is a relic of previous flow control, I will remove it. Thank you for pointing it out.
4) The local variables... A leftover from the code I have inherited. I have tried to refactor the code without them, but run into many issues. It's an ongoing side project.
5) Maybe I don't understand how Labview deals with this, but i seem to generate a new stop button for every while loop I create...
6) Fair enough, I will work on this
07-11-2017 04:27 AM
i had less points but essentially this ^^
clean up your code, i suppose you will fix several issues jsut by that
07-11-2017 04:34 AM - edited 07-11-2017 04:35 AM
Hi jm,
1) I am reading the queue when there is something to read. Please can you explain why I should not be doing this?
You should not be doing this because of THINK DATAFLOW!
You check the queue for some data - but you DON'T KNOW if the producer loop already had time to produce that data!
When you create those three producer loops you should handle their data regardless of the queue status when you start the consumer loop…
(One more problem: When you don't read the queue it will grow in memory "unlimited" as you didn't provide a max queue size!)
5) Maybe I don't understand how Labview deals with this, but i seem to generate a new stop button for every while loop I create...
When I create a new loop then there is NO new button generated!
You seem to create them in a different way…
07-11-2017 04:45 AM
start by creating sub-vis for the case structures in "10-07-17 3 trans-1.vi"
as far as i can see they do the same.
don't forget to create the appropriate terminals for queue in and other stuff,
and make them preallocated-cloned-execution
07-11-2017 09:23 AM
@GerdW wrote:
Hi jm,
1) I am reading the queue when there is something to read. Please can you explain why I should not be doing this?
You should not be doing this because of THINK DATAFLOW!
You check the queue for some data - but you DON'T KNOW if the producer loop already had time to produce that data!
When you create those three producer loops you should handle their data regardless of the queue status when you start the consumer loop…
(One more problem: When you don't read the queue it will grow in memory "unlimited" as you didn't provide a max queue size!)
5) Maybe I don't understand how Labview deals with this, but i seem to generate a new stop button for every while loop I create...
When I create a new loop then there is NO new button generated!
You seem to create them in a different way…
One way you get the button is if you choose it from the express menu, but I could've sworn that a long time ago it was a listed option.
07-11-2017 09:28 AM
Hi billko,
One way you get the button is if you choose it from the express menu
Ahh, yes. Learned something new this day!
That happens when you remove the "Express" palette from the functions palette view… 😄
But we also learned how LabVIEW beginners stumble even about this simple issue! Hey, there is an "Express" palette and I don't need to think about my algorithm anymore… 😞
07-11-2017 09:55 AM
The While loops in my code are intended to run continuously, and so there is only one condition where I want them to stop; When I tell them to. I don't really understand what the issues is with using this as my stop condition, other than it looks messy.
Saying I don't bother to think about my algorithm is hardly a helpful contribution.
07-11-2017 10:01 AM
@jm22b wrote:
The While loops in my code are intended to run continuously, and so there is only one condition where I want them to stop; When I tell them to. I don't really understand what the issues is with using this as my stop condition, other than it looks messy.
Saying I don't bother to think about my algorithm is hardly a helpful contribution.
I think the frustration you feel in the previous response is aimed more at NI marketing than yourself in particular. It's not helpful I agree, as NI marketing seems to continue to try to sell LabVIEW as something which requires no programming.