LabVIEW
PSA - Cannot Save a bad VI without its block diagram while building (vims!)
Solved!
Have been having build issues from some minor changes to the code. With the build either straight crashing, or giving me the error "Cannot save a bad VI without it's block diagram" - and then mentioning the top level build VI.
The code ran find in dev, and you could get it to build if you enabled debugging in the build spec.
After too much enabling/disabling sections of code, narrowed it down to a vim.
Tried looking at these, which helped but ended up on a redherring.
The issue ended up being a private data type, from an api, being fed into a vim.
LabVIEW will only complain about out of scope typedefs if there is a constant or FP node. The actual data wire doesn't complain.
The setup below has a:
- lib providing data in a variant, with a (private!) typedef so the data can be unflattened later
- a vim to convert the data, which is just a variant to data wrapper.
This runs completely fine.
But building with standard options gives:
This error would be the same if it's buried several vi's down - making it hard to find.
My assumption is this:
- in dev, inline the vim straight on the block diagram and deal with the cases
- in build, build the specific version of that vim at that point in time into a temporary vi, optimise the vi, then inline in it into the calling vi.
The differences can be seen in using the two right click options for the vim below. Replace and inline works, convert to vi complains about out of scope.
Anyway hope that helps someone as I spent too long finding this.
For you picky types - yes this is a stupid example. The real example is an queue, so we can async call multiple api's and collect the data later - so having the data typedef as part of the vi helps coding. And yes if a public api is giving data, that data should be public, it was a mistake.
