Reading measurements on 3 serial ports--how to do so in parallel?

[dmafackler]

Issue:

Magnetic moments are read out from a cryogenic magnetometer on 3 serial ports (X, Y, Z channels). The read-out cycle is identical for each channel. A single re-entrant VI wrappers the required command structure and serial communications. Parallel instances of that VI were placed in a single for loop, achieving full X, Y, Z readout in 0.5 seconds. But something has changed--now we are seeing 4.0 seconds loop cycle times to achieve the same full X, Y, Z readout. Same code, different parallelizing behavior. What changed?

What conditions must be met for LabVIEW to guarantee parallel execution of the underlying serial communications chains? 

The underlying hardware is NI-8430/8. Driver NI-Serial 3.5/6(double-checking). Running LV2009sp1 x32 on Win7 x64. 

The parallel serial operation is a valuable time-saver to our laboratory. Instead of a full sample sequence taking an hour, it could be done in 10 minutes. [75 measurement cycles per sample x 10 passes, demagnetization treatments between passes].

Any knowledgebase items or papers you can point us to for refining our understanding of LabVIEW parallelization with respect to serial I/O?

Code here:

http://millstone.iodp.tamu.edu/~fackler/Read2G/

Read2G.orig.7z is the version we saw work with 0.5 sec readout cycle times.

Read2G.alt.7z is a variant attempting to achieve the same by providing more hints to LabVIEW.

[Yes. The magnetometer hardware is 1200 baud. No, its the only interface the vendor provides...perhaps a future project.]

2GCommand.vi is the re-entrant piece. GetAllMoments.vi is the wrapper that invokes the re-entrant bits, theoretically in parallel.

[Albert.Geven]

Hi

This looks correct but a bit overdone. In my view it should work in parallel.

I have no experience with this serial card. The only thing I can think of is to reduce the number of parallel executing vi's.

Now you have 3 different vi's (please change the icons) that are reentrant but serialized by the error wire.

Because the vi's are different reentrancy is not needed.

I hope somebody else finds a real answer.

[dmafackler]

Thanks for taking a look.

Have a ticket open with NI.

Pursuing my education there.

Are you aware of other conditions than explicit wiring, re-entrancy that can affect LabVIEWs choice of parallelization?

Do VI properties affect parallelizability? e.g. "Enable debugging", "Automatic error handling", choice of thread space?

Any known external factors that also affect LabVIEWs parallel capability (OS, BIOS settings, multi-core processing settings)?

Regards from 28 35.75' S 173 22.83' W

[Albert.Geven]

I always leave it to labview to choose threads.

I did not check your vi's but they never should be in the user thread.