Jump to content

Cyberius

Members
  • Posts

    4
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    United Kingdom

LabVIEW Information

  • Version
    LabVIEW 8.6
  • Since
    2006

Cyberius's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi all, I have a Labview application in which I want the user to be able to create any number of floating panels that could be [value displays/interactive panels/status information]. Different panel types can be different sizes. I also need these panels to be dockable and the dock area must be scrollable if there are too many panels. I have done something similar already, where I clone any number of template VIs. However, this only gets me a fraction of the way. Is there still no way to instantiate controls dynamically? I have played with panes and drag and drop, but this didn't get me far either. The best I have so far is to drag controls into an array, but of course all the controls must be identical in type and size. Is there a way to instantiate a VI from a template and then transfer the created controls from the instantiated VI to the main VI? I have seen the example that does docking with SubPanels, but that doesn't help much either. Many thanks, Christie
  2. Hi All, I just had a look at the MGI components. They are also pretty impressive. I like that it is possible to get the strings back without writing it to file. I would have liked if it returned field names and values separately, but this can be done manually by splitting at "=", assuming there is no other "=" in the name or value. Also, they seem to be able to parse timestamps and waveforms correctly. I still need to do waveforms in my VIs. Christie
  3. Hah! I was not aware of these VIs. I had a play with it just now and was rather disappointed... that it works quite well. However, I did find a few restrictions and have a few comments. 1) Data can only be saved to file. I use my VIs to parse data to/from a database and can be used to store it in any other medium that can take strings. 2) The field names are built using "." as separators, which means that a field such as "Cluster..Numeric" can be parsed in two ways, either "Cluster" and ."Numeric" or "Cluster." and "Numeric". Of course this won't be a problem, unless you have both cases in one structure. I know, this is beyond nit picking. In my database, I save each field name as an array of strings. 3) Clusters within the main cluster are saved as sections (I suspect this is intentional). This has the side effect that these cluster names must be unique. 4) <.size> is appended to indicate array size, which also restricts naming of your array. (Again, nit picking.) I am using the raw array name to store the array size to avoid this problem. 5) Recursion is used instead of iteration. This is just a preference, but I feel that one has less control over a recursive solution. 6) I noticed that timestamps are just flattened to strings. I checked this case in particular, because I had trouble with it. 7) The root datatype has to be a cluster. (I assume this is because it maps so nicely to a config file.) It would be great if there were VIs that work like mine, but also VIs that automatically save to config files. I have not had a look at the MGI version, but I will. I have attached my VIs. I hope I have all the dependencies included. It's not very elegant looking and needs some cleaning up. Please have a look. Comments are welcome. Christie Strings - Control to & from String.vi Tool - Array Element Default.vi Strings - Variant to Strings.vi Strings - Variant from Strings.vi Strings - Variant from Strings - Commands.ctl
  4. Hi all, I have created a tool that I find very useful and from our meetings at the Cambridge Labview Users Group, I discovered that other people would find this useful also. I think it could make a great edition to the OpenG toolkit, but probably requires a bit of cleaning up. The purpose is to convert any Labview data structure, including multi-level nested clusters and/or arrays into pairs of name tags and associated string values, such that it can be saved to and loaded from a config file, for example. Labview can already do variant<->flattened string conversions, but if your data structures change between versions, you can no longer load your old data into your new structures. Also, flattened strings aren't exactly friendly to the eye. This tool gets around all that. I have used this tool in several programs with complex data structures and have had no problems. I had to use some of the OpenG variant tools to make it do what I needed, since building up a complex variant really is very complicated and requires information about type descriptors that I couldn't find in the Labview help files. I suspect there may be a few obscure type descriptors that still need to be catered for. Please have a look at the VIs attached and let me know if anyone would like this as part of OpenG. Christie
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.