drjdpowell

Here is the function I mentioned, BTW:

Does your receiving actor know the exact reply address that the special sender will use? You can use addresses as unique identifiers with "equals". There is a vi in the palettes that searches an array of addresses for the reply address on an incoming message. Your design is different from ones I'm familiar with, so that may not be a good answer.

This is Issue 9, the trickiest problem in Messenger Library at the moment. Can you try version 1.10.6, which is in the LAVA-CR (this has been submitted to the Tools Network and is working its way through the process. There is no ideal solution but this is my best attempt. Alternately, you can try renaming your Main:ActorNR to something else (assuming you don't need to launch it but are instead running it directly).

The dll should be automatically included in any exe; does that not happen with you? I have not tried using older dlls, but I suspect the would work.

A new video resource is the gdevcon1 videos.

Yes, DQMH is Delacor's framework, and is on the Tools Network, as is Messenger Library (which I wrote).

One loop per device is very scalable, when combined with asynchronous calls to allow an arbitrary number of such loops. The details are a bit tricky, but its the most scalable way to do it, which is why multiple people have generated frameworks to do it more easily.

They have this Sqlite function https://www.sqlite.org/c3ref/memory_highwater.html. But I haven't implemented it (yet).

I suspect your problem is not using BEGIN/COMMIT or some other way of wrapping many INSERTS in one transaction. Try looking at Example1, which inserts a large number of points.

Did you wrap your INSERTs in a transaction?

There are (not free) extensions of Sqlite that add encryption, but I have not tried them:

Note: The NI Labs version is now available without password protection.

Yes, that's the basic JSONtext use case: working with JSON: Working to/from LabVIEW data types is also a use case, and there is the (more complicated) ability to intermix JSON and LabVIEW Types in clusters using the <JSON>-tag method smithd describes, but a basic motivation of JSONtext is to be able to work simply with JSON-formatted strings directly.

At some point, but it joins a long list of other things it would be nice to have. I'd like JSONpath filtering, like $.MyArray[?(@.type="MyType")]

We'd have to deal somehow with projects that are in the CR and on the Tools Network. Personally, I sometimes have a newer version in the CR (and update the Tools Network less often when the changes have been more real-word tested).

I now use JSON for tree-like program settings, and things like test results and test scripts. I left objects and variant attributes behind and just handle text directly (JSONtext). Like others, your "time series" examples don't seem very tree-like to me (although my JSON test-result files do contain several serieses).

I'm afraid those functions have not been implemented yet.

That extension to JSON is part of the LabVIEW JSON primitives, and JSONtext supports that.

I few other methods for you to consider: 1) a separate "helper loop": in this, the main loop of the template is a "manager", with a separate loop inside the actor doing the work. The "worker" can be controlled by non-actorish ways (such as an Abort Notifier) by the Manager, which is always capable of handling new messages coming in. This encapsulates the non-actor communication, keeping it local (and understandable). I likely addition to this is a "job queue", to hold the list of actions that the manager queues up for the worker. Here is where one can have job priority, or cancelable jobs. Note that this is different from the "action stack" (what you called a "state machine"). These are different things that are too often combined. 2) Have a "Sequence actor" that does the long actions, which can't itself be aborted, but which acts on hardware via short-to-execute synchronous Request-Reply messages to separate hardware actors. Send the "abort" messages to the hardware actors, putting them into a safe-mode state where they reply to action requests with errors. The first such error message causes the "Sequence actor" to end it's sequence (using standard error-chaining logic). Note that if your stop really is an emergency then this bypassing of your complex higher-level logic to talk directly to low-level hardware actors is actually a lot safer and more easily testable. 3) An asynchronous version of (2), where the "Sequence actor" uses Async Request-Reply for interaction with the Hardware actors. Less flexible than (2), but more properly actorish, in that the Sequence actor is always able to handle messages. I actually don't mind your abort notifier triggered from outside the actor. This is, as you say, bending the rules for a limited and clear purpose, and for the special case of aborting. Unfortunately, though, you're dealing with the problem of "state" (true "state", not the actions of a so-called "QSM") and that isn't ever easy.

I use an object only when I'm doing a lot more than just passing data in a single message. So a "job" object might be sent to the "Worker" actor, who calls "do job", but then the completed "job" is passed on to another actor who calls methods to reads the results. Or a "data" object might pass through several actors for processing and display. If I just want to pass a loose collection of data from one actor to another then I just use a cluster. But I find it rare to do this, and my messages tend to either be a single piece of data (or array) or a tight collection of data that makes sense to be an object.

I, personally, rare!y make custom message subclasses, though it is my intention that one can use Messenger Library that way. Somewhere on LAVA is an example I made of doing AF-style Command-Pattern messages. But I generally either use variants or I create non-message object classes that I pass in messages (example: a dataset object, or job object, or fast-growing object). The later have useful lifetimes longer than one message pass. I'm not sure variants are that slow, btw, so I would benchmark before avoiding them. Edit> "fast-growing object" is some strange auto-spell correction, but I can't for the life of me tell what I was meaning to write!

I needed a reference I can wait on, and I do not know of a lower-overhead option than a queue.

I suspect one of your actors, or something it calls, is broken in the build. "Async Launch Shell" is what calls all the actors, and any one being broken will throw an error like this. What I would do to debug is build all my actors as separate EXEs. Even if they don't do anything when run by themselves they should at least run. See if you get an error in building one of them. Unfortunately, debugging EXE problems is very painful and time-consuming. You could try re-asking your question on the main "Messenger Library" thread, as other developers who use it on RT have posted there and may have advice.

It's an asynchronous action called "Reference Monitor", a variant of the "Address Watchdog" available on the library pallets. It's started inside "Startup type 2.vi". That VI exchanges messages with "Startup Handshaking.vi" (inside "Launch Actor") in order to get a Queue created in the Caller for the Reference Monitor to monitor. The Monitor is configured to send a shutdown message if the Queue dies. BTW, this is one of the best examples of "internal complexity to support external simplicity" in Messenger Library. Having things created by a Caller automatically clean themselves up is a major simplification, but to get this requires sophisticated internal plumbing.

An example (using and array of control references, but you can make Get/Set Control Values work similarly): To JSON: From JSON: