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

[thutch79]

Good question. I'll ask the developer. It is open sourced, but I feel funny posting it without his permission first.

[BertMcMahan]

---

@thutch79 wrote:

I mean, yes, that’s how actor framework works, but I don’t think that’s root cause here. Like I said, the program has been built many times before and the new additions aren’t actors or anything called dynamically. If I didn’t already mentioned it, I did a round where I literally put everything in the “always include” section and it still failed. The VIMs are definitely broken so they’re at least part of the issue. This is the first I’m building malleable VIs into anything so that’s probably where I’m falling down. 

---

I meant do the VIMs call anything dynamically, not the AF stuff. I don't know what the library you're using does.

Can you make a simple VIM that just does some addition or something and see if that works? That way you'd figure out if it's these specific VIM's or VIM's in general.

If you can't post the library, can you summarize what it does? Maybe we can theorize on it a bit.

[thutch79]

Oh, gotcha. No, these are pretty simple. It's just an enhanced configuration file interface. The more I look, it doesn't look like it's the VIM. I haven't heard back from the developer on posting the code, but a screen shot is pretty benign, so here is one. The broken VI is malleable, but the one at the center is also malleable and it is not broken. I thought maybe it had something to do with the DVR usage, but there is an "open" and "close" method that goes with it and those are all not broken. They have DVR functions right in them.

[BertMcMahan]

Could it have anything to do with reading files? File paths on RT systems can be a little different than desktop systems sometimes (IIRC).

[thutch79]

No, I don't think so. The code is broken before it ever runs so the path never gets a chance to muck things up. Plus, I've been using the same file paths both in a previous, functioning executable and the dev code.

I just had a successful build by rolling back to the old config file interface library. That was definitely the source the of the issue. Unfortunately, I'm not in a position to troubleshoot in much further. Need to move on. If I get permission from the developer to post it, I'll post the source code for people to pick at if they're interested.

[EthanStern]

Hi All,

I figured I'd weigh in here, for the benefit of anyone who might be interested in this issue. I wrote the open-source library thutch79 is talking about. If anyone is interested, they can get it from the bitbucket repo (https://bitbucket.org/composedsystems/composed-configuration/src) or pull the latest release from G Package Manager (https://gpackage.io). Thank you, thutch79 for not posting it, as I would cringe a little at the idea of a static version of the library publicly hosted here for all time.

Malleable VIs (VIMs) are an awesome addition to LabVIEW and we continue to use them despite seeing issues in the IDE. We expect these issues to be fixed in future LV releases and have, thus far, judged the benefits to outweigh the nuisances.

Let's straighten one thing out in advance--VIMs are not dynamic. They provide an edit-time polymorphism and that's it. What is statically placed at edit-time is the instance that gets built and is the instance that runs. There's no mystical malleable dynamic behavior to blame. If the wires are not broken the code should build and run as placed.

All of the malleability of composed-configuration (the suspect library) is around data type conversion. It's not doing anything fancy. You wire a type and that's the type that a configuration datum gets cast to upon read. If the type read from a configuration sink (e.g. an INI file) is not compatible, you'll get a run-time error. That's all the library does.

