More deterministic execution with Windows

[crossrulz]

---

@rowdyr wrote:

My application is mostly sequential due to the data flow. I didn't see how producer consumer loops could help in such a case. Image processing can't happen until the image is acquired and data output can't occur until image processing is finished. Would producer consumer loops speed that up?

---

What the Producer/Consumer does is create a Pipeline.  So the producer loop would acquire the image and pass it on to the consumer loop (the processing loop).  While the image is being processed, the producer loop can be looking for a new trigger.  You could go further and have the processing loop send messages to other loops to update the UI, send whatever output, log data, etc.

[billko]

---

@crossrulz wrote:

---

@rowdyr wrote:

My application is mostly sequential due to the data flow. I didn't see how producer consumer loops could help in such a case. Image processing can't happen until the image is acquired and data output can't occur until image processing is finished. Would producer consumer loops speed that up?

---

What the Producer/Consumer does is create a Pipeline.  So the producer loop would acquire the image and pass it on to the consumer loop (the processing loop).  While the image is being processed, the producer loop can be looking for a new trigger.  You could go further and have the processing loop send messages to other loops to update the UI, send whatever output, log data, etc.

---

If you saw the old Lucille Ball "I love Lucy" episode with the chocolate candy on the conveyor belt, that is an example of a lossy queue.

[RTSLVU]

---

@rowdyr wrote:

Thanks for all those ideas recommending producer consumer loops. I haven't tried that yet. My application is mostly sequential due to the data flow. I didn't see how producer consumer loops could help in such a case. Image processing can't happen until the image is acquired and data output can't occur until image processing is finished. Would producer consumer loops speed that up? Sorry I can't really post code due to our company's policy but it is a rather large event handler and state machine within a loop.

---

The Producer Loop will acquire an image and place it in a Queue, then acquire another image and place it in the Queue, then acquire another... until told to stop.

The Consumer Loop will Dequeue an image, process it, and output data completely independent of and without effecting the timing of the Producer Loop.

[mcduff]

One other thing to consider, beside removing property nodes. Is your DLL thread safe? If so, you can configure it to run in any thread. By default it is usually set to run in the UI thread, having it run in any thread may help as you don’t need to wait for the UI thread.

[johntrich1971]

---

Thanks for all those ideas recommending producer consumer loops. I haven't tried that yet. My application is mostly sequential due to the data flow. I didn't see how producer consumer loops could help in such a case. Image processing can't happen until the image is acquired and data output can't occur until image processing is finished. Would producer consumer loops speed that up? Sorry I can't really post code due to our company's policy but it is a rather large event handler and state machine within a loop.

---

A producer/consumer loop is, by default, sequential. There are a number of advantages. First, it allows data collection and processing to be ran in parallel. This keeps the data collection loop free for the next iteration. 

One problem with a Windows system is that sometimes a processing loop will take longer than expected. If you are only using one loop this might put you over the limit. If you are using a producer/consumer architecture you will not lose any data as long as the average time to process the data is less than the average time to obtain the data. If Windows takes a little longer on one loop to complete the processing it's not a problem as it will catch up on the next iteration. Things do become more complex when average processing time is longer than the data collection time, but that doesn't seem to be the case in your situation.

[rowdyr]

Thanks to everyone for their suggestions. After a bit of detective work I found the issue was actually two main problems. Firstly the camera settings were not correct so it wasn't able to trigger at the required hardware trigger rate. Secondly, I had used a few property nodes to update the front panel controls. Once I removed these, the loop time was much more consistent. There is quite a bit going on in the UI so doing things like dragging the window would cause delays of 100s of milliseconds.

I also gained some improvement in execution speed by moving to the 64-bit LabVIEW version. Not a lot (approx. 10% faster) but still helps reduce the chance of missing frames. Didn't try out the producer consumer loop but will probably do it that way next time.

[billko]

---

@rowdyr wrote:

Thanks to everyone for their suggestions. After a bit of detective work I found the issue was actually two main problems. Firstly the camera settings were not correct so it wasn't able to trigger at the required hardware trigger rate. Secondly, I had used a few property nodes to update the front panel controls. Once I removed these, the loop time was much more consistent. There is quite a bit going on in the UI so doing things like dragging the window would cause delays of 100s of milliseconds.

I also gained some improvement in execution speed by moving to the 64-bit LabVIEW version. Not a lot (approx. 10% faster) but still helps reduce the chance of missing frames. Didn't try out the producer consumer loop but will probably do it that way next time.

---

If you used the producer consumer pattern, you would probably not miss a frame.

[RTSLVU]

---

@rowdyr wrote:

Thanks to everyone for their suggestions. After a bit of detective work I found the issue was actually two main problems. Firstly the camera settings were not correct so it wasn't able to trigger at the required hardware trigger rate. Secondly, I had used a few property nodes to update the front panel controls. Once I removed these, the loop time was much more consistent. There is quite a bit going on in the UI so doing things like dragging the window would cause delays of 100s of milliseconds.

I also gained some improvement in execution speed by moving to the 64-bit LabVIEW version. Not a lot (approx. 10% faster) but still helps reduce the chance of missing frames. Didn't try out the producer consumer loop but will probably do it that way next time.

---

I know it's going to be a lot of work, but IMHO: It's time to stop putting "a band-aid on a bullet hole" and us a proper program architecture. 

[Intaris]

---

@BertMcMahan wrote:

I'd recommend posting your code. Lagging during window drags isn't an unheard of problem, but it could point to some other issues. For example, overusing Property Nodes can slow things down since they require the UI thread.

---

This is exactly where my brain went to given your description of the problem.

Property nodes, context switches, root loop, all things we tend to overlook as LV developers which can cause all kids of scheduling and resource-contention issues in code. Freeing up your code to run completely independently of UI thread and root loop will greatly improve responsiveness.

The caveats with regard to windows timing and producer consumer are also valid, but my first point of action would be tracking down and re-positioning your property node calls.

[rowdyr]

After digging a bit more in the code, I am finding other areas where the UI thread is being invoked. The code is rather complex because it's interfacing with quite a few bits of hardware in addition to other stand-alone LabVIEW applications. I had disabled large parts of the code to track down and correct the timing issues but once I put it all back, the old problems resurfaced. I found property nodes scattered about third party libraries and DLL calls using the UI thread. I had also used VI Server for inter-application communications so now I need to rewrite using shared variables or network streams. Looks like I've started on the wrong foot 😩

Does anybody know if there is a way to track when the main program reverts to the UI thread? I have just been observing loop cycle times while dragging windows but that's not a particularly sophisticated method and it involves a lot of trial and error disabling and enabling sections of code.