typdef constant programmatically from it's path

[david_tatrai]

Hi, in a project I want to use queues to communicate data between various modules. To make the program scaleable, I wanted to make a communicator module that reads all the messages and forwards them to the corresponding place. To make this communicator universal, in the queues I use variants converted from typedefs. The number of the modules communicating can vary during the runtime of the program (dynamic connection/disconnection of various hardware modules and so asynchronous VI calling is in the background)

So in the communicator, I’ve got to be prepared to undefined number of cases. This in my case is not so difficult if the queues are name referred.

But I have a problem that I couldn’t find any solution: In the communicator, I should convert the variants back to  typedefs, without hardwiring the data types. I found the “Get Type Definition Path VI” in the variant palette that works perfectly.

So my question is:  Is there a way to get a constant of a typedef programmatically, if the path is the only known thing? Or is there any other way to get a constant of a typedef inside a variant? (programmatically)  

Thanks, David

[paul_cardinale]

Functions palette -> Application Control -> Scripting -> New VI Object

[crossrulz]

Sounds to me that you should be using the Actor Framework.  Part of that mechanism is you have a main actor that launches everybody else and they use the Send Message To Parent Actor to pass data up.  The main actor then passes on the message to whoever needs it.  It is all OOP based.

[david_tatrai]

I've made numerous trials with VI scripting, but unfortunately didn't manage to solve the problem. Could you help, how to parametrize the New VI Object function? Thanks in advance.

[david_tatrai]

Yes, You're right, actor framework probably a useable architecture for this problem, but I've never used OOP so this time it would require a too big effort. (It's planned to learn.)

[Ben]

LabVIEW is "type safe" for the most part by the nature of its wires. At development time the definition of the wires are clearly defined.

Even if we did provide an easy method to get a type from file and it was wired to a "Variant to Data" node what do you think you are going to do with the wire after you have it converted to a type def?

Could you sketch up a diagram and put a box somewhere in your diagram "where the miracle happens" so that we can see what you are trying to do?

You could crate a sub-VI that is used to decode all possible data types and pull out common elements but the question still remains where doe your type defined wire go to?

LVOOP will let you handle both ends (putting it into a variant and getting it out) by giving you the option to pair up "encoding" and "decoding" to from the variant.

Not sure if we can really help,

Ben

[Hooovahh]

What you want to do is not possible, the way you want to do it.  The type must be known at compile time.  You can't write code that changes the cluster output as it runs, you can only link the input and output to a common type def control (again at edit time).  You can have a Variant to Data converting it to the appropriate type but it can cause run-time errors if the type isn't what is expected.

Even NI functions that change data types need to be told what type of data type to be.  The Dequeue element needs a reference passed in from an obtain function, where the data type is specified.  Type cast can turn into anything, but you need the data type as an input telling it what to be.

[david_tatrai]

I've created a simplified version of the communicator and uploaded it. Any advice would be appreciated. (The real code is  better organized)

I have some ideas to solve the problem by choosing other ways for organization, but for me this would be the most elegant way. 

[Hooovahh · Accepted solution]

I've had an architecture that sorta looked like this.  The idea was you have two queues, one for your "To" one for your "From" with the data type a variant for both directions.  The variant attribute can contain more than just the value, so one attribute is "Method Name" and is a string.  Based on this string we would go to a state in a state machine.  

We knew that if the Method Name was "Set Analog" then we knew the variant was actually this type def'ed cluster so we knew we could safely convert the variant to that typed cluster.  So each method like "Set Analog" would have two type def'ed controls, one for the "To" one for the "From" so when we sent a reply we knew we would go to the "Set Analog.Reply" case where we would turn our reply into that type def and send it back on the From queue.  We also bundled other things into that variant like if there was an error from performing the action, we had a GUID for some methods so we would reply to the right module, there was an option for generating an internal event, that knew not to send a reply, and all this information was packed into that variant payload.

But again the thing to remember is this still wasn't dynamic (it can't be) LabVIEW is a strictly data typed language, and even if we get a variant in and we know it is a type from a specific path, we can't change the data type of the cluster at run-time. That might end up breaking the VI, like what if the type def is actually an enum, and you try to unbundle it?  The VI is already running it can't become broken after running.

[david_tatrai]

Thanks, for the comment!!

Actually this is a very simple "hack"/solution for my problem. This way, I've got to modify only the data structures a bit.

You're right, this architecture is not an absolutely universal, as various data types can be sored in the variants, but in my case, the typedefs inside the variants have similar structures: a cluster with various elements including the from and to tags. And during the "hardwired" test at the beginning of the development, it worked fine without any issues.