From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug? Parallel Instance ID overshoot (2011SP1)

The parallel FOR loop P terminal can be configured to output the parallel Instance ID (new in LabVIEW 2011). I think I run into a bug that will be rarely exposed, but can be difficult to track down.

 

Simple example:

Configure a Parallel FOR loop for 32 parallel instances, wire a 32 to the P terminal and set N to a higher number.

 

To demonstrate, create an array of the parallel instance IDs generated (autoindexing output tunnel) and observe that the highest ID is 32 (!!!). What's wrong with that, you ask? Well, the lowest ID is zero, meaning we actually get 33 different instance IDs, one too many!

 

Since I am using the P(ID) to index into an array of 32 DLL paths, to be called with a CLFN via the path input, it means that approximately one in 33 calls to the CLFN fails because the array only contains 32 elements (index=0..31) and trying to get index 32 results in a silent failure (except for randomly wrong results)

 

I tried on a old dual core notebook as well as on a dual Xeon E5 system with 32 logical cores. Same result.

 

Bummer! Is there a CAR for this? Thanks!

 

Message 1 of 8
(2,820 Views)

Hey altenbach,

 

The error you mentioned cannot be reproduced on my computer, I tried on a desktop with Intel Xeron Processor W3505. Could you run the attached code on your computer? 

 

Also could you post your code here? I want to run it to see if I could reproduce the error.

 

Thanks

 

Yupeng J.
Download All
0 Kudos
Message 2 of 8
(2,778 Views)

Sorry, I am cuRrently on thE bus.

0 Kudos
Message 3 of 8
(2,766 Views)

I agree that the highest ID should be 31, and in running this test code, it has always showed to be 31. However, according to your original post, you were seeing the highest ID as 32. This 32 is the incorrect behavior that the code tests for (and is unable to reproduce on my machine). Please test the attached code later and let me know how it works for you. Also I'm interested to test yours on my machine, please post it if possible. 

Yupeng J.
0 Kudos
Message 4 of 8
(2,751 Views)

Yes, I cannot always create a new VI and see the behavior, but It happens quite often.

 

Here is a sample VI simplified from my application directly. I substituted a dummy subVI with a small delay to make things realistic.

 

The array of IDs here is either [0,32] or [31,32] in my 32 core machine. Note that the parallel instances is zero by default. Even if you set it to -1 or 32, the outcome does not change. The max ID is 32 while it should only be 31!

 

Hopefully you can reproduce this. Thanks! Currently, there are only two iterations due to the autoindexing array size but I see the problem with all sizes..

 

Message 5 of 8
(2,735 Views)

Your code is simplied to reproduce the error on my machine. Please check the attachment. This error had been reported to our R&D and the error will be fixed in the future version of LabVIEW. Thanks a lot for reporting the error. 

 

Yupeng J.
Download All
Message 6 of 8
(2,698 Views)

Yes, thanks. The new code still reproduces the problem on all machines that I have tried.

0 Kudos
Message 7 of 8
(2,673 Views)

CAR 362584 was fixed in LabVIEW 2012. You would see this behavior in LabVIEW 2010 and 2011 if you have a non-accumulating output tunnel on the For Loop and you configure the P terminal to output the instance ID.

Message 8 of 8
(2,616 Views)