Strange issue when loading/porting VIs containing malleable VIs (LabVIEW 2019 x64)

[Stinus Olsen]

So a coworker sent me a project that needed to have some refactoring/restructuring done.

When I open the project, the entire AF hierarchy loads broken because I shuffled around some dependencies packed as LVLIBPs.

That was to be expected.

What I didn't expect was LabVIEW complaining over some missing malleable VIs, since we only use the builtin ones.

Nevertheless it really really doesn't want to find the Stall Data Flow vim - and it's being pretty persistent about it:

I tried the "Search VI" trick of deleting the VI, then CTRL-Z'ing it back into existence - but LabVIEW doesn't pop the usual browse dialog in this case.

In the picture above there was originally two missing vim's, but I replaced the first one manually, just to show you that the vim is available on my machine.

Double-clicking on the missing vim yields the "I'm missing this <GUID> vi" dialog.

Any ideas on why LabVIEW is keen on not recognizing the vim in my installation?

Cheers

[thols]

I cannot help but at least I can say that this happens to me too. But I had issues migrating channel wires at the same time so I never took the time to isolate this issue. I could not come up with a better workaround than you did, replacing every node.

[wiebe@CARYA]

Did any conversion happened? E.g. from 32 to 64 bit or LV18 to LV19?

Does this happen to all .vims? If some do load, it would be interesting to see what the difference is.

Is compiled code separation on or off? IIRC, that can mess things up quite a bit.

[Stinus Olsen]

Those are good questions 👍

My coworker lifted the code from LV2017 32-bit to LV2019 64-bit on his machine, and after I experienced the issue in my initial post I asked him about if he had any issues.

It turned out he saw some issues too when he did the conversion..!

Comparing our environments it turned out he was running LV2019 x64 SP1 and I was just running the base version.

Being under pressure time-wise I didn't investigate further - I upgraded my own LabVIEW version to SP1, relinked the project and stuck my nose in the track.

This morning however, I had the opportunity of pulling the project from our SVN onto a freshly upgraded PC (LV2019 x64 upgraded to LV2019 x64 SP1), and behold - the issue happened again..!

Error window complains about hierarchy being broken, SubVIs not being executable etc. - Stall Data Flow.vim missing - open one of the VIs that are missing it, double click on the missing VI - LabVIEW pops the <GUID>.vi missing dialog...

This happens for ALL used standard .vim files AND the ones installed through VIPM (for example "From JSON Text.vim" from the JSONtext package from JDP Science [1.3.1.84]).

The VIs that are calling the .vim files does use code separation - but AFAIAC that shouldn't give any issue with the built-in VIs like the Stall Data Flow.vim?!

[wiebe@CARYA]

---

@Stinus Olsen wrote:

The VIs that are calling the .vim files does use code separation - but AFAIAC that shouldn't give any issue with the built-in VIs like the Stall Data Flow.vim?!

---

I'd say it shouldn't happen at all 😁. Code separation does complicate things and cause trouble every now and then. Especially with funky stuff, like channel wires. Things that are probably cached?

Do you have your own .vims, and do they work OK?

When 17SP1 was just released, I posted a bug that LV13 .vims (yes, they did exist back then) where missing after converting. It was dismissed as "that's not supported".

I just hope that the problem is not with converting .vims in general (as I suspected and mentioned back then).

[Stinus Olsen]

---

wiebe@CARYA wrote:

I'd say it shouldn't happen at all 😁. ...

---

 Exactly and true that..!

---

Do you have your own .vims, and do they work OK?

---

Yes we do, but none that is used in this project, unfortunately..

Just clearing the VI cache doesn't provoke the issue again, but that may be caused by the fact that the code is now in the correct version for _that_ machine.

If I get the opportunity again, I will try upgrading the code on a new installation and see what changes.

Maybe I should just create a VM just for the sake of it, set disk to be non-persistent and try it over and over again 😄

(don't have the time atm though)

[J.C._Andersen]

I have had a similar experience just two days ago.

What happened here was that my college had made a project in LabVIEW 2019 SP1 and I was going to review it on my VM with LabVIEW 2019 f1, so I did not have the SP1. I should mention that both our LabVIEW versions are 32 bit.

In his code he uses some VIM's from one of out internal tool packages, and those VIM's did not load on my machine. I got the ghosted question mark VI's on the BD and when I looked at them with context help, it displayed <GUID>.vim.

The first thing i tried was to upgrade my VM to LabVIEW 2019 SP1. After the reboot I opened the project again, but the result was the same. Then I cleared the compiled objects cache and reloaded again. This did the trick, and it all loaded as it should.

To me this suggests that there might be problem with moving code containing VIM's built with LabVIEW 2019 SP1 to LabVIEW 2019 developer machine.