06-11-2019 09:55 AM
Intaris--I'm frankly amazed that you're able to use malleable VIs in a version of LV that is 2 years older than the version in which they were released. Did you have to do anything special to allow that code to compile or make the IDE not lose its mind? (Fingers crossed, I will not be trying this myself, but you've piqued my interest!)
Trying not to get hung up on semantics, but a significant design flaw = an edit-time bug in the IDE
Inlining a VI abstracts placement and compile details from a human reading the code. A VIM is an inlined VI with the special ability to allow polymorphism to traverse its connector pane. In no other instance does a developer need to delete and replace an inlined subVI to trigger the environment to update a VI's functionality (inlined or otherwise). Unless I hear an explanation directly from Aristos Queue (or someone at NI with similar qualifications) that this is either a known limitation in the IDE's ability to handle malleability or intended--for a reason I have yet to comprehend--it is an issue to be solved by NI, and hopefully soon.
06-11-2019 09:55 AM
@Intaris wrote:
It's how I understand it, yes. But like I said, I'm working in an older LV version, things may have changed.
But you shouldn't think of a vim as a sub-VI. It isn't. It's more like the option "drop the contents of this VI when dragged". But with a get-out-of-jail free option to update later.
This is not true. If you right click and select convert instance VI to standard VI you lose the connection to the malleable VI, but otherwise any changes made to a malleable VI propagate to all instances.
06-11-2019 09:59 AM - edited 06-11-2019 10:02 AM
@Intaris wrote:
But you shouldn't think of a vim as a sub-VI. It isn't. It's more like the option "drop the contents of this VI when dragged".
That would be madness! How would you ever keep track of what code is running where? How would you update all your malleable VIs in your project when you update the .vim source? Thankfully, this is not the behavior that I'm familiar with in later LabVIEW versions.
I'm using LabVIEW 2017 SP1 and LabVIEW 2018 and make extensive use of malleable VIs.
I have seen issues when trying to relink libraries that contain malleable VIs where the VIs containing .vims aren't properly marked as 'dirty' by LabVIEW and are not able to be recompiled properly (they show up in dependencies with a yellow triangle). To get around this, I added a few methods to the open source @cs/ci package on GPM called 'relink' and 'recompile'. Relink solves the problem using GPM-specific files, and Recompile works on any LabVIEW project. The recompile function works by getting all the project items and their dependencies, sorting them by dependency, forcing a compile, and then saving everything.
This was the function that finally solved the 'missing dependencies' issue when relinking libraries that contained malleable VIs. It feels like this could be improved under-the-hood in LabVIEW; maybe it has been in a newer version?
06-11-2019 10:07 AM
Hey Steve! Thanks for jumping in. I will look up those two tools and give them a try when I get some free time. Those sound like they could resolve the issue for me.
08-13-2019 09:36 AM
In an effort to try and round out this thread and not leave a dead-ended issue, here's the recap of what we found and the solution. Really, it came down to switching to LV 2019 to correctly build our project with VIMs included. I long ago in this thread eliminated the VIMs in our RT app and there wasn't a compelling reason to put them back in right now. I'm sure that will change over time, but for now, I haven't tested that build with VIMs again. I didn't have the same option with our PC side code as it runs deep with VIMs. In the end, we had two issues:
Even with LV2019, we needed to uncheck "remove unused polymorphic VIs" in the build spec.
08-13-2019 11:04 AM
@EthanStern wrote:
Intaris--I'm frankly amazed that you're able to use malleable VIs in a version of LV that is 2 years older than the version in which they were released. Did you have to do anything special to allow that code to compile or make the IDE not lose its mind? (Fingers crossed, I will not be trying this myself, but you've piqued my interest!)
No, just had to copy it into user.lib/macros and it worked. Well, for a given definition of "worked".
I use a single vim extensively in our FPGA code which serves as a "delay" line for any given datatype, up to 64 cycles delay and the value for the delay MUST be positive (there are some VIs on disk which help enforce this - if not positive and if not constant folded - throw a compile error before handing off to Xilinx.
My experience with VIMs is limited to LV 2015, so I would imagine it may well have improved since. But in 2015 they're cool but you have to take care. As others have mentioned, not surprising since they were super(secret)-unsupported back then.
08-13-2019 12:43 PM
Wacky. We've had a different dev team in parallel to thutch79 struggling with VIMs and builds. I second his wrap-up post above. A combination of updating to LV2019 and unchecking the "remove unused polymorphic instances" box are the only consistent solution. (Service request open to investigate and fix the checkbox issue.) Word directly from the horse's mouth is that VI inlining received major rework (supposedly 2018 sp1) to fix malleable build issues. We have only proven success in LV2019.