Showing results for 
Search instead for 
Did you mean: 

Typedef value from .ctl file Front panel Control Reference

Go to solution

Hi Blokk!!!

The post you send is pretty related to me. Thank you... But in Solution its clearly mention by Hooovahh "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." So, I will look at the example attached in that post and if found something interesting then come back again to discuss it. 

0 Kudos
Message 11 of 21

Hmm, as a workaround, something like the snippet below is in my mind. You can get the values of the elements in the new typedef cluster by name. I used a VI from MGI ("MGI Get Cluster", ) plus the "Flattened String To Variant" to parse out value from the incoming TCP/IP binary data string.


Test for Exe_v2.png

0 Kudos
Message 12 of 21

Hey!! Can you send me or zip up the Required MGI  mojo files? As to install through VIPM, I have to ask my IT for administration right and blau blau... Sorry Blokk. I am asking you a most idiotic thing I know but really excited to see your implementation. 

0 Kudos
Message 13 of 21

Hmm, I am not sure if it will work this way, but unpack the attached zip into the following folder:

"  \National Instruments\LabVIEW 2016\user.lib\   "

So it will be like this: c:\Program Files (x86)\National Instruments\LabVIEW 2016\user.lib\_MGI\


Restart LabVIEW. Then try to open my VI...


EDit: if you have an earlier version than LV2016 this might not work. Please just ask for permission from your IT people, you can get really good things via VIPM! 🙂


0 Kudos
Message 14 of 21

Hey, I have attached the VI "MGI Get Cluster", and another one which is callee, "MGI Get Cluster" zipped. I backsaved them for version 10.0. So you should be able to check my example with these two VIs...

0 Kudos
Message 15 of 21
Accepted by T@nvi143

Also tested the VI with the Cluster element (I am not sure what happens if there is a typdef cluster inside typdef cluster, I will play with that case):





Message 16 of 21

Thanks Blokk. Sorry for accepting the solution lately but wanted to test it on every condition and  scenario. It work's perfectly. thanks a lot for every support. I owe you a beer... 

0 Kudos
Message 17 of 21

I am happy the trick worked for you! Good luck with your project! 🙂

0 Kudos
Message 18 of 21

What am I missing here? Aren't you still having to hardcode the Typedef  with a constant cluster when you are converting from variant at the end?

0 Kudos
Message 19 of 21

Well, you are right. But the trick/workaround is that, you do not try to convert the whole typedef cluster. Only the required elements, by NAME. See this previous snippet how:


So this is a kind of partial solution. I could imagine, this can be useful, when you have an ever-changing SERVER side, where the typedef data cluster mutates time by time. However, you do not need to change the code at the CLIENT side, just pick the required values BY NAME. Imagine, you have a single SERVER unit, and lots of CLIENTS. It is very useful that you do not need to recompile/redeploy the client code every time when you mutate the typdef cluster at the SERVER...


edit: of course, you still need to select the data type for the element you picked by name, in order to convert it from variant. There are certain ways, see like this:

I would also imagine, using the new cool features (vim, Type Specialization, etc...) of LV2018, one could even improve my snippet further for this specific server-client typdef cluster exchange task...

0 Kudos
Message 20 of 21