drjdpowell

Right now for me is June 19 at 13:19. If someone asked me what day it is, they wouldn’t expect me to round up to "June 20thâ€.

Yes, I just threw this together as an example. It would need some work to be a robust reusable component, though it does properly shut itself down and close all references as used in the example. The actual code that this example is modeled on is a component called “Metronome" built into Messenger Library**. The point, though, is that one can build such a reusable, easy-to-use component, and use it simplify use of the JKI template. ** See the Messenger Library example "Example of Recurring Event Methodsâ€. It shows both this “trigger†method and an alternative “delayed message to self†method. This is the template I now use, BTW, which will be in the next version of Messenger Library: It uses JKI-like strings, but as a “follow-on action†stack, where there is no ability to call “idleâ€.

I’ve used DAQmx Events multiple times. Also IMAQdx “Frame Done†Events. I wouldn’t worry about the Event Loop overhead.

Beta modifications: Uses Open_v2 to allow Read Only, and search for libsqlite3.so on RT. Please test. drjdpowell_lib_sqlite_labview-1.5.1.42.vip

I’ll look into using sqlite3_open_v2(). I had "sqlite3.*†as one of the search paths, so that must have failed for some reason.

Can you try just using the string “libsqlite3.so†or “libsqlite3.*� /usr/lib may be the default library path, and then I can cover the case where the library default path is another location.

What’s the Target_Type conditional disable symbol on the cRIO?

Questions: — does it work on Windows? — Do the examples work on the cRIO? — Can you attach a sample db so I can inspect it?

Putting “?†is the string “?â€, not a parameter, so when you tried to bind a parameter it was an error. Not sure why your code isn’t working, but try eliminating the SELECT and changing the INSERT to “INSERT OR IGNOREâ€, as that should accomplish the same thing (and be faster too).

With the JKI one has a single stack-like, last-in-first-out, method but TWO queue-like, first-in-first-out, methods: States on back, and an Event queue. The former has priority over the latter, but one can mess with that by adding “idle†states at various places. Having two very different methods of doing the same thing is complicating without creating meaningful additional capability. Reducing things a single event queue, with a subVI-like stack handling of each event is actually much simpler. The easiest way to do this is just the replace “States on back†with a User Event message to oneself, but with a little sophistication one can create reusable subVIs that either do a delayed User Event or set up a “trigger source†of periodic events. Here’s an example of a JKI with two timed triggers: Periodic Triggers with JKI statemachine.zip

You use it too little; one should ALWAYS use “States in Frontâ€, never at back. Enqueue the “idle†at front. Don’t think of it as a queue, think of it as a call stack. But note that there are better and more flexible ways to do this. Another example is to have a separate loop fire “Do XYZ†User Events at the JKI machine. One can have multiple such loops with independent periods, and the UI remains instantly responsive, even if the periods are long.

Is there a list somewhere of the operations that block a thread? In other words, when do I have to start worrying about threads or execution systems?

Back when I used to “loop†states in a JKI template in this way, I would just call “idle†if I wanted to give an Event a change to be handled. Often, I would modify the Timeout case such that the timeout could be specified in the “idle†command. So my “DMM_Read†state would post: idle >>100 DMM_Read Does calling “idle†not work for you? — James BTW, I would currently recommend creating the ability to fire a “delayed User Event†at the Event Structure. So “DMM_Read would send a User Event, delayed by 100 ms, containing the command “DMM_Readâ€. The advantage of this is that any number of “loops†can be occurring in the JKI statemachine at the same time, with independent cycle times, and with all Events being unblocked.

I think the “static†data they are referring to there is accessible from every call to the function, thus it would not be safe reentrantly call the function. But LabVIEW reentrant have separate data spaces, and don’t share data between reentrant calls.

What would be nice would be if LabVIEW supported a multi-part “Call by Referenceâ€, where one could fill the inputs of a function, pass it to an async process for execution, then read to outputs when it comes back. That would be type-safe and very simple. For async HTTP Get, you’d just need a reference to HTTP Get. Might also simplify command messages as in the AF.

Can’t open the example ‘cause I’m still on 2013, but there is no “casting†required in the method I’m thinking of.

For comparison, I made a quick version of the asynchronous HTTP Get (LabVIEW 2013; Messenger Library): Async HTTP Get.zip You can, if it is alright to kill the TCP reference from a parallel loop.

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.

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

“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):

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

The OpenG Toolkit VIPM package has this license: 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.