drjdpowell

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

SQLite isn't a database server; it's intended to be accessed only locally, not over the network. See https://www.sqlite.org/whentouse.html.

Conditional Tunnels had no performance benefit in 2012, but beta testers of 2012 argued for higher performance, and for 2013 they were changed to use the same techniques used with indexing While Loops, which are much higher performance and not something one can do another way.

I would say the conditional and concatenating tunnel options are a very notable feature introduced post-2009.

If it's an additional "fix it up function" then I can support many versions easily. Might be slower, but one doesn't care about raw speed in a config file use case. But I'm wary of adding more extended features to the core functions, where I do care about speed and simplicity. As an example of the simplicity issue, currently one can overwrite whitespace when setting values in a JSON. I use this to allow quicker setting of items in the JSON, allowing update in place where possible. If I have 10 char of whitespace and overwrite 4 characters, I now have 6 char or whitespace. But if I have a 10-char comment, and overwrite 4 char, I now have corrupted JSON.

It's a Client-Server design, where the cRIO actor would be the Server. A disconnect of the Client has no affect on the Server and it continues to run. The Client (on the main computer or another RIO) needs to detect the disconnection and attempt to reconnect. Nobody needs to shutdown, though the Client will need to go into a loop of trying to reconnect every few minutes until the network is back up. See the conversation starting here, where bbean was dealing with the issue of the Client not being able to connect to the server.

Do you want to be able to programatically add comments, or just ignore them on reading? I am wary of adding features to the core functions as I want to protect its speed and simplicity, but I don't mind additional functions. In fact, I've been considering a function that is intended to take human-edited JSON and "fix it up", correcting common errors like leaving an extra comma when deleting. This could easily strip comments.

Error 1510 is "The requested service was not found as a registered service with the NI Service Locator.” Does the LabVIEW Example "TCP Named Service" work on the two machines? Did you use the right IP address?

To my understanding, the data type is fixed at design time but the Event Registrations are run-time dynamic. I think Jack Dunaway's excellent examples on User Events showed this.

I see your point there; a "read only on first call" input makes sense. Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration. If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules. I agree they should not have changed the behavior that has applied for so long (especially without telling people).