Elapsed Time Express VI Occasionally Missing

[BASE10]

I'm having the same problem with LabVIEW 2019 and have seen it once before with an older version. I think I've only seen this occur on FPGA VIs.

Twice this week I have opened the VI in question and found that all the timing express VIs have changed to the question mark symbols and have to be replaced. In addition, the Butterworth filter express VIs all look fine but refuse to compile, giving the error "Butterworth Filter: XNode is not executable". If I open one of the filters and edit it, I get the following error when I click OK and have to replace all these VIs too, for a total of 21 replacements.

Things that might be relevant:

• All VIs in the project are set to "separate compiled code"
• Usually happens when moving code between machines, I'm using GIT now, but have seen it with manual copying too; however the latest incident did not involve moving code anywhere. I think I had just done a GIT Commit but that might be a red herring because I hadn't edited that VI that day. 
• Code stored in different directory on each machine.

It feels like it's either a path thing, with some piece of code not realising that the project has changed directory, or something to do with the "compiled object cache". Only guessing though.

I really hope someone from NI can help because this is going to go from frustrating to infuriating very quickly if it carries on! This problem has been around for at least 8 year now by the look of it. I've never used another programming language where so many of the problems I encounter REALLY ARE bugs that aren't my fault.

[Hooovahh]

Thanks for reminding me of this thread.  I still see this all the time in various LabVIEW versions up to and including 2018.  Over the years I've just been using my own version of this VI I named "Elapse Timer non-express" which has a couple minor improvements.  Every time I've used the native Express VI over the last 5 years I've at some point regretting it and replaced it with a normal SubVI.

[BertMcMahan]

I never use the Elapsed Time VI but I do use the Select File one... have you had the Select File one ever go corrupt on you, or is it just Elapsed Time?

[Hooovahh]

I think I have seen it on the browse for file Express VI but I think I use Elapse Timer more often which is probably why I've seen it be an issue more.

[BASE10]

It did it a couple more times yesterday. Rage rage rage!

Can you guys say if your problematic VIs are also set to "separate compiled code" or match any other criteria here.

I'm thinking that the compiled object cache is a prime candidate for breaking stuff when the project is moved/copied.

[Hooovahh]

I can't remember if I mentioned this, but I almost exclusively have the separate compile code on.

[billko]

I separate my compiled code as well, and I've never had an issue with any of my express VIs disappearing.  And while I don't move my projects around, I may, at any time check out a project from SVN and put it in an arbitrary folder.  I believe the cache treats this as a new set of objects to cache.

However, I've reverted projects so often that I'm amazed that the cache doesn't get totally screwed up.  It must have some method of knowing whether or not a particular file has changed.

[TurboPhil]

I just encountered this problem myself. Noticed that one of our automated CI builds failed with a useless error message (thanks, NI!), and when I went onto the box to investigate, there were several "broken" VIs due to "missing" instances of Elapsed Time.

These VIs are all under source control (Git), and the exact same revision opens on other machines with nothing missing.

And, like others have shown on this thread, I can search for Elapsed Time in quick drop on one of the "broken" VIs, and it is found and immediately resolves the "missing" instance, too.

Anybody have any luck resolving this? I'm afraid the solution might be to ditch express VIs entirely. I don't look forward to that find/replace across all of our repos...

😠

EDIT: it does look like the affected callers all had the "separate compiled code from source" flag set. And once I cleared the compiled object cache and reopened the lvproj, everything was unbroken. So we might just have to accept the fact that we'll have to clear the cache prior to every CI job, or go back to storing compiled code in the VIs themselves, since the cache appears to be untrustworthy.

[Hooovahh]

---

@TurboPhil wrote:

I'm afraid the solution might be to ditch express VIs entirely. I don't look forward to that find/replace across all of our repos...

😠

---

That's basically what I did.  I haven't seen this in 2020 yet but again I doubt I have any ExpressVIs left in that code base.

[paul_cardinale]

---

@Hooovahh wrote:

I can't remember if I mentioned this, but I almost exclusively have the separate compile code on.

---

We always keep that turned off.  I remember that having separated code was causing problems with my deployment utility (don't remember the particulars).  I've now setup my deployment utility to scan for separated code and if it finds VIs with separated code, opens a dialog box offering to fix them.