drjdpowell

A note on "Messaging": A Messaging system is one where different bits of information "messages" come through and are handled one-by-one at the same point. Because different messages are mixed together, the communication cannot be lossy. Even if you have no messages that represent must-not-be-missed commands, you will still have the problem of missing the latest update of an indicator, because of an update to a different indicator. This is different from the case of using multiple separate (possibly lossy) communication methods to update independant indicators (often, this kind of system uses the terminology of "tags"). Because they are separate, the latest value of each "tag" is never lost. But this is not "messaging". Considerations of whether to use "messaging" or "tags" is another conversation.

One possible option with a bad hardware driver is to make your actor an independent exe, using the NetworkMessenger for communication Then you can kill the entire exe and restart cleanly. I've never done that, though.

Unfortunately one sometimes has to call code like hardware DLLs that are not well written. I have to use a dll that will throw up a dialog box underneath the main LabVIEW window (never to be clicked on by the User) if it has a problem.

Hi Max, Recovering from a stuck hardware actor is often impossible, as it is some dll call that is stuck and LabVIEW cannot abort the call. Nor can the dll be reloaded without restarting the entire application. However one still needs to recognise and report the problem. I use the "Timeout Watchdog" recently added to the library. The main actor uses that on the handling of some message that periodically comes from the hardware actor. Now, another unreliable actor is one that handles potentially large blocks of memory. An out-of-memory error will abort the actor, invalidating it's address, and you can use an "Address Watchdog" to notify Main. In that case you probably can restart the actor and recover.

It's because of the lack of quotes about 'MFG'. The first function you are using requires valid JSON values, but you are feeding it unquoted standard text.

I ask about performance because I wouldn't have thought your new method would in general be faster. When I was considering how to improve the performance of this library I became convinced that I should produce a new package that delt directly with strings, abandoning the objects and variant attributes used here. That package is JSONtext, which I use in all new work. So I am unlikely to make more than minor improvements to this library. However, someone else could continue development of LAVA JSON if they like.

What kind of performance improvement does this make?

working on it

As of the latest Tools Network version, the palettes should also appear in the "Flatten/Unflatten String>>JSONtext" palette, in place of the install link in LabVIEW 2019. It's programmatically added, so let me know if that doesn't work for you.

Sorry, I missed your post while on vacation. I actually don't do UML diagrams, so I'm not much help.

Issue 31

See the posts starting here. You have to use opkg to install sqlite on a Linux RT system.

I don't believe a this-VI ref has any problem; it is only a ref openned by name. Example, if I openned a reference to the string "MyVI.vi:6", then clone 6 of MyVI could leave memory without properly closing the ref.

That isn't a use case; it's just the next level up in your solution to whatever the use case is. What is the real-world use case? Who's your "User" and what are they trying to do?

I'm curious; what's the use case you have?

Please try the new 1.3.0 version in the LAVA-CR.

I know this is a OOP question, but there are other ways of addressing your problem that use "duck typing", such as Shaun's SCPI instruments. In my case, there would probably be an "actor" somewhere that responds to requests for current readings, and any actor that responds to those same messages is capable of substituting for it.

The dll uses a global variable, in such a way that it isn't safe to call function in parallel from multiple threads. Whatever that is called if "single threaded" is the wrong terminology.

No, I was trying to avoid blocking the UI thread, as some of the calls take a long time.

Thanks guys, I've been having intermittent lockup of dll. This dll is not safe to call from more than one thread at a time, and I had put in protection to prevent that, but I noticed the lockup occurred in two different LabVIEW instances at the same time. My protection, unfortunately, is confined to a single instance of LabVIEW, and thus couldn't stop this.

Question: if I have VIs running under two different projects (thus separate "instances" of LabVIEW) and both VIs are calling into the same dll, is a separate copy of the dll loaded in each instance? Or is there only one copy of the dll?

FYI, the DEV template is designed to be able to handle simple Events very quickly and easily, just like a more simpler Event-Structure loop. The follow-on actions output from the Event Structure is set to "use default if unwired", and the default action is just the error handler (and message reply). The "Next Action" and "Reply" subVIs that must execute are performance optimised to add negligible overhead in the default case of no actions and no message to reply to.

Can I encourage you have another look at the DEV template? You seem to have taken the DEV template and deleted the entire "Follow-on Action" handler, and are now trying to reinvent some of the very features you just deleted. At the very least, don't delete the error-handling case which already makes a Notification of any error. Have you seen the Youtube instructional videos on Messenger Library? The DEV template looks complicated, but is designed to support both high-performance use, like a simple Event-structure (with error handling) and more complex use, like a JKI State Machine. Since even simply-running things often require complex initialisation operations, I would suggest that starting with a "simpler" structure will led to less simple real-world programs.

What JSON file are you using? You've just given me a VI that expects JSON, and a YAML file. I note that your YAML contains no arrays, yet your JSONpaths treat "Configuration" as an array.

Different applications can have different config needs. In fact, a single app can have multiple different needs requiring different styles and thus different config files. So it is hard to give general advice other than "JSON is flexible and easy". Re your questions: 1) saving and loading files isn't complicated, so I've never seen value in a separate "config" actor. 2) I usually use just "LabVIEW Data", but see also this blog post. 3) I've done similar systems. Here configuring the system involves reading (from the config file) what actors are needed and launching them before sending them there config subJSON. This can involve dynamic loading of the actor class (from the lvclass name in the file). Your max of 96 messages second doesn't sound that much to me. Using a standard message will be simpler. But this is something you should test as soon as possible. It is ok to introduce something more complex if needed, but only if needed.