Jump to content

[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

Link to comment
  • 1 month later...
  • 2 months later...

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.

Link to comment

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
Link to comment

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

Link to comment

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.

Link to comment
  • 1 month later...

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.