LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

Not-So-Infinite Reset of Death

7/3/2018

4 Comments

 
Ethan Stern
Picture
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 Stab

In 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 Stage

When 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 Around

This 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)
Picture
Which runs a pre-built LabVIEW EXE that calls a Windows batch file:​
Picture
You see this while reaper works:
Picture
...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
Ethan Stern link
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.

Here's what I actually did: I defeated the almost immediate FP.Close call in my root Actor (in this case, a View-Model). I confirmed that the stop sequence makes functional sense for my application and that everything is being stopped. I added a poor man's orderly shutdown to ViewModel (as in "wait a reeeeally long time with your FP open while everything else stops") and then I invoked top-level FP.Close. Alas, after a bunch of button pressing (view insertions), the app still hangs at shutdown with my old pal IRoD. It is interesting to me that the duration and complexity of the execution affect the likelihood of IRoD. The more dynamic view swapping that occurs, the more frequently IRoD shows up.

If you think I haven't done your suggestion justice, I'm all ears ;) I would love to reap the reaper.

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
Kevin link
7/14/2021 08:32:11 am

Very thoughtful bllog

Reply



Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    October 2019
    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources