Jon Kokott Posted February 25, 2011 Report Share Posted February 25, 2011 Name: Daemon Creation Tool Submitter: Jon Kokott Submitted: 23 Feb 2011 File Updated: 28 Feb 2011 Category: VI Scripting LabVIEW Version: 8.6 License Type: BSD (Most common) This Labview scripting tool takes a standard VI, and creates a wrapper around it to launch it as a daemon. This is useful for creating inline code modules that need a process to run in the background.Accessible through the tools menu option. Features: Daemons will abort when the top level VI is aborted. Daemon can be aborted by closing the "Daemon Owner" VI refnum. Daemons obey source VI properties such as open front panel when called. Host process can be reentrant or standard. Tool places created daemon in idential project location. Tool will not alter the source VI in any way. To install this toolkit unzip and run the setup.vi file. The setup.vi as well as uninstall.vi will run immediately upon opening, so if you wish to inspect the files open the .lvproj file in the /source directory. It will install the toolkit to whatever version of labview runs the setup.vi file. uninstall.vi will uninstall the package. The package has been saved in LabVIEW 8.6, and fully tested in 8.6 & 2010. ________________________ Created By: Jonathan Kokott jmkokott@gmail.com Click here to download this file Quote Link to comment
Jon Kokott Posted February 25, 2011 Author Report Share Posted February 25, 2011 [bug] You cannot use a multipane source VI. Fix: remove the subVI which replicates the frontpanel of the source VI. Quote Link to comment
Mark Balla Posted March 1, 2011 Report Share Posted March 1, 2011 Approved 2-28-2011 Placed in Scripting Category. Quote Link to comment
Jon Kokott Posted April 5, 2011 Author Report Share Posted April 5, 2011 [bug]Source VIs contained in Libraries within libraries will error out. [temp fix] Move the library owning the source VI out of any other libraries and run the tool again. Quote Link to comment
Jon Kokott Posted June 20, 2011 Author Report Share Posted June 20, 2011 I noticed something interesting today. If the daemon completes its run (the calling VI finishes execution), and has created any references (like queues, notifiers, etc.) it destroys them upon completion. I've tried to see if this was because it wasn't in opened using identical application references, but it does not seem to change the behavior. This means if you need any shared application memory you must open all references outside of the daemon source VI, or be ready to release them before the daemon completes. I'm not really sure why a queue reference is owned by the daemon alone, and cannot exist after the VI is closed. I'll think about adding an auto close VI daemon reference option to make the daemon wait indefinitely until the reference is manually closed. Quote Link to comment
Yair Posted June 21, 2011 Report Share Posted June 21, 2011 In general, references are automatically destroyed when their hierarchy goes idle or out of memory. The hierarchy is determined by the top-level VI, which in your case would be the daemon. One way of working around this for queues and notifiers is to obtain the references by name. Then, the reference which was created in the daemon will be destroyed, but if the queue still has other references, it will not be destroyed. 1 Quote Link to comment
Jon Kokott Posted June 21, 2011 Author Report Share Posted June 21, 2011 In general, references are automatically destroyed when their hierarchy goes idle or out of memory. The hierarchy is determined by the top-level VI, which in your case would be the daemon. One way of working around this for queues and notifiers is to obtain the references by name. Then, the reference which was created in the daemon will be destroyed, but if the queue still has other references, it will not be destroyed. Correct me if I am wrong, but memory allocations for queues do not appear in a given VIs memory when using VI profiler. I assumed from this that queues would be "owned" (in terms of memory) by the active application. It seems counter intuitive that a VI hierarchy owns memory allocations and not the owning applications if this is the way labview displays memory allocations. I might be venting a little be here as I would be given the ability to define the application/"VI Hierarchy" owning a given chunk of memory than have labview decide for me. I suppose I can always go back to C (joking...) Quote Link to comment
Yair Posted June 22, 2011 Report Share Posted June 22, 2011 I'm not sure how the memory profiler presents the data, as I only use it rarely. In any case, I would agree that it would be nice if this was changed so that a reference would only be destroyed after all the hierarchies which use it stop executing. I know that NI is aware of this desire and maybe one day they will change LV to work like this, but that's not the way LV behaves today. Quote Link to comment
Jon Kokott Posted July 31, 2011 Author Report Share Posted July 31, 2011 It appears LV 2011 now has an asynchronous call by reference node feature. I'll try it out sometime but I'm sure it will be vastly superior to this implementation. ~Jon Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.