Threads

[mishklyar]

Hello all,

  I have some question about Labview threads and Windows. We have producer/consumer pattern for data aquisition.

Producer loop  acquires the data and pushes it to the queue.

Producer loop is a quite complex, it contains NI analog output and another two IO cards that programmed via DLL's.

I would like to optimize the speed of the Producer loop,to do so, I suggested to put the Producer loop to the different thread.

Now I wonder if it possible,and how, so I can be sure that Producer loop runs in the different Windows thread with realtime priority?

I am familiar with VI server etc., but didn't find the way to be shure it runs in the separate Windows thread.Is it possible at all?

Michael.

[Norbert_B · Accepted solution]

---

mishklyar wrote:
[...]Windows thread with realtime priority?[...]

---

Michael,

that is an antagonism. Windows and Realtime exclude one another.

That being said, we can try to increase performance of certain tasks/threads to achieve performance comparable to realtime.

First of all, you must not run any other software in the background. Disable all non-critical services like screensaver, hard drive indexing, firewalls and virus scan tools.

Second step: Increase the priority of LabVIEW.exe to Realtime using task manager. You have to do this because all threads created by LV have the maximum priority of LabVIEW.exe in regard to the OS. Please note that from this moment, a hang in LV will most probably hang the whole system!

Third step: Create different priorities for your LV "tasks". The easiest way is using timed loops.

Please note that this approach i static is highly not recommended and can lead to an instable system. If you need realtime applications, it is recommended to use dedicated realtime platforms like LV RT or FPGAs.

hope this helps,

Norbert 

[mishklyar]

Now I think, may be there is some trick, so that Producer loop would be another Application instance?

May be make the Producer loop Labview dll ? But what about queues then?

Should I pass the data via TCP/IP between producer/consumer?

[Norbert_B]

I think the far better approach is to consider why you need realtime. What are your requirements in regard to timing?

If the requirements state that there must be a jitter less than 1ms in the system, forget about Windows. There is no way to guarante this.

If you should stay below 1ms jitter, but it can exceed this, Windows might be ok.  

I would suggest you to split up the application. You will introduce additional latencies because you cannot use in-process mechanics for transfer of data (e.g. queues).

The best way is to remove all disturbing processes from the system as far as possible and increase performance of the LV application. Setting priorities is the last wrench to use to make the application work as desired.

So if you do not see a chance currently to achieve the needed performance, playing around with priorities will do no good (in fact, experience shows that this will completly mess up the system!). 

You can find many tips for increasing performance in this forum, esp. the nuggets are often valuable. And you can take a look into the Goldberg-thread in the Breakpoint-area of this forum for some other quite interesting hints and tips...... 

hope this helps,

Norbert 

[mishklyar]

 "I would suggest you to split up the application. " 

Did you meant "wouldn't" ? 🙂

Thanks

[Norbert_B]

Yes, you are right....sure i meant "you should not split it up" 😉

Norbert 

[Ben]

After almost 12 years of LV development, I have yet to see an app that could be "fixed" by messing with priorities.

Setting a thread to Real-Time will set it priority higher than the driver for your mouse so "lock-ups" are guarenteed.

Don't mess with priority.

Instead make your code more effiecient!

Post the code that is putting the high load on your CPU and ask the contributors here to review and comment. if you do not want to post your code you could review the links I have collected in the "LabVIEW_Performance" cloud. Now without looking... Buffer allocation and copies are frequently an issue.

Just trying to help,

Ben

Message Edited by Ben on 11-10-2009 08:02 AM