drjdpowell

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:

I think you may be misunderstanding how "Variant to Data" works and what it is for. Providing a type inside a Variant to the top input does nothing; instead you need to connect the actual type. It converts variants into a specific data type. You don't need "Variant to Data" at all for your Controls, as they stay as Variants. And names never matter; if you get the data structure right, it will work. "Variant to Data" and "Set Control Value" both ignore that actual names in the data. I do Controls to/from JSON all the time, so I will try and dig up an example.

My questions remain the same as back on June 15: what are you trying to do?

Definitely on my list of JSONtext additions. Ideally, I would want to implement RFC 7396: JSON Merge Patch, with the ability to generate a "patch" of the differences between two JSON texts, then apply the patch to one text to get the other.

You seem to be sending CAPTURE... but your receiver is expecting only CAPT...

I'm trying it out on my own projects at the moment, but I intend to release it. I could post a copy here if you want to try it.

What are you trying to do? Are you trying to load "Page 2" of your tab control? Because the number 1 will be converted by "Variant to Data" to your "Page 2". With JSONtext, I placed speed over making the Variants perfect. Variants are a means to an end. I did the fastest, lowest-overhead way that will produce a Variant that can be converted to your datatype correctly. For an enum, an integer converts correctly and is probably an order of magnitude faster than what JSON API does. Why are you using the Variant version of that VI, anyway, rather than the VIM (which hides the variant stuff away entirely)?

I've used public inlined methods (non-VIM), so that can't be the issue.

I use the ctrl-L shortcut key to bring up the Error List Window. Broken actor will have a red X.

My first suspicion would be you forgot to wire the newly-launched actor to your cluster (ie. you "dropped" or "lost" the address). The problem is almost certainly in your Top-Level actor. Use Probes to debug your actor's address wire backwards. Using the standard probe, an unlaunched actor address look like this (note the Messenger.lvclass): While a launched actor looks like this (note the EventMessenger substituted for Messenger.lvclass): You can also use the custom "Address Probe", which looks like this: The "X" indicates an invalid address, though note that this could be a launched-then-shutdown actor address, rather than an unlaunched one.

That error is from when one tries to Send a message to the parent class of all Messengers. The parent class is "virtual" meaning it is an error to actually try and use it, rather than a "concrete" child class like your EventMessenger (orange wire in the image). Your Aerotech.lvclass "actor" has a Messenger inside it. If you have never "Launched" it, then it will not contain a concrete child-class Messenger and will throw that error (note: it will throw a different error if it Launched and then Shutdown for some reason). So, I think you have a bug somewhere upstream that has caused you to "drop" the address of your Aerotech actor, or to never launch it, and you are trying to send to a never-launched actor address. I will try and improve that error message to mention unlaunched actors.

Sounds similar to this current conversation on the AF group.

Has anyone had experience with web services from a cRIO? Are they unreliable, as described here?

It is built in. Just use it. BTW, Something not built in is the extended math functions (log, sin, stdev, and the like). But I include a vi for loading that:

If you use Variant handling using the Variant Parsing Library, or use any library that does, please see this conversation, where I learned from AQ that the name in a Variant is never to be supported in NXG, eliminating all sorts of advanced capability.

One trick I've done in the past is to include a static reference to an empty subVI that I know will install in the same subdirectory as my plugins, and get the path to that subdirectory from the VI reference. Then I do a recursive directory search from that base directory for my plugins.

I not aware of such an issue caused by Messenger Library, and that subVI does nothing other than fire a User Event. Are you able to make an EXE and try that?

This is issue 9: https://bitbucket.org/drjdpowell/messenging/issues/9/non-reentrant-actors-started-by-themselves# You can freely change the strictness of the reference to “Dynamic Launch Shell” if you like; so you don’t have to downgrade to an older Messenger Library version.

Arrgh! Same problem, only now nothing suggested above fixes it.