drjdpowell

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.

Follow-on question: Why does the CVT NOT have a Variant type?!? I was going to suggest to my client that they could both significantly simplify their code and guard against race conditions by grouping data in cohesive clusters, but that doesn't seem possible due to the lack of a variant type in the CVT. Why is it missing?

i don't think there can possibly be a race condition in the code itself. If you send message A then B, then they are handled A then B. Could there be a compiler bug on RT affecting either User Events or the DVR the ObsReg uses?

Ah, sorry, so it works on RT, but not in an EXE on RT. Debugging the hard way, then: you’ll have to log to a file. The method "vi.lib\drjdpowell\Messenging\ObserverRegister\ObsReg Core\ObsReg to Table.vi” may help in this. Also, quickly try: 1) not running the error wire through the Notify 2) double check you didn’t accidentally run the wires under the Register-for-All call rather than through (this has happened to me once; one cannot tell by looking).