06-22-2016 03:32 AM
Hi I am storing step results in a queue. For this I am using the Sequence File Post Result List Entry Callback.
To dequeue I am using the Labview API Function, which is awaiting the next result and dequeues it for further processing.
If my LabVIEW application fetches results, Teststand gets extremly slow. If I stop my application it is extremly fast.
It seems that there is some lock on the queue.
How can I avoid this?
Solved! Go to Solution.
06-22-2016 10:33 AM
Hi Michael,
am I right, you are using a LabVIEW queue? Is it size limited? You are using the Dequeue.vi to read the queue in LV, aren't you?
Oli
06-23-2016 04:01 AM
@Oli_Wachno wrote:Hi Michael,
am I right, you are using a LabVIEW queue? Is it size limited? You are using the Dequeue.vi to read the queue in LV, aren't you?
Oli
No I am using a Teststand iQueue and I get its reference from the synchronisation manager through the LabVIEW API for teststand. Therefore the dequeue "vi" is a method of the iQueue object.
I tried both - limited size and unlimited size. I might be wrong, but there would be a serious problem with the queue algorithm if the size would matter . Queue acess should happen through pointer handling and not by moving data.
I access the queue with a -1 seconds timeout setting, which means it is waiting till the end of days if i do not put data in the queue.
The data in the queue are provided by the PostResultListEntry Callback which contains a queue step which is set to "Enqueue".
It works very good, I am getting all the information I want. The problem is that when I am waiting for new data from the queue, the sequence step processing slows down. It takes about 3 seconds per step. Before (without dequeuing) it was about 80 ms. I wouldn't have a problem if only fetching was slow, because i could do a bolk dequeue. But the actual execution seems to wait for the queue.
To me it seems to be a connection problem. There is probably a slow handshake between the LabView application and the synchronisation manager and probably the queue is locked in that time. I have already put the enqueueing in a separate thread.
06-23-2016 05:27 AM
Sounds strange... I haven't worked with this kind of queues yet.
Instead, I am using Wrapper VIs to access LabVIEW queues. I prefer this way, since I feel like being able to debug more easily this way
06-23-2016 07:04 AM
Yeah it is weird, this sort of behaviour is something I would never expect in an object which is called "queue". It should be able to enqueue and dequeue independently.
@Oli_Wachno wrote:Sounds strange... I haven't worked with this kind of queues yet.
Instead, I am using Wrapper VIs to access LabVIEW queues. I prefer this way, since I feel like being able to debug more easily this way
06-23-2016 10:00 AM - edited 06-23-2016 10:01 AM
Are you passing "true" for the processMsgs argument to Dequeue? If not, try doing so. Also if you are doing this from a step in a sequence via a code module call into a labview VI, pass the step's sequence context in for the sequence context parameter.
-Doug
06-23-2016 10:17 AM
Thank you! That was the help of the day. Its runnig extremly fast, I cann even do an bulk readout because the sequence is faster than the processing application.
ProcessMsgs was false. I would appreciate if you could explain why this parameter stops the step execution while dequeuing.
The context help says: Pass True to process Microsoft Windows messages while waiting. When you call this method from an execution. pass True for this parameter. Otherwise pass False.
Does this mean, that if I call the method from isnside an action step I should pass False and otherwise True? I do not understand what is meant by "from an execution".
06-24-2016 09:24 AM
From an execution means if your code is called from a step of a teststand execution (as opposed to from the User-Interface thread of the application) it almost always makes sense to pass true because those threads aren't UI threads so processing messages isn't likely to have any side effects. Sometimes processing messages in a UI thread leads to unintended consequences like allowing user-input or timer events when the program isn't expecting it, that is why it's not always done.
Window messages are often used to make cross-thread calls synchronously (i.e. send a message that tells the receiving thread to do something and wait for it to finish). That can lead to delays and hangs if the receiving thread isn't processing messages, because in that case the calling thread waits until the receiving thread is again processing the message and is then able to do what it is asking.
Another thing that might also have fixed your issue is to change which execution system your VI's are using if they are currently executing in the UI thread of LabVIEW (not 100% sure though, I'm really not a LabVIEW expert). I suspect the issue is related to another thread trying to send a message to the thread LabVIEW is using to make calls into the TestStand API, and that other thread is likely trying to make a cross-thread call and is waiting for it to complete. And that is likely keeping you from being able to run other LabVIEW steps. I'm really not 100% sure what the exact issue is in this case, because I'm not a LabVIEW expert. Perhaps someone who is could fill in more details.
Hope this helps,
-Doug