Finding Errors in AF VIs (easily)

[ChristophHS]

Hi,

when usind actors I occasionally break an actor or message related VI.

How can I easily identify such a broken VI? It's sometimes rather tedious to go through the VIs and find the one that's broken.

Found this question, - correct me if I'm wrong - MonitoredActor is rather useful for debugging but not for simple broken VIs.

https://forums.ni.com/t5/Actor-Framework-Discussions/How-can-I-quickly-find-my-vi-s-fault-in-AF/m-p/...

Regards

Christoph

[cbutcher · Accepted solution]

Does opening the Error List not tell you?

Typically a vast number of VIs become broken, but only a few (or perhaps one in your case) are themselves with an error.

They appear at the very top with red X marks, unlike the rest that just show no mark.

Some old code I broke as a demonstration

[ChristophHS]

I feel dumb now ...

I'm so used to the error list popping up by itself (or displaying the broken run arrow), I forgot to open it manually.

Not sure, but I recall having problems / not finding the correct broken VIs. But maybe thats not correct ...

Anyway thanks for the reply

[OneOfTheDans]

I've definitely found limitations of the Error List. Some that come to mind first thing Monday morning:

• It only shows errors for VIs that are loaded in memory.
  This means the Error List won't necessarily show you all the errors within your .lvproj. It's especially an issue if you dynamically load VIs. I get around this by making a temporary "HELPER.vi", then dragging all my dynamically loaded VIs into the block diagram, then looking at the Error List.
• It's difficult to open if your run arrow isn't broken.
  The way I use to get there is by right-clicking a .lvclass or .lvlib in your project explorer. Maybe there's an easier way? I haven't found it though.
• Sometimes it's just wrong.
  I've had that Error List tell me VIs were broken... when I open the VI, there's nothing wrong with it (and no changed dependency locations). I have a hunch it's related to dependent polymorphic VIs changing. Perhaps Mass Compile would help in this case...
• You can't use it while building applications.
  I've found applications that use AF to be really finicky if you're trying to build executables. The Application Builder can easily remove the wrong files/dependencies, and break the build. Then it fails with a generic error and you get stuck trying to trace back the error manually. If the error window could show the traceback of broken VIs and the root cause, this would go so much faster.

[cbutcher]

---

@OneOfTheDans wrote:

I've definitely found limitations of the Error List. Some that come to mind first thing Monday morning:

• It's difficult to open if your run arrow isn't broken.
  The way I use to get there is by right-clicking a .lvclass or .lvlib in your project explorer. Maybe there's an easier way? I haven't found it though.

---

Ctrl+L 🙂

---

@OneOfTheDans wrote:

I've definitely found limitations of the Error List. Some that come to mind first thing Monday morning:

• You can't use it while building applications.
  I've found applications that use AF to be really finicky if you're trying to build executables. The Application Builder can easily remove the wrong files/dependencies, and break the build. Then it fails with a generic error and you get stuck trying to trace back the error manually. If the error window could show the traceback of broken VIs and the root cause, this would go so much faster.

---

The build-time issues can be annoying... Sorry, I haven't really got a good suggestion there. Especially because sometimes it looks OK... 😞 I think mostly my issues related to the AD_Debug library and PPL versions (I just removed AF_Debug from my libraries).

[BertMcMahan]

[Taggart]

---

@cbutcher wrote:

---

@OneOfTheDans wrote:

I've definitely found limitations of the Error List. Some that come to mind first thing Monday morning:

• It's difficult to open if your run arrow isn't broken.
  The way I use to get there is by right-clicking a .lvclass or .lvlib in your project explorer. Maybe there's an easier way? I haven't found it though.

---

Ctrl+L 🙂

---

@OneOfTheDans wrote:

I've definitely found limitations of the Error List. Some that come to mind first thing Monday morning:

• You can't use it while building applications.
  I've found applications that use AF to be really finicky if you're trying to build executables. The Application Builder can easily remove the wrong files/dependencies, and break the build. Then it fails with a generic error and you get stuck trying to trace back the error manually. If the error window could show the traceback of broken VIs and the root cause, this would go so much faster.

---

The build-time issues can be annoying... Sorry, I haven't really got a good suggestion there. Especially because sometimes it looks OK... 😞 I think mostly my issues related to the AD_Debug library and PPL versions (I just removed AF_Debug from my libraries).

---

I had really long build times once because I had circular dependencies. I had tyepdef or two that were part of a class and were used elsewhere. Steve pointed that out to me. Removing the typdef from the library solved it. It might be worth checking for circular depenedencies.  I want to say McBee has a tool for that somewhere on the forums.

[AristosQueue (NI)]

> How can I easily identify such a broken VI?

Sign up for http://ni.com/beta

When the LV 2020 beta is posted in the next few days, there's a small-but-useful new feature that I think will help with the debugging problem. This is like the smallest thing changed in 2020, but I added it for myself, and I've had several people tell me it's a big deal: in the error list window, we've always told you the *nearest* dependency that is breaking a given VI/class. Now the error list window also shows the *root* dependency that is breaking a given VI/class.

[ChristophHS]

---

@AristosQueue (NI) wrote:

Sign up for http://ni.com/beta

When the LV 2020 beta is posted in the next few days, there's a small-but-useful new feature that I think will help with the debugging problem. This is like the smallest thing changed in 2020, but I added it for myself, and I've had several people tell me it's a big deal: in the error list window, we've always told you the *nearest* dependency that is breaking a given VI/class. Now the error list window also shows the *root* dependency that is breaking a given VI/class.

---

That sounds like a nice feature.

But to be honest, I won't start using beta versions. We're having multiple PCs, applications and projects. Upgrading to a new LV is no fun... especially when suddenly things won't work anymore. (E.g. after upgrading to Win10 and LV18 my FPGA Project kept killing the pc (bluesceen) - Don't know and don't care what's the reason, neither me nor support could do anything about it - that's stuff that happens).

Anyway, It appears that I'm not the only one having issues with broken VIs. I was also sure I had broken VIs which where not in the Error-Lists. But I could not reproduce this when creating this question, so not sure about that.

[AristosQueue (NI)]

---

@ChristophHS wrote:
But to be honest, I won't start using beta versions.

---

Oh, I agree, you definitely shouldn't use a beta for anything real. But checking it out in a virtual machine (so you can wipe it out of existence entirely later) helps us make sure we aren't breaking your stuff with the new release.