drjdpowell

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

I don't understand this bit. Are your "steps" source code rather than built?

Could you explain a little more what you are doing. I am confused that you are using TCP (something usually used for communication BETWEEN applications) and having namespace conflicts (which happen when you have multiple paths to the same-named thing on the SAME instance). On no condition would I recommend renamespacing the library, as TCP involves flattening the messages to strings, and that uses the class names, which you are changing. The TCP Messengers override the usually LabVIEW flattening for some common messages for reasons of performance, replacing the class names with a much-shorter format using an enum for class type. This is why some messages will still work. But this is strictly limited. I had imagined, when you first brought up Teststand and TCP Messengers, that you were building a separate LabVIEW application, and that Teststand (in a separate application) connects to the first via TCP. That could not have conflicts.

Note: if you have a Tools Network package, you can request assigned ranges of error codes for just your library. For example, "SQLite Library" errors start at 402860

Exactly. You can even do the case where the types of actor is determined at run time, in which case the caller makes a JSON object like this: {"Actor Class Name":"MyActorX.lvclass","Config":{...}} Then on application load, the caller launches an actor of that class, then sends it the "Config".

How does your calling code keep track of the different clones? Match that. If the caller gives them specific names, such as storing the actor addresses in a cluster, then use those names in a JSON object. If, instead, the actor addresses naturally are treated as an array, then store a JSON array.

That looks right to me. I don't know why it wouldn't work.

Are you sure you are referencing the right clone of your facade vi? A common error I've seen is to get a reference to the master copy of a reentrant vi and not to the actual clone in use. How are you getting your reference.

Yes, that is the problem. If I connect a "Buffer" of a certain data type, the "Data" input should adapt to be that datatype. That's how Queues work, but there isn't a way I can identify to make VIMs work that way. Outputs adapt to inputs, but not unconnected inputs.

Maybe we need a "placeholder" type, or "Your Type Here". Actually, NI seems to be using an "anything" cluster of zero elements in primitives like "Flatten To String" and "Flatten to JSON". This has never struck me as being flawed.

BTW, does anyone know of any other "malleable cluster" libraries or work using VIMs?

If you do this, you still end up with a broken buffer wire (you just also get a broken data wire if you choose to incorrectly wire in a scalar). Note that the type of the output wire now matches the input wire now instead of being a DVR. I've now getting the buffer wire to be unbroken when the Data input is unwired, by making the default Data an "undefined type" (a class call "Undefined Type"). I added a case that is unbroken when Data is this "undefined" type, which it is when the User has not wired that input. The error message the User gets in this case is just the one for a required input not being wired, which is much less confusing than a broken "Buffer" wire and an additional error message about type mismatch. AQ, what do you think about an actual "undefined type type in LabVIEW and/or NXG? One thing that could be useful for NXG is a undefined type in a cluster constant, which defines teh name of the item without the type, and allows the type to adapt to that supplied by the first Bundle-by-Name. This would avoid some of my concerns about clusters in NXG.

I'm favouring just freeze the name, as that is simplest for the User to understand, given that it is difficult to diagnose, let alone fix, any problem if the name adaption goes wrong.

Question for AQ: I'm trying to use "Unbundle by name" to access the elements of the cluster (the buffer array and the index integers). This works, but if the User accidently connects a cluster without the right-named elements, the unbundles can get scrambled, and not properly reset to the right names when a proper Buffer cluster is attached. The only solution then is to delete that VIM instance and re-drop it from the pallets. I can't find a solution and may have to switch to an unnamed unbundle, using the positions in the cluster. That is less than ideal, and won't work in NXG (you know my negative opinions on cluster changes made in NXG).

DVRs can be used, but not created or destroyed, inside an inline VI. Not clear to me why that is. Thus this library can handle buffers inside DVRs, but the User has to explicitly create a by-value buffer and put it in a DVR themselves.

Sorry, I don't understand what you're meaning.

I think I can fix this by making the last case of the Type-Specialisation Structure be a case that passes the Buffer input to Buffer Output. I make sure this last case is broken, so it is only used for type propagation when all cases are broken.