drjdpowell

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

I'm surprised as that shouldn't be possible. Messages are handled in order sent, so the Registration must be handled before your "Deploy_FPGA" message. Everything in this code is strictly ordered, so there should be no race condition. Does the ObsReg custom probe work on RT? If so can you place a probes just before the "FPGA_Initialized" Notification, on both the ObsReg and the Error in. If it is a race condition preventing registration, you will see this in the ObsReg probe (do it both with and without the time delay).

Does the ObserverRegistry probe work on RT? The probe included in the package will display all the registrations just before you make the Notification. Another idea is to take one of the message loggers, make it a nonreentrant actor so you can open its FP on RT, then use it to see if the notification is getting though.

Are you sure you aren't passing an error in to the "Notify Event"? No event is sent on error in. I generally don't connect the error wire to notify unless I want to not Notify on error. Also, are you passing the Notifications over TCP?

A coincidence. I'd just committed to fixing the issue of missed events from the "Self:Initialize" case five days ago. See Issue 13. However, using a State Notification instead of an Event one should fix that; does it not on RT? Note, BTW, that you shouldn't do both an Event and State Notification on the same label (I think this isn't the problem though). If it is only an issue on RT, then I will look into the TCP communication actors, who treat the first Registration message specially (and thus a bug might be their).