Some questions/comments on AF Hands-On Exercise (Version 2, 21 Aug 2012)

[Bob_Schor]

I attended this Hands-On session at NI Week 2012, and got through most of it (with occasional assistance).  Thanks for posting the code and (corrected) manual -- I'm working through it several times as a "learning exercise" -- I'll be trying to "teach" (or better, demo) this with some of my students and colleagues.

I've run into a snag (bug?  user error?) in attempting to run the Cooler Test (this occurs at the very end of Part 1, which is about where we got to during the session at NI Week).  I've gone over my earlier code several times to be sure I didn't "miss something" in the earlier steps, but I think I'm OK so far.

I should start by saying that we haven't (yet) gotten our official set of disks from NI as part of our Academic License, so I'm working from a version of LabVIEW 2012 that I downloaded from NI when I returned from NI Week.  I'm running LabVIEW 12.0f1, with LabVIEW RealTime also installed, on a Windows 7 Pro 64-bit PC (I'm running, I hope, the 32-bit version of LabVIEW -- yes, that's what shows on About LabVIEW).

When I run Cooler Test (after opening Simulation Data_Global), the first thing I notice is that both Fan A and Fan B turn on!  This shouldn't happen -- only one fan should be on.  It occurred to me that when Dual Fan is launched, the state of the fans might not be specified, so I added a call to the Power Off VI for Dual Fan in the Cooler Actor Core before calling its Launch Actor method (similar to initializing the Water Level Deadband in this same VI).  This didn't change the behavior -- both fans still started "on".  Isn't this a logical (maybe even "correct") place to initialize the fans?  Isn't using the Power Off VI the proper way to do so?

But that's not the Real Issue.  When I notice this "unexpected behavior", I push the Stop button on the front panel of Cooler Test, and get the (depressingly-familiar) "We apologize for the inconvenience" message that says that LabVIEW has crashed and taken me back to the desktop.  I can even get this if I open a fresh copy of LabVIEW, open the AF Hands-On Exercise, and just start inspecting (i.e. opening and looking at) various VIs.  In this latter scenario, it's difficult to document what specific steps cause a crash, but suffice to say that it doesn't involve my explicitly running any VIs (though I might, for example, examine a Class heirarchy or use some similar utility within LabVIEW that could, behind the scenes, run code).  Usually, however, when the crash occurs, I'm simply "examining" code (possibly wiggling a VI to check connections, clicking here or there to move around between several windows, etc.).

In LabVIEW 2011, I experienced a similar series of "Crash-on-edit" behaviors associated with Network Streams.  I attended Nancy Hollenbeck's talk on Network Streams at NI Week, and asked if this had been found and fixed in LabVIEW 2012.  She said that it had, and that the bug was a problem in the LabVIEW editor (I think that's what she said -- it was only a brief mention).  Might there be a similar bug/problem with the rather-more-complex Actor Framework structure in LabVIEW?

I intend to persevere, as I find the Actor model, and LVOOP, convincing, having done my own modest share of multiple Queued State Machines, All Different (and difficult to extend, in some instances) and Mostly Not Playing Nicely with Each Other.  Having a more unified, more Interaction-Friendly Environment, is worth the effort and struggle!

Message was edited by AristosQueue to add a link to the Hands-On document on this site.

[justACS]

Hi Bob,

That is very odd behavior.  Can you zip up your code and send it to me?

[Bob_Schor]

I'm delighted to do so.  Here is my latest version (I've been working my way through the exercise, so some of the files are modified by me ...).  On my machine, opening the Project, loading the Simulation Global and running the Cooler Test shows both Fans coming on, and when I hit Stop (on the Test), I get the We Apologize message.

[komorbela]

I downloaded, tested and got the same odd behaviour.

I open the ...\Exercise\AF Hands-On Exercise.lvproj project, run the Cooler Test.vi in Test VIs virtual folder, and LabVIEW crashes as I press Stop.

I have LabVIEW version 12.0f1 (32 bit) on Win7 Professional 64 bit. I also have just the downloaded version of the LabVIEW 2012. The DVD just arrived. Is there a difference, should I install?

[Bob_Schor]

Hooray, I'm not crazy!  [Now, it is possible that I Did Something Stupid in the code, though I tried to follow the instructions in the Manual, but I can get a similar crash, not by running the program, but by simply "looking at it", that is, running LabVIEW, opening VIs, looking at heirarchies, examining Block Diagrams, stuff like that ...].

Bob Schor

[justACS]

Nope, not crazy.  I can replicate the behavior, too.  Now I'll try to figure out what's up...

[justACS · Accepted solution]

OK, it looks like something bad happened behind the scenes to one of your VIs.  The immediate solution is to force a recompile.  Open Cooler Test.vi, hold down CTRL + Shift, and click on the run arrow.  Then save all (this project) to save the recompiled VIs.  You should be good to go.

I'm talking with various parties in R&D about how to move forward with this, but in the mean time, that should get you going.

[Bob_Schor]

Wow, that was obscure!  Ctrl+Shift+Run, then Save All?  I presume this is Secret Behind-the-Scenes NI Stuff that we (ordinarily) should never need to know about nor use.

The Good News is that this did seem to "fix" Cooler Test, in that it now (a) runs, (b) stops without Apologizing, and (c) starts with both fans off.  There's still some funny logic that I don't understand (if both fans "Fault", they don't recover, and I'm a bit confused about the interaction of Water Valve, Pump, and Water Level, but that's probably "just code").

I'm definitely going to try again to start with the Exercise "fresh" from the Web and work it (again) carefully.  It will be "interesting" if this sequence again produces an Apologizing Cooler Test, but now, at least, I know how to Beat It into Submission.

Any clue what cause the Apologizing crashes?  Are there steps we can take to (a) "fix" things (Ctrl+Shift+Run on all VI?  Mass Compile option?) and (b) get the information to NI in a more timely manner than simply clicking "Send Report"?  [I ask because I've now found several of these crashes, including one in Network Streams that did get fixed, I'm told (but I haven't tested my "Break It" code), but it wasn't fixed until the final release, still being present in the 2012 Beta though the bug was reported to NI, and "escalated" as best I could, very early in 2012)].

Onward!

Bob Schor

[komorbela]

Hi BobSchor,

I just looked it up and found CTRL + SHIFT + RUN to be a published functionality of LabVIEW. I don't know how long ago did this become public, but it was also in the 8.6 version's help. this is the latest version: Preparing VIs for Build Specifications.

[AristosQueue (NI)]

Ctrl+shift+run is the equivalent of forcing a mass compile on all VIs in memory. Since VIs are compiled as they load into memory (if needed), the only use to customers is working around a screw up in R&D, like this one. User niACS has passed along this bug report to the compiler team.