LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Malleable VIs in Packed Project Libraries

Solved!
Go to solution

Well, it turned out to be a rather obscure phenomenon. I had a test VI call a VIM. The VIM is a public member of a class, and the VIM calls a VI from the class that has its access scope set to Private. The caller of the VIM is then not allowed to wire anything up to the VIM...

 

Trying to run the broken top level VI the VIM only complains about not supporting the wired data types, which it does...The real problem was that the private VI had a dynamic dispatch terminal which it is not allowed to in combination with the private scope. Unlike regular VIs though, the VIM did not include the underlying broken VI in its own error list (I could/should have noticed that in the overall error list though). Smiley Frustrated

 

 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 11 of 24
(383 Views)

@Mads  escreveu:

Unlike regular VIs though, the VIM did not include the underlying broken VI in its own error list (I could/should have noticed that in the overall error list though). Smiley Frustrated 


Though it's quite inconvenient not to show that the error is in the VIM, it was kind of expected, since the VIM is inlined.

0 Kudos
Message 12 of 24
(378 Views)

@hbaron93 wrote:

@Mads  escreveu:

Unlike regular VIs though, the VIM did not include the underlying broken VI in its own error list (I could/should have noticed that in the overall error list though). Smiley Frustrated 


Though it's quite inconvenient not to show that the error is in the VIM, it was kind of expected, since the VIM is inlined.


Yes, I thought about that too. It does excuse it a bit, but there are plenty of other situations where VIMs are "aware" that they are an entity on their own.  Another thing though is the way it no longer accepts any inputs, that's kind of worse...If the code was on the calling diagram that would not have been the case, only its sub-VI would be broken.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 13 of 24
(371 Views)
Highlighted

The weaknesses in the error handling for malleable class VIs hit me even worse when the real problem was that one of the VIs was calling a *protected* VI. Private VIs are OK in the malleable VI, but protected evidently not... Anyway - I had a nested malleable VI (Malleable class member was callig another malleable class member) that did not report anything sensible at all other than the "not supported data type"...and it produced some funny behaviour, just look at the video here:

 

 

So the VIM accepts a 2D Double and SGL array constant...(the malleable VIs have different code for those two data types by using the Type Specialization Structure with the Assert Type Match function) but then breaks and permanently so (until deleted from the diagram and reinserted) if it is wired those same data types generated in a for loop for example Smiley Surprised

 

The well hidden reason for this strange behavior was that the top level malleable VI called some protected VIs from its own class, but as you can see this would only break anything if a non-constant array was wired to it from the calling VI - and then with no errors related to class protection at all.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 14 of 24
(358 Views)

Mads: Seems buggy. I'll check into it.

0 Kudos
Message 15 of 24
(313 Views)

I can't replicate issue... protected VIs are working fine in my test cases. I tried some more exotic things without success. What's the block diagram of your malleable VI look like?

0 Kudos
Message 16 of 24
(310 Views)

Mads doesn't have the VIs shown in the video anymore. He tried to recreate but could not replicate the issue. I tried several variations and could not replicate. If anyone else sees this issue, please take the time to file a bug report with National Instruments, with attached VIs. It's apparently more of a corner case than originally believed, so I'll need VIs to replicate and fix the bug.

0 Kudos
Message 17 of 24
(294 Views)

So is it true that you cannot have malleable vi's made publicly available from a packed project library?  I've been able to create a PPL that internally uses a malleable vi, but any public scoped malleable vi's are not available from the PPL file.

0 Kudos
Message 18 of 24
(275 Views)

Hi AQ! I'm having this issue in LV2017 sp1 32-bit. Protected dynamic dispatch VIs called inside a malleable VI (inside a TSS) do not dispatch their overrides (yet no edit-time errors). Everything works fine when the DD API is all Public.

 

I submitted a service request with a link to this thread. I'm also posting the source here if anyone wants to take a peek.

 

Steps to reproduce:

  • Open project
  • Open and Run Sandbox.vi (Expected behavior. You can change the requested type per diagram comments to see the edit-time polymorphism work correctly.)
  • Go to IConfiguration.lvclass and set all of its API methods to Protected (and apply change to all children) to observe the other behavior.
  • Control-click the run arrow in Sandbox.vi (REQUIRED, I think)
  • Run Sandbox.vi (With no injected type change, you will now see only the base class's methods dispatched--incorrectly)

 

You will see two different run-time behaviors, where the Protected behavior does not make sense (to me). The DD VIs should always dispatch to the injected type. If that's not possible, I would expect to see an edit-time error.

 

- Ethan

0 Kudos
Message 19 of 24
(150 Views)

I submitted a post describing a similar problem in my code. Then it then got flagged as spam and placed in form purgatory. I'll see if it gets moderated back into existence. 

 

P.S. This problem seems to have nothing to do with PPLs because I'm not using them. But I think the symptom is the same as what's being discussed here.

 

- Ethan

0 Kudos
Message 20 of 24
(192 Views)