Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in LV2017 re AF_Debug and Application Builder - Current State?

So there are several threads regarding a bug in either the Application Builder or AF_Debug VIs on both this subforum and the main LabVIEW forum.

I'm going to try and link to these threads and summarize what I've gathered from them, and hopefully someone can point out any problems with my conclusions, or suggest steps forward. 

 

Initially, it seems that reports concluded that Actor Framework.lvlib shipped with LabVIEW 2017 could not be built into a PPL (at all) due to the AF_Debug.lvlib library. The proposed solution was to copy the LabVIEW 2016/resource/AFDebug folder into the 2017 directory, and then problems disappear. Some links follow:

AF PPL Plugin (forum post)

Building AF PPL makes LabView 2017 crash (forum post)

Building PPL From Actor Framework Causes LabVIEW Crash (KB article)

In the second link, it's also pointed out by wrkcrw00 that LV2017 SP1 allows building of the Actor Framework PPL.

 

In this link, Building the Actor Framework to a lvlibp in LabVIEW 2017 crashes, Allen Smith (justACS) suggests the use of the 2016 AFDebug to avoid requiring an upgrade to 2017 SP1, posted in June 2018.

 

Seemingly the 2016 version hasn't produced problems for anyone that I can see, but it's unclear from these posts if the bug is actually in AF/AFDebug, or in the Application Builder, and it's just the case that AFDebug exposes this bug (that would seem to be what Allen writes in the solution here: AFDebug lvlib Generate Trace vi causing error in LabVIEW).

 

Particularly, that last thread is regarding building an application, not a PPL. The solution was given in March 2018, but the thread received a new post today, prompting this post. Although in that example it seems there are no serious breaks, just significant inconvenience, it appears similar to problems I'm currently having with AF PPLs on Windows and cRIO-9045 (see Building dependent PPLs on cRIO targets, Building dependent PPLs across multiple targets (Windows, cRIO) ).

A response by Mark Yedinak in the latter highlights the example project for building the Actor Framework PPL - I've tried using this as both the real project and as an example when creating my own version, but I suspect my problems occur later in the process (a library or two down the dependency chain), confirming that SP1 can build AF as a PPL successfully (at least, the AB finishes and produces a PPL).

 

Some questions:

  1. Could somebody (possibly from NI - I don't care who but I'm not sure about licencing restrictions here...) please upload a copy of LabVIEW 2016's AFDebug folder? I don't believe it's attached in any of the linked threads, and I don't have an installed copy.
  2. What's the deal with included files in a PPL from outside of the top-level library? In particular, how is the typedef for the Time-Delayed Send Message handled? It's not a member of the Actor Framework.lvlib, but it is used by AF_Debug.lvlib. This then links it into Actor Framework, via the Conditional Disable Structures, which are loaded by a project even if they won't be built into the PPL. I suspect this is a large part of my problem, and possibly the bug described above in general? At the very least, it makes building a library that includes Time-Delayed Send Message{, Core}.vi more tricky. Should I include the typedef in that library, or leave it outside in both cases?
  3. What is this bug? Is it fixed in either 2017 SP1 or 2018, or is it just that AFDebug is modified to no longer immediately (or at all?) trigger its appearance?
    • Note that the application building thread (titled regarding Generate Trace above) lists 2018 as also having a problem
    • I get very similar windows appear if I try and build libraries back and forth for Windows and cRIO. As I understand, lvlib files don't contain dependency paths, so in a new project when adding a library file, what loads is dependent only on the LabVIEW search process, possibly documented here: Modifying LabVIEW Default Search Paths for SubVIs) - PPLs do I think contain relative paths to their dependencies (but that's OK for me - mine are all side by side in the same directory). At the very least, they name PPLs on which they depend (open an lvlibp with dependencies in something like Notepad++).

 

My thanks to anyone who can provide help, guidance, or just conclusive answers on this topic.


GCentral
0 Kudos
Message 1 of 3
(3,447 Views)

Hi,

   After a day of headbashing over this issue my colleague and I have come to the following conclusion.

   The error which appears during build is a red herring.  It is annoying but doesn't stop the application from running.  Yes, switching to the 2016 version of AF Debug does make it go away. 

 

 The crucial thing is, when calling Launch Root Actor VI, leave the Show Front Panel input set to false (default).  Leave it to the Actor itself to show its front panel.

 

This is what we did and then then all the issues with Actor windows appearing and then crashing, went away....

 

0 Kudos
Message 2 of 3
(3,277 Views)

Since I found a solution which I think works for others as well, I want to share it here as well.

I did post in a different thread, so take a look there:

https://forums.ni.com/t5/Actor-Framework-Discussions/AFDebug-lvlib-Generate-Trace-vi-causing-error-i...

0 Kudos
Message 3 of 3
(2,294 Views)