LabVIEW
I need something like a Queue but different
@Yamaeda wrote:
@RTSLVU wrote:
@Yamaeda wrote:
Your Scan Interval delay shouldn't be in the Consumer, but in the producer.
/Y
I don't want the instrument to only measure once a minute if that is the data logging rate,
I want the instrument to continue to measure at its configured update rate and save the last reading once a minute.
Well, with your current design you're misusing the queue as your solution to not have it grow indefinatly is to simple ditch it. I'd have the sampler collect into a buffer (shift register or AE or similar) and have the logger as a separate loop which simply grabs the last value from the buffer, no queue at all.
An alternative is that the sampler grabs 1 sec worth of samples and enqueues them and the logger grabs the last. No emptying of queue needed./Y
Yeah, that was not a good idea. I changed it yesterday to something that would not let the queue grow to a large size under slow logging rates.
If I ever get the time to add live data plots I will have to revisit the acquisition.
You have a race condition in the top loop. The outer Stop local will be read in the beginning of the loop while the inner Stop local will be read after the acquisition. I assume the acquisition is fast enough to not cause any big issues, but it's better to wire out the inner Local to the outer stop, that way the last read value will be used.
Do you have a small Wait in the False case of the logging loop? If not it's a CPU burner. The same goes for the 'wait loop'.
/Y
Not sure what you want exactly, but...
1) That queue should not be named. It' a disaster waiting to happen. Give the control wired to it a label, and it will show in probes. Use named queues only when they need to be accessed in parallel code, and the reference is can't be shared (which will virtually never happen).
2) If you replace the queue functions with class member VI's, that class could do anything you want. It could extend, change, remove any behavior the queue has... A "queue" with (optional) acknowledgement is fairly easy. If you're into OO of course, if not it probably won't do much. Not a good idea to start making this if you're new to OO, although OO knowledge isn't required to use it.
Search LabVIEW like a graph!
@Yamaeda wrote:
You have a race condition in the top loop. The outer Stop local will be read in the beginning of the loop while the inner Stop local will be read after the acquisition. I assume the acquisition is fast enough to not cause any big issues, but it's better to wire out the inner Local to the outer stop, that way the last read value will be used.
Do you have a small Wait in the False case of the logging loop? If not it's a CPU burner. The same goes for the 'wait loop'.
/Y
Yes I realised that, and race conditions like this was why I was looking for a better soultion. But due to my lack of programming knowledge the proper solutions are beyond my abilities.
This is what I finally came up with, it is probably not the most robust soultion but seems to work as desired.
@mcduff wrote:
In your Main Program Loop you are using property nodes to change the value of a control/indicator. I suggest you use local variable instead.
This comment is buried deep with the Error Dialog VI and I have no idea if it still applies, but here it is
The property nodes for VI Server (used to programmatically control VIs and the value of controls) execute in the User Interface (UI) thread. An optimization in LV's compiler causes a case structure to execute entirely in the UI thread if any case of the case structure uses the UI thread and nothing in the other cases is explicitly unable to run in the UI thread. The General Error Handler.vi wants to avoid switching into the UI thread unless it absolutely has to. This allows the GEH to be used inside time critical loops without introducing thread synchronization. By moving this value property node into a subVI, the compiler optimization does not apply, and the GEH will only trigger the UI thread when it actually has to throw a dialog or when a string control reference is actually passed in
If this is still true, your bottom loop may be running exclusively in the UI thread, and thus your program may be slower than need be.
mcduff
That is interesting and if this is still true it is unavoidable as I use other property nodes in my main state machine to update things on the the front panel like blinking controls during test setup, highlighting the current test step on a Table.
@RTSLVU wrote:
wiebe@CARYA wrote:
Not sure what you want exactly, but...
1) That queue should not be named. It' a disaster waiting to happen. Give the control wired to it a label, and it will show in probes. Use named queues only when they need to be accessed in parallel code, and the reference is can't be shared (which will virtually never happen).
2) If you replace the queue functions with class member VI's, that class could do anything you want. It could extend, change, remove any behavior the queue has... A "queue" with (optional) acknowledgement is fairly easy. If you're into OO of course, if not it probably won't do much. Not a good idea to start making this if you're new to OO, although OO knowledge isn't required to use it.
- I have never heard this before can you elaborate?
1) It's no magic. The class wire can be consider a cluster in many ways. So it will hold a queue reference. So the Init method would simply init a queue and put it in the wire. The Enqueue method will simply enqueue the elements, and the Dequeue method will dequeue. That would get you basic queue functionality. It would be a 1-to-1 replacement for the existing solution (although the class won't be able to adapt to the data type, -1 for this solution). Then the magic begins... When sending the queue, you can modify the send method, to for instance cluster the data with a new queue reference. The dequeue method can unbundle, and use the queue reference to confirm the received message. Or basically do anything.
OO is really not that present in this solution, it's only used as a glorified cluster to hold data. So a type deffed cluster with subVI's would add the same functionality. But you might as well (, or better actually), use a class.
EDIT:
Sorry didn't realize 1) was referring to my 1)...
When you name your queues, at some point you'll get a naming conflict. I've seen that happing in the field. Programmer A things he's clever and names his queue the VI name without .VI. Programmer B things he's clever and names his queue "Main". Boom, unexplainable weirdness. If there is no need to name the queue, don't.
If I have to (inside a class where I need some sort of synchronization that is acting globally by name), I make sure to pre-fix the string with some obscure string, so change of it coincidentally colliding is limited to zero.
If you label the control that Init Queue uses, the label shows up in the help (not probes) window.
@RTSLVU wrote:
2) Classes and OO are far beyond my abilities.
That is just a matter of expectation management... Hardest part is seeing why you need it, to justify the learning curve that is obviously there.
I find OO to be far more easy then traditional programming.
@mcduff wrote:
Put them, Property Nodes, in subVIs and the optimization does not apply, if the statement is still true.
Reading/Writing from/to a property that is linked to any front panel or anything in a front panel will cause a thread switch to the UI thread and back. It will not force the entire loop into the UI thread though. And, yes, this is thousands of times slower than a local variable (~3000x I think was the last benchmark I did). If you are setting other properties, there is no way around it. But the value property all by itself should be replaced with a local variable.
