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.
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.
07-09-2012 09:30 PM
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!
07-10-2012 12:01 PM - edited 07-10-2012 12:10 PM
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
07-10-2012 12:10 PM - edited 07-10-2012 12:12 PM
Sorry, I am cuRrently on thE bus.
07-10-2012 12:27 PM
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.
07-10-2012 01:38 PM - edited 07-10-2012 01:53 PM
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..
07-10-2012 03:53 PM
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.
07-10-2012 05:32 PM
Yes, thanks. The new code still reproduces the problem on all machines that I have tried.
08-09-2012 11:26 AM
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.