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: 

Details regarding CAR 670058

I am looking for more information regarding the issue mentioned here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001DpAbCAK&l=en-US#

and tracked by CAR 670058. Other than the link above, I am unable to find additional information regarding this issue.

 

This error occurs intermittently on our test stations, using TestStand 2014 (32 bit) and LabView 2015 SP1 f10 (15.0.1) (32-bit) and associated LabVIEW Run-Time Engine.

 

As not using private scope is not a viable option for us, I am very curious about additional details regarding this issue. Specifically, is there a fix for this in certain versions or patches of the Run-Time Engine? Are there other known causes for this error message, especially when it occurs with known good code/PPLs and this message only appears intermittently? Are there any precursor events, which we could attempt to avoid, which causes the intermittent appearance of this issue?

 

One thing I have noticed is that once this error occurs for one PPL, it will occur for all PPL calls until all of TestStand and LabVIEW are completely shut down and then restarted. Sometimes "Unload All Modules" will resolve the issue.

 

I cannot reliably reproduce the issue, but it does seem to occur with some frequency, on the order of weekly.

Message 1 of 3
(948 Views)

Same thing here, just stumbled over this issue while trying to deploy a new machine

0 Kudos
Message 2 of 3
(897 Views)

It's possible that there might be different root issues that lead to the same error report that you're seeing, but the investigation of CAR 670058 has found that member VIs referencing private type definitions within the same PPL are erroneously broken on load (because they're not correctly detecting that they're in the same PPL).

 

We don't have a timeline for a fix yet, but there are several possible workarounds:

  1. Disconnect type defs when building PPLs.
  2. Make all type defs in PPLs have public access scope.
  3. Make any member VI that uses a private type def also be private.
  4. Make all methods and type defs in the PPL public (as mentioned in the KB).

I hope that one of these might prove helpful.


Christina Rogers
Principal Product Owner, LabVIEW R&D
Message 3 of 3
(817 Views)