05-08-2017 06:29 AM
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.
05-08-2017 07:36 AM
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 Value.vi", http://sine.ni.com/nips/cds/view/p/lang/en/nid/209753 ) plus the "Flattened String To Variant" to parse out value from the incoming TCP/IP binary data string.
05-08-2017 08:00 AM
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.
05-08-2017 08:41 AM - edited 05-08-2017 08:51 AM
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! 🙂
05-08-2017 09:48 AM
Hey, I have attached the VI "MGI Get Cluster Value.vi", and another one which is callee, "MGI Get Cluster Elements.vi" zipped. I backsaved them for version 10.0. So you should be able to check my example with these two VIs...
05-08-2017 11:06 AM
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):
05-15-2017 02:51 AM
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...
05-15-2017 02:54 AM
I am happy the trick worked for you! Good luck with your project! 🙂
07-30-2018 12:24 PM
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?
07-31-2018 12:18 AM - edited 07-31-2018 12:22 AM
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: https://forums.ni.com/t5/LabVIEW/Typedef-value-from-ctl-file-Front-panel-Control-Reference/m-p/36240...
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: http://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/parsing_with_vis/
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...