drjdpowell

Labview does not allow to open a shared reentrant VI with a call by reference

You can work around that.   Have your classes use static preallocate-clone methods, and have a dynamic method that returns a prepared reference to one of these static clones.  You store that reference in your object on creation.  Then use a single call-by-reference in your loop, and all preallocate-clone NI subVIs should work correctly.

— James

BTW, I didn’t comment on the Cancelation-token functionality.  I don’t have that, because once I have to send something a message, even if that message is just “cancelâ€, I consider making the something an actor, which can be extended to new messages as needed.   My “actions†are to be as simple as possible.   They always poll their equivalent of the “results reporterâ€, and abort if that object dies, since they then have no reason to continue (their job being to send results).  This feature means you don’t have the “cancel†them in order to shut down the application.  

So I suggest you think about either building the cancelation token up into something more message-like, or eliminating it for simplicity.

Added Later>> Check out the “CancelableObserver†class in Messenger Library.  This allows one to make a cancelable “forwarding address†out of any other standard address.  You could do this for your “Results Reporterâ€.   Then your Actions can just poll the validity of their Results Reporter instead of a Cancelation token.  Note that it is guaranteed that no message can be sent after you call “cancel†on the communication method, in contrast to calling cancel on a token, where the running Action may have just checked the token and be about to send the results.  The latter behavior can lead to race conditions.

Not a huge deal, but just makes me feel more comfortable using it. 

Well, clone pools are a “high water mark†type thing; you will never have more than the maximum number that you had running at any one time.  I’ve done testing with my Async Actions and Actors, and running a few thousand is no issue.  Note that any shared-renetrant subVIs called by your top-level “function†won’t be cleaned up when you release the pool, so I’m not sure if you can reliably recover from a “do a million things at once†bug.  Whatever you do, you need to have a simple high-level API for the new User, with a minimum of different new wire types and “Create so-and-so†calls, even if you have a more complex low-level API semi-hidden in an “Advanced†palette.

Some comments after having a look at the code:

1) Is there value in the Execution System stuff?  I’ve never discovered much reason to mess with Execution Systems.  It would be simpler (and possibly less overall overhead) to have a single clone pool for all Async stuff, created on first use as in the Actor Framework or "Messenger Libraryâ€.

2) Consider combining the “Action†and “Function†classes (and thus making Actions children of “Taskâ€).  This reduces the number of wire types and would make Tasks fully recursive (so a Batch can contain other Batches).

3) Do you really need the Variant Parameter stuff in “Actionâ€, given that children of Action can just add whatever parameters they want in private data?

— James

You are crediting a few dozen people when really it should be one guy.  

“Creditâ€?   What has this to do with credit?  This is legalese meant to disclaim liability.  Plus copyright, but I’m unsure of the value of copyright on something you’ve licensed without restriction.   Perhaps we could drop the requirement to reproduce the copyright, and just retain the disclaimer (see below):

Copyright © 1995-2004 Mark Adler, Jean-loup Gailly; 1998-2004 Gilles Vollant; 2002-2006 Jean-Pierre Drolet, Heiko Fettig; 2002-2007 Cal-Bay Systems, Inc.; 2002-2009 Christophe Salzmann; 2002-2010 Jim Kring; 2003 Paul F. Sullivan; 2003-2008 Rolf Kalbermatter; 2004 Enrique Vargas, Michael C. Ashe; 2006 JKI; 2006-2007 MKS Instruments Inc.; 2008 T. Plomp; 2010-2012 Jonathon Green; 2012 James David Powell

All rights reserved.

 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following disclaimer is retained, in code, documentation, and/or other materials provided with a distribution.

 

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 

Have a look at the “Async Action.lvlib:Action.lvclass†in my "Messenger Library†on the Tools Network, as well as child classes such as “Time Delayed Messageâ€, “Async File Dialogâ€, or “Address Watchdogâ€.  This is my OO implementation of what your describing, where child classes override “Execute.viâ€, and optionally “Setup.vi†(run before Async Call). 

However, though I have 10 asynchronous actions built into “Messenger Libraryâ€, and can create new ones easily, I don’t generally make application-specific ones.  Instead, I use either an on-diagram “helper†loop, or have an independent subactor.  The pattern could be described as a “Manager†(a event- and message-handling loop with state data) and a number of “Workers†(specialized “helper†loops or subactors).  

Asynchronous actions are still very worthwhile pursuing, though, as things like a delayed enqueue or an asynchronous dialog box are very valuable.

—James

BTW> The “Producer-Consumer†QMH templates produced by NI are to be avoided, for all sorts of reasons.  I just did a talk on this for the CSLUG user group on Monday; there is a recording of it in their Google+ account (I mentioned the issue of state-sharing between the loops, but my primary criticism was the horrifying potential for race conditions).

I think the takeaway is that people would like a single licence that covers all the VIs in the OpenG that they can then reference in their documentation. 

The OpenG Toolkit VIPM package has this license:

 

 

OpenG Toolkit

Copyright © 1995-2004 Mark Adler, Jean-loup Gailly; 1998-2004 Gilles Vollant; 2002-2006 Jean-Pierre Drolet, Heiko Fettig; 2002-2007 Cal-Bay Systems, Inc.; 2002-2009 Christophe Salzmann; 2002-2010 Jim Kring; 2003 Paul F. Sullivan; 2003-2008 Rolf Kalbermatter; 2004 Enrique Vargas, Michael C. Ashe; 2006 JKI; 2006-2007 MKS Instruments Inc.; 2008 T. Plomp; 2010-2011 Jonathon Green

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

 

  * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

 

  * Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

