![]() I have been working on some pretty large applications lately that have highly dynamic behavior. Actors are getting launched and closed, views are frequently popping into subpanels--that kind of thing. At some point pretty far into my development, I started getting this dialog when my executable (EXE) shut down. It seemed harmless enough, until I realized it was not going away...ever. I did the usual web snooping and stumbled on this LAVA post. Infinite Reset of Death sounds about right (IRoD, as I now call it). First StabIn my first act of attempted remediation, I somewhat arbitrarily added explicit (actually redundant) shutdown to my framework. I don't like the idea of adding code just to see what happens, but I thought that I might avoid the problem by enforcing a more orderly shutdown process. Nope. 2nd StageWhen that failed, I tried mass compiling and rebuilding. I pretty quickly learned something about a river in Egypt and that this problem is also intermittent. It tended to happen sometimes rarely...then constantly (and, of course, most often on the customer's embedded PC). Done Messing AroundThis problem is a strange type of nuisance. When it occurs, I've already done everything I can reasonably do to shut down my application. To be clear, this is not a case of an Actor left silently running. Everything is stopped--I'm sure of it--and LabVIEW is fighting with itself to release resources. I spent a while pondering the safety implications and general dirtiness of the following solution. It was the best I could muster--and I think it is absolutely harmless, since all my code is completely done executing (hardware set to safe states, data saved, and resources obtained by LabVIEW closed). Meet Reaper: https://bitbucket.org/account/user/composedsystems/projects/REAP The idea is super simple--kill the specified task through Windows command prompt. (Only works on Windows, of course.) Call Collect Application.vi when you are ready to reap. You will, of course, want to call this after all of your code is done running. (The same place you might have called the Quit LabVIEW function) Which runs a pre-built LabVIEW EXE that calls a Windows batch file: You see this while reaper works: ...And that's the end of your application. No doubt about it. If you go this route, you'll need to build a reaper in whichever version of LabVIEW run-time you are deploying. You must also include the EXE and its batch file in your buildspec but, if you read this far and understood what I was talking about, you probably already knew that. Happy reaping! Ethan Stern is a Managing Partner at Composed Systems and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, NI Certified Professional Instructor, and SOLID software enthusiast.
4 Comments
Robert Smith
7/4/2018 07:33:41 am
Hey Ethan, nice article! I've run into this problem before too, and it's incredibly frustrating. I found that forcing the main VI's front panel to stay open long enough for labview to clean up all of the actors did the trick. I just pop up a splash screen similar to the one in your article and wait 5 seconds before closing the main VI front panel.
Reply
7/5/2018 10:59:50 am
Hi Robert! Very interesting and thanks for the tip. I tried your suggestion immediately (and with great enthusiasm). Unfortunately, it did not solve my problem.
Reply
helcio burd
7/11/2018 10:58:24 am
I have the same problem in large applications. I thought that it was due to active objects not closing properly (within GOOP) and made sure that all the references were properly closed during shutdown, but that never solved the problem and I continued to get the RESETTING.VI message (once in a while) during shutdown of the application. This is so incredibly frustrating; good to know that there is a way to deal with that!
Reply
Leave a Reply. |
Tags
All
Archives
October 2019
LabVIEW Blogs |