One thing we have seen several times is that VIMs--or possibly their callers (who more actually "own" the inlined malleable code)--cling to old (and clearly bad) dependencies. Mass compile has not resolved this issue for us (in fact, mass compile has done some pretty unhelpful things, which is why we generally don't use it). Control-clicking the run arrow does not fix the issue. Removing the malleable instance from a diagram and replacing it seems to nudge the crusty old links out of LV memory. (Remember I mentioned nuisances?) This issue is especially common (for me) in unit tests (we use VI Tester).

We have not built any VIMs for RT targets but I see no reason why there should be any trouble here. If anyone knows differently, I would love to know about it (suspecting with the utmost conviction that it is a bug and not a real limit of the capability of VIMs).

I have seen other IDE issues recently while migrating to libraries containing VIMs but I don't know for sure if malleability has anything to do with the problem. The most costly issue to date was one where the IDE was silently stripping LVLIB namespaces off of dependencies when it loaded them from a new location. I could build the code into an EXE and run it, but only on some targets. We tried a number of systems and virtual machines and could not tie the broken EXE behavior to a particular OS version, driver set, or IDE install. After I noticed this weird namespace stripping, I reverted everything and followed a different workflow to relink the code with the same exact result. It was ugly. I eventually relinked and modified everything manually, editing and resaving all of the libraries up the dependency tree. We are done with these major relinks for now so I apologized to our customer and just kept moving forward.

Writing this was somewhat cathartic, though I'm not sure it will directly help the guy in trouble. Let's chat.

Ethan

[thutch79]

Thank you Ethan for chiming in.

Ok. I just wanted to close out this thread with my conclusions. I'll try to walk through the mess until where I am today. I don't think I dug to the absolute root cause, but I was able to build successfully, albeit not in the manner that I should be able to. Ethan and I did a screen share so he could see what was going on. I showed him a very basic VI using his "configuration" library (robust ini file reader/writer). It was failing to build, so we thought we had the issue cornered. This was in a fresh project with no other code to complicate things. So, I took the entire folder with both the simple VI and the library code, and zipped it. Ethan looked at it on his side and it built and ran just fine. I moved it to other dev environment computers in our office and found two to exhibit the issue and one that it built successfully.

So, now it seemed to be a dev environment issue, or Labview install issue. As a quick experiment, I put LV 2018 on one of the problem machines and the problem went away. Great, I thought! Yes, it's painful to move versions with such a large code base, but I've done it plenty in the past, so off I went installing. I had secretly wanted a good reason to move to 2018 anyway. I got everything up to speed in 2018. I did a full mass compile of all my source code including the libraries. I tried to build..... and failure.

Now, my RT only uses this config library and no other libraries that contain malleability. So, I stripped it out in favor of an old (non-malleable) version. The RT code now builds just fine. I'm moving on there. The new version of the library isn't important enough to deal with any issues. However, on my host side (64 bit LV, if it matters to anyone), I use many of these libraries, none of which I could reasonable strip out. So, I need to deal with the problem. I turned on remote debugging to I could take a look under the hood and see what's broken. Here's the really weird (and frustrating) part. Every single class and subVI called from my startup VI (directly, not dynamically) was missing. Note, this is not just library calls. This was calls to all the code in our system. There is absolutely no reason that could be, that I know of. I tried a number of the typical things to get it to correct. I cleared the compiled object cache, mass compiled, ctrl-shift-click the run arrow, new build spec, etc. Nothing made any difference. Finally, I put the project folder containing all the libraries in the "always include" section of the build spec. Suddenly, the build worked fine. It was finally finding all the code, not just the code in the library folder.

I would love to keep digging to find a root cause, but my development schedule has already taken a week long hit over this, so I need to move on. If anyone has any quick suggestions, I'd be happy to dig a bit more as time allows. One last thing I will try when time allows is taking the folder back out of the "always include" to see if that just shook something loose and now it will work OK. I doubt it, but worth a try next time I build. For now, here's what I feel I can conclude:

1. This had nothing to do with RT. That was just the first code I tried to compile with this issue.

2. Malleable VIs in and of themselves aren't necessarily the problem (i.e. they can be built), but there's still a good chance something about malleable VIs is screwing with the IDE when it comes to building executables in certain instances.

Thanks to everyone that has chimed in with suggestions.

[Intaris]

I'm currently working with VIMs in LV 2015 (where they aren't officially supported) so maybe things have changed since.

In my code, whenver a vim is placed, it drops a copy of the VI contents locally. This is NOT linked back to the source under normal circumstances. IF, however, at a later stage, I access the VI contents (via INI switches the options become available in the right.click menu) THEN it will update to the current version saved on disk.

So while the VIM knows where it comes from, it doesn't seem to try to keep itself up to date with changes to the "origin" vim on disk. This can lead to a crazy mix and match of vim versions in code.  Maybe it's possible to re-link all of them in oen fell swoop in later versions of LV, in 2015 I need to right click each and every one of them and replace them with themselves to get them to update.

Note: AFAIK, this is planned functionality, and NOT a bug.

[thutch79]

Well, that seems like a really bad design decision if that's the case. So you could have different versions of the same sub VI running around your code?

[Intaris]

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.