Jump to content
Jon Kokott

[CR] Daemon Creation Tool

Recommended Posts

index.php?app=downloads&module=display&section=screenshot&id=166

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

Share this post


Link to post
Share on other sites

[bug]

You cannot use a multipane source VI.

Fix: remove the subVI which replicates the frontpanel of the source VI.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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...)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.