Neil Pate

You have my respect. I gave up on resizing GUIs in LabVIEW about a decade ago... Christian, I usually customise a boolean radio control to have nice big buttons vertically, this drives the selection of the current "view" which is just what I call the VI (actor, module, whatever) running in the subpanel. On the left hand side is the customised radio button. In the middle is the subpanel and down at the bottom (the yellow bar) is where my status panel (also a subpanel) gets loaded.

Sounds like you are on the right track. I do like your idea of a subpanel based config page, but in all honesty have not ever actually needed one yet (and I am talking reasonable sized projects here). I personally am not a big fan of the Actor Framework that ships with LV. I have probably not given it enough of a chance, but it just feels too busy for me. I have created my own lightweight Actor Framework (based on User Events and not queues) and that does not use the command pattern (I don't really like having a class per action/message).

Christian, the original solution you have described is very common, I have definitely used it in the past, with good success. Such an implementation certainly will allow you to get up and running nice and quickly. Unless you are updating your indicators at a ludicrous rate (like > 1000 Hz) or throwing huge graphs onto the screen I would not worry about performance. Modern CPUs are just so good. Even today I still use a tab for a GUI which I know is going to be simple (like a pop-up window or something), but certainly never as my top-level. However, the problem with the tab structure is only good for logical GUI grouping, it does not help you at all on the block diagram which is where all the trouble will be. I guarantee you, if your application works well and has a predicted lifespan of more than a few years you will get more and more requests just to add another button or indicator. This will be easy at first but after point you will reach critical mass of controls and indicators where it just becomes too unwieldy for you as a developer to make changes. You will struggle much more than the compiler... If you are comfortable with the idea of a subpanel for your configuration, then yes I would take it one step further and replace your tab with a subpanel. This architecture forms the basis of most of my GUI type applications to this day. Also I probably would not use a subpanel for the config, how likely are you to want to swap that out "on-the-fly" without changing the rest of the GUI? Note that as smithd mentioned, if you do go down the subpanel route you will have multiple VIs running in parallel, so you will need to start thinking about how you will communicate between them. There are lots of different techniques (queues, user events etc), figuring out this is a great way to push your LabVIEW skills to the next level.

Nope, just guessing. Something with two tabs very often ends up as ten tabs with a single event structure handling dozens if not hundreds of value change events. More than one UI loop is good, not bad. You may know what you want on the screen today...

Not directly answering your question but I would say the biggest favour you can do yourself is not use tabs, subpanels are your friend here., To answer your question, I know that in the past LabVIEW's "cleverness" sometimes caused bugs with charts where data would just not be present on the indicator if was not visible, but I would not bother about unloading panels.

Nope, only NI RIO hardware.

Craig, it's not like they took features out of LabVIEW when they introduced LVOOP did they?

Wow, a lot of work has gone into this! Nice toolkit Q. I have never been a big fan of XControls as they just have too many weird issues.

Thanks James. I have tried everything and cannot seem to recreate it. Don't really need to just now it is bugging me! :-)

I am looking through some RT code, and am a bit confused by the following node. Can anybody tell me how I would make the node with the "chip" icon on it? The VI with this in in under the RT CompactRIO target folder in the project. I am pretty sure this has something to do with Scan mode on the FPGA or shared variables or user-defined variables, however I am not very familiar with any of these. Any ideas? Edit: the C-Series module that this node refers to is currently tucked away under my FPGA Target, so perhaps this is old test code from when the module was used in Scan mode? If I move the modue out from the FPGA to just under the chassis the little glyph looks different, like a little blue square wave with a triangular wave just about it.

Bingo! Seems to work. I think all my clusters will be properly named as they will come from my code, it is only the arrays which come from the OPC-UA toolkit that may have this problem.

This is all part of my master-plan (insert evil voice) to use a variant repository for my across-loop data sharing experiement. Currently I am making a nice tree viewer for the variant attributes (kinda like Ton's XControl) and mostly based on this.

Courtesy of the OPC-UA API that comes with the DSC toolkit. I did try to check for a variant in a variant, but it seemed to keep going down the rabbit hole. I will try the variant to array of variants I do use this elsewhere. At the moment this is getting me out of jail, but it feels wrong on so many levels. The OPC-UA toolkit kindly tells me what the data type is, it just does not bother putting that into the variant.

I have a variant, for some reason it does not seem to have it's type information inside, the variant thinks it contains a variant (which I don't believe it does). I cannot do anything about this, this is how it is being handed to me. Does anybody know how I can retrieve the original data type? (do not really need to know specifics of SGL or DBL etc, just want to know it is an array). In the example attached I know this particular variant is an SGL array, so the Variant-->Data works fine as I have manually put in the type. However I am expecting various different array types. Variant Trouble.vi

Just for anybody interested. Courtesy of our friends at GPower (4th link on google, impressive!) http://www.gpower.as/downloads/bsd-license-explained

I would be pretty hesitant at trying to run mathscript nodes at anywhere near this rate. Not that I have tried to do it, just gut feeling tells me it would end badly. Marc, that thread you linked to regarding cRIO performance is very interesting, pity there was no real answer from NI other than buy the new controller :-( TimA I like your avatar :-)

Ditto to what the others have said. I have not yet tried building my application but just dropping the XControl down on the FP works almost as expected. One minor thing which I have not investigated the reason for yet is that you cannot resize the tree column widths. I am probably going to modify it a bit as I want to actually use it as a GUI component and I don't want it displaying the text "Attributes" and a few other things.

Thanks, I am now experimenting with using a variant to store quite all of my global system data, and this tree is a really neat way to show everything (for debug/dev purposes). I would have had exactly the same bug, so I have updated my package with your fix.

I thought it might be (I do have it installed), but it behaves much nicer than any XControl I have come across (no usual edit time strangeness I am used to with XControls), and is that not a Probe? OK, done some digging, seems like it definitely this. Thanks James (and Ton and Brian)

OK, so this seems to be native behaviour of variants with attributes, but how did you create the Variant Tree control?

What magic is this that allows a variant to be displayed as a tree? Or am I just being really dense after a long week?

I also used LabSQL when I did not have access to the NI toolkit, this was many years ago.

You mean the same System Configuration API where changing the time could cause a hard-crash of the cRIO. Yes lovely stuff that.

No, I am asking for the first scenario. Good to know it can be done. I have never really found the necessity to create polymorphic VIs, individual wrapped API VIs was sufficient for me in the past.

If you have something going wrong with your code, and you know it is one of the particular methods of the AE then (that have wrapped been wrapped so as to not expose the enum and all controls), you can easily just search for that particular VI in your code. I was under the impression you could not do this with a polymorphic VI?