Multithreading with 8.2

[cobra21]

I am designing a fast-scanning labview program which controls both a piezo stage and photon detectors. Threads for stage movement and data acquisition are completely separated without any data dependencies. But it seems like the stage moves quite randomly when data acquisition is in progress at the same time. For example, the stage was supposed to scan for 100ms per each line (which is implemented by a timed loop to fire triggers in a constant rate), but hardware response for that varies from 60 to 200. Then I redesigned a VI for data acquisition only and ran it with a compiled version of stage controller VI, which eliminated the problem. I wonder why this happens and also if it is possible to ensure time-strict multithreading without any upgrade from 8.20 or introducing real-time module. If not, can they be a solution?

I will post the code upon request, but to briefly describe it, a thread for the stage is in a timed loop and for data acquisition in a for loop. Those two call library functions inside the loops. i heard from manufacturers of two devices that they are not USB demanding and should work well each other. My CPU is 2.3GHz dual-cure.

[Aristos Queue]

Strict timing always requires the real-time operating system. You simply cannot guarantee timing using MS Windows or any of the desktop operating systems. You can get very close by turning off screen savers, virus checking, file caching, and a host of other aspects of the system, but you'll never get to the point of zero interrupts in your time-critical thread.

You should talk to your area NI sales person to get a good handle on exactly which LV version is the one for your needs. They're the most qualified to differentiate the different tools.

[silmaril]

ZITAT(cobra21 @ Aug 7 2007, 03:31 PM)

I am designing a fast-scanning labview program which controls both a piezo stage and photon detectors. Threads for stage movement and data acquisition are completely separated without any data dependencies. But it seems like the stage moves quite randomly when data acquisition is in progress at the same time. For example, the stage was supposed to scan for 100ms per each line (which is implemented by a timed loop to fire triggers in a constant rate), but hardware response for that varies from 60 to 200. Then I redesigned a VI for data acquisition only and ran it with a compiled version of stage controller VI, which eliminated the problem. I wonder why this happens and also if it is possible to ensure time-strict multithreading without any upgrade from 8.20 or introducing real-time module. If not, can they be a solution?

I will post the code upon request, but to briefly describe it, a thread for the stage is in a timed loop and for data acquisition in a for loop. Those two call library functions inside the loops. i heard from manufacturers of two devices that they are not USB demanding and should work well each other. My CPU is 2.3GHz dual-cure.

Which kind of hardware are you using?

Maybe there is some better way to programm your application.

On the acquisition side you should be using a buffered acquisition (most propably continous).

Depending on which hardware you use, you might be able to use buffered output as well (or programm the complete movement in advance on a motion board).

The point is: if your I/O hardware can do the critical timing, all your LV application has to do is initialize it and get all the data when there is time

This doen't sound to me, as if you really need an RT system.

[LAVA 1.0 Content]

QUOTE(silmaril @ Aug 7 2007, 12:32 PM)

Which kind of hardware are you using?

The point is: if your I/O hardware can do the critical timing, all your LV application has to do is initialize it and get all the data when there is time

QUOTE(cobra21 @ Aug 7 2007, 09:31 AM)

i heard from manufacturers of two devices that they are not USB demanding and should work well each other. My CPU is 2.3GHz dual-cure.

USB? Hmmm. Is it USB 2.0 compliant? Are there intermediate drivers or is ActiveX involved?

When I hear USB instrumentation, I also start to think laptop computer. A laptop might be configured to conserve power causing I/O delays... USB is fast, but not deterministic. If you're passing alot of data back and forth then there might be blocking; the USB interface is busy on a large read of data and is not available for a write...