It needs updating (it's missing "2012 James David Powell" ), but it covers the entire toolkit.  Stick that in a TXT file in your installer and your done.

For example, ever modified a VI.lib VI and used it in a commercial work?   Did you read and follow the "NI Release License Agreement" all the way to "Attachment A — Source Code Licenseâ€?  Commercial licenses aren’t a bureaucratic burden only to the extent you ignore them.  Perhaps the BSD license used by OpenG is too short and readable.  We need it to be long and unintelligible.

An earlier (rather long) discussion about licensing.

There's something to be said for just being able to throw money at the problem to get your own commercial license and not have to deal with open source requirements. A few hundred to a few thousand dollars may well be worth my time even if you also distribute via open source licenses. And here's a hint: when I say "worth my time", I'm not weighing against the time it would take for me to implement your library myself. I'm considering bureaucratic burden.

Are you sure you understand your commercial licenses?   The big difference about the BSD license from most licenses is that a human can actually quickly understand it.  Ever read the licenses you agreed to in using LabVIEW?

Anybody know any lawyers?  As a copyright holder of some BSD-liscenced packages (and one or two OpenG VIs) I couldn’t care less if you include me of my license in your binaries.  But I am interested in not being sued.   And not being a lawyer I can only use an established license in order to feel some confidence that I am protected.  From a common-sense point of view, it seem silly to think that one could be liable to a third party because a second party passed on your software in their product without passing on your legal disclaimer.  But I’m not a lawyer, and all licenses seem to have that.

Any sort of inter-module communication will have certain messages that you want to get across regardless of the error.

I have a “Reply†method that always sends a message, since someone else is presumably waiting for it.  The reply is an error message if there is an error in, rather than the usual reply message.

The usual pattern that I (and others, i think) have used is analogous to a file directory: directories contain a mix of different files and also subdirectories (which can contain sub subdirectories, etc., etc.).   The classes are a Parent, with children File and Directory, the later containing an array of Parent.  File can have subclasses for different file types, and there can also be different subclasses of Directory.  It’s a recursive tree-like structure

But your hierarchy of different levels is not the same as a tree-like structure.  Steps can only contain an array of Functions, and so on.  You would have a common parent (which defines your “Execute†or “Do†main method) but you need each subclass to contain an array of a specific other subclass.  So Step contains an array of Functions.

But, are you sure you need a specific hierarchy like this?   Seems more work and unnecessarily rigid.   Why can’t the User call a Function inside another Function?  If a User wants to execute an Action as part of a Group, why require the extra work of creating a Step with one Action?

It has made me rethink how I think about static events. The lifespan of static event registration is fundamentally inconsistent with how I've been treating event context in my dialog VIs. I may very well adopt practice of using only dynamic event registration just so I can be in absolute control over the lifetime of the registration.

The new Flush Events primitive may also work for dialogs.

However never in my years of experience had I ever seen any example where changes that happen while my diagram is not executing could generate events to be consumed during execution.

I’ve used this behavior with Event Structures inside Custom Probes, where events can be generated even though the probe is only actually executing periodically.  XControls work similarly, I think.

The workflow/setup is:

— User has my EXE and takes calibration data with it (no LabVIEW Dev environment installed)

— imports data into “Eigenvector Solo†3rd-party App to do advanced calibration

— â€œEigenvector Solo†outputs a .m file

— my EXE imports and runs .m file on new data.

It’s the last step that I think can’t be done, because the EXE can’t dynamically load and compile a .m file.

I have a request to make an EXE be able to dynamically call a .m file with Mathscript.   The .m file is User supplied and not knowable at build time.   But my understanding is that the EXE compiles in the Mathscript, so this cannot work, and that other dynamic mathscript options (such as “evalâ€) do not work in an EXE.  Has anyone encountered this issue before? 

And the point about the static method is correct, but I don't have the option of modifying the grandparent class as it is a key part of the system architecture.

Not sure I understand.  You wouldn’t be changing any functionality; your DD methods for grandparent and parent would behave as before, but you would have the ability to call the static method directly from the child.

As ak_nz says, the “to more…†methods don’t change the objects.  What you need to do is move the grandparent functionality into a separate static method, and call that method from all three DD methods (grandparent, parent and child).   That way, the child can replace the parent functionality while still calling the grandparent code.

It thought I was 13 years older than I was when the photo was taken,

Ha!!  Only thought I was 11 years older.  

What’s the point of anti-virus software that a virus can get around by renaming itself “labview.exe�

I’m afraid I only bang away at things till they work.  I believe I found it worked much better with the text as opaque (and in the opaque bin) inside a transparent object (in transparent bin).

Thank you all for your feedback. I believe using strings require one thing at least: being diligent when naming the states correctly at their creation, since renaming them would require modifying several string constants --> bigger effort and error prone.

Or you could just use Find/Replace...

I used the JKI template for almost every project for about 5 years, till about a year ago when I replaced it with a new design that is very heavily influenced by it.  The new design retains the strings.

Try renaming the class (this deletes the class mutation history, which might be causing your problem).

They use Text-Variant messages rather than Command Pattern, but the OP could also consider looking at:

— mje’s Message Pump, which uses “Actorâ€-like objects that can be inherited from to add functionality.

— my Messenger Library, which includes a Sample Project that redoes the NI “Continuous Measurement and Logging†example.  It uses OOP extensively in the Message-passing objects, though the “Actors†are actually just single VIs.   Don’t know if this counts as an “object-based frameworkâ€, as one isn’t required to do much OOP in actually using it.

I suspect there might be a concern that making “public†data members easier would discourage more careful design.  There are reasons why heavy use of “properties†might be thought of as a “code smellâ€.  Of course, a significant fraction of the time one really does just need a direct read/write access to a data member, and a “public†declaration would certainly be convenient.