LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Real-Time Application doesn't run; source code works fine

Solved!
Go to solution

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.

Message 21 of 27
(1,542 Views)

@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.  

Message 22 of 27
(1,541 Views)

@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?

Message 23 of 27
(1,537 Views)

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.

0 Kudos
Message 24 of 27
(1,524 Views)
Solution
Accepted by thutch79

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:

  • Code with VIMs would not build in anything earlier than 2019
  • We had an incorrectly scoped method in a class that was not being caught in the IDE in LV earlier than 2019, but was causing the build to break. That was impossible to find in the build even with debug turned on. It wasn't until LV2019 caught it that we saw the issue.

Even with LV2019, we needed to uncheck "remove unused polymorphic VIs" in the build spec.

Message 25 of 27
(1,359 Views)

@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.

0 Kudos
Message 26 of 27
(1,341 Views)

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.

0 Kudos
Message 27 of 27
(1,325 Views)