drjdpowell

Are you using matching bitness? You have to use the same bitness, 32 versus 64, for all DLLs and LabVIEW.

I don't tend to use them unless they have meaning beyond the message itself (ie. they are a natural grouping of data, rather than something that just exists for the message). Most of my messages contain only one piece of data, so no typedef needed (unless that data is naturally a typedef). Also, it is possible to go more than just a typedef: have an API of subVIs to send and receive the messages in a common library. This can be a lot more powerful than just a typedef. An example would be having any message starting with "Config:..." being passed to a Config subVI, with multiple possible messages being handled by that subVI ("Config: Get as JSON","Config: Set from JSON", etc.). Another option is to send an Object that has multiple methods that the receiving actor can use. I view a typedef as a poor cost-benefit trade-off, since you have the coupling issue without the maximum possible benefits.

Plan? Yes, but not a priority. Note, though, that JSONtext returns substrings, meaning you can implement filtering in LabVIEW without making data copies, so the following code implements your example: More effort, of course, but it should be fast, and using LabVIEW is very flexible, and more debug-able.

Unfortunately this contrasts with the current behaviour that null-->NaN for a floating-point number, rather than being the default number input. In standard JSON, the float values NaN, Infinity and -Infinity have to become null, and to convert them back to a default value doesn't make sense. We could add an option to "ignore null items" which would treat nulls as equivalent to that item not existing.

A possibly better option is to replace your string/integer values with JSON strings, which is LabVIEW strings with <JSON> at the start of the name. So "<JSON>Comment" rather than "Comment". JSONtext will happily parse out the value into your cluster as JSON, then when you actually need your value you can convert it to string/integer, with appropriate handling if it is null or throws an error. This method, by the way, is also how to handle JSON that has variable structure.

That one is trickier. What is null supposed to mean, interpreted as an integer? Unlike for Floats, there is no Not-an-Integer value, nor is there an obvious "null" value like an empty string. Should one just use zero as null? Or should one consider the null to be that same as if the item was not present at all in the JSON, those using your default value in the supplied cluster. Why is whatever generated this JSON providing null values at all? Especially in place of strings and integers?

The error is coming from where you attempt to convert null (as in "comment":null) to a string. Intuitively, one would think that a null should be equivalent to an empty string (just as when converted to a number, null becomes NaN and does not throw an error). Thank you for the report.

Why the "Preallocated"; are you trying to have a firm limit of 12 clones due to the long-term running? With "Shared Clones" this stuff has been implemented by numerous frameworks, but I have not seen a fixed-size pool of clones done. I would implement such a thing with my existing Messenger-Library "actors", but with an additional "active clone count" to keep things to 12.

Post a simple vi showing the error, please.

First thing I would try is to follow the "Useful Hint" given in the spatialite link and try and load the extension via the sqlite3 command-line tool to see if it works there or gives a more informative error message.

I don't use any messenger-library-specific way. Usually I kill a reference like a notifier, but lately I have been using the new "channels" feature, which have a "last value" shutdown Boolean. So far, channels have produced cleaner code.

Sorry, I've been lax in updating the Tools Network and the LAVA-CR. I have updated the LAVA CR to the 1.11.1 version.

Just a warning: this bug is the prime suspect in an application failing after 55 days continuous use. LabVIEW has a limit of one million Queues alive at any time, after which "Obtain Queue" throws an Error 2: out of memory. This happens after 55 days if one actor shuts down (without its Caller shutting down) every 5 or so seconds. Unfortunately the application was built two days before this bug was reported. Please upgrade to the latest Messenger Library version.

Sadly, I still have no experience with PPLs, and you'll have to ask someone else. I have no idea about palettes.

Here's a couple of diagrams. You seem to be doing this: Where the privately-namespaced copy of Messenger Library in your ppl cannot communicate. But I'm suggesting this: Where every component uses a common ppl.

Why?

You've just told me the equivalent of: I want two people to talk to each other, but each use a private language that no other person can understand.

I think you should put Messenger Library in a ppl and have all your other code use that ppl. Then everyone is using the same namespace. Why have you not done that?

I think there is a misunderstanding somewhere as what you describe here is almost the opposite of what I suggested here:

Here is a link I found that I think might be the same issue, though with a Global Variable as the communication method between components: https://forums.ni.com/t5/LabVIEW/How-to-access-common-global-variable-between-different-Packed/td-p/3324410?profile.language=en There, as I suggested above, the solution was to put the common dependancy in a common ppl, that all communicating components used.

A short list of possible techniques: 1) Let the hardware do the timing. Things like DAQmx or IMAQdx can provide Events, such as "FrameDone", and some hardware can provide buffered data in precise short periods (every 50ms, say) where you can just make your timeout 0ms, because waiting 50ms means nothing to your UI actions. 2) have a loop/actor send a message periodically. In "Messenger Library" this actor is called "Metronome", and there is an AF component called I-forget-what that does similar. 3) send a time-delayed message to oneself; resending when it is handled. Also on Messenger Library and the AF. 4) Calculate the time till the action is next due, and use that as timeout (or just do the action if the remaining time is zero or negative). Recalculate after an other message/event. Generally, I would advise one never use a fixed timeout value to schedule a periodic action. With the above methods one can easily have multiple periodic actions occurring on different time scales without any interference (assuming all the actions are reasonably quick).

But that wasn't the idea. Your plugins can't pull in different copies of common dependancies; they must use the copy in the exe, be that source or a ppl. You need to consult someone who is an expert in plugins.

A possibly useful link: https://forums.ni.com/t5/LabVIEW/Verify-plugin-source-distribution-after-build/td-p/3771429

BTW, I'm no expert in such plugins, but this statement seems very wrong to me. Your plugins should find common dependencies in the EXE that is loading them, not making new copies.

Ah, so really your issue is about "plug in" architecture where you want to be able to drop new plugins to a folder, and there is the problem of the plugins depending on common code (Messenger Library). I have only previously done dynamically-loaded code that is built as part of the same build as the EXE that loads them, where such issues don't come up. You might be better to ask in another forum, as the issues you have are not Messenger-Library specific and will be common to other such plug-in designs. Another option is to put the entire of Messenger Library in a PPL (changing namespace) but then have ALL your code use this PPL instead of VI.lib (so everything uses the same namespace).