LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2020 errors when creating Override for a class in a PPL with debugging enabled

Solved!
Go to solution

I've opened a support request for this, but I'm going to post to the forum too for the following possible reasons:

  • Maybe I did something stupid and someone can point it out
  • Others might run into this and search online (in which case, it might be reassuring if nothing else)
  • It might be that someone else can helpfully try and either reproduce or fail to reproduce the issue

 

When creating a New > VI for Override in a class that inherits from a class in a Packed Project Library with debugging enabled in LabVIEW 2020, the VI fails to be created with an error 7 in CLSUIP_CreateNewVI.vi

The error occurs inside the "No Error" case (which is why debugging enabled is important - with no debugging in the PPL the block diagram doesn't load and the scripting goes through the error case) when trying to load based on a template VI (the dynamic dispatch VI in the PPL).

OverrideFrom2019PPL.png

 

Initially I ran into this using a PPL built in 2019 - I reproduced it using a new 2020 PPL with only one class and one (DD) VI.

 

Possible reproduction steps are:

  1. Create a blank project
  2. Add a library, then a class, then a dynamic dispatch VI from template
  3. Create a Packed Project Library build specification.
  4. On the "Advanced" tab, set the Enabled Debugging to true
  5. Build the PPL
  6. Create a new project
  7. Add > Item the built PPL from step 5
  8. Create a new class (the new window makes this step much nicer - yay 2020...) and inherit from the class created in step 2+5.
  9. Right click on the class and choose New > VI for Override and then choose the VI that's available.
  10. Get the error message.

Note that if you don't do step 4, there is no error.

The error appears to be the same if you use PPLs that you already have available from e.g. 2019 (in which case skip steps 1-5).

 


GCentral
Message 1 of 7
(3,523 Views)

Following your steps above, I can reproduce the issue. So it's not just you, you can rest easy.

Message 2 of 7
(3,458 Views)
Solution
Accepted by topic author cbutcher

Bug number 1047200 (replacing "legacy CAR ID", apparently) was filed against this.

 

Possible workarounds include

a) Modify LabVIEW 2020\resource\Framework\Providers\LVClassLibrary\NewAccessors\VIRetooler\CLSUIP_CreateNewVI.vi to always error in the middle case structure

b) Don't use debugging-enabled PPLs

c) Manually override (don't use the scripting).


GCentral
Message 3 of 7
(3,413 Views)

A bit late to the party here, but the same appears when you select override from the tool menu. So manual override is really "manual"!

0 Kudos
Message 4 of 7
(3,164 Views)

Hi guys,

I'm having the same problem with PPLs with debugging enabled, on a cRIO target.
About the workarounds suggested by Christian:
a) It worked for me! Thank you!
b) Painfull option (as all the PPL adventure on cRIO)
c) When you say "manually override", it meens :
- create a new VI from dynamic dispatch template
- add the right vi inputs/outputs
- save with the same name than the one you want to override
- optionnaly adapt the vi exection option
is that right?

 

Just something to notice, the exact same project with a parent PPL and a child trying to override a VI produce the problem on my machine, but NOT on my colleague's one. So there must be something contextual to this error.

Message 5 of 7
(2,822 Views)

@Jonzarwal wrote:

Hi guys,

...
c) When you say "manually override", it meens :
- create a new VI from dynamic dispatch template
- add the right vi inputs/outputs
- save with the same name than the one you want to override
- optionnaly adapt the vi exection option
is that right?

 


Exactly 😞 You also have to deal with required/recommended connector pane options, although maybe you included that in "add the right vi inputs/outputs".

 


@Jonzarwal wrote:

Just something to notice, the exact same project with a parent PPL and a child trying to override a VI produce the problem on my machine, but NOT on my colleague's one. So there must be something contextual to this error.


How odd... Thanks for letting me know - maybe this can be useful to NI etc if it reappears.

 

The bug-list/fixes at https://www.ni.com/en-gb/support/documentation/bugs/20/labview-2020-bug-fixes.html show this was fixed in 2020f1, so hopefully updating is also an option? (I don't recall right now, and mostly work in LV2019 currently).

 


GCentral
0 Kudos
Message 6 of 7
(2,811 Views)

Ok that makes sense. I have LV2020, and my colleague is LV2020f2.

So i'm upgrading.

Thanks for the feedback!

0 Kudos
Message 7 of 7
(2,800 Views)