Subpanels and clusters?

[JPrevost]

So here I am still streamlining my program to be smaller and easier to modify. First question should be easy; do clusters effect the performance of a program? Example; Passing multiple wires into a case structure vs. putting them in a cluster and while in the case, unbundle by name to an indicator?

Second question, subpanels. When is it a good idea to use them. My program has an area that displays boolean data as FP LEDs and they only get written too. Would it benifit me in any way to make a seperate VI for them, use a cluster, and call the VI into a subpanel? I wish I knew more about how certain things effect program performance.

Third question; When using OpenG vi's, after compiling with LabView's application builder, do the users have to do a full install or can they just copy the new exe into the program directory? Or do I have to do more? I ask because I'm using the extension replace vi to change the .exe to .cfg for user config data to be saved but during builds, the more I use OpenG the more beta testers complain of broken features

[didierj]

So here I am still streamlining my program to be smaller and easier to modify. First question should be easy; do clusters effect the performance of a program? Example; Passing multiple wires into a case structure vs. putting them in a cluster and while in the case, unbundle by name to an indicator?

I wouldn't recommend this. Use bundle/unbundle more in the case when you want to pass data to a sub-vi and its connector pane would get overcrowded.

Second question, subpanels. When is it a good idea to use them. My program has an area that displays boolean data as FP LEDs and they only get written too. Would it benifit me in any way to make a seperate VI for them, use a cluster, and call the VI into a subpanel? I wish I knew more about how certain things effect program performance.

I use sub-panels, usually as a sort of tab-replacement, e.g. when you have a program that can perform different tasks but only one task is used at a time.

Third question; When using OpenG vi's, after compiling with LabView's application builder, do the users have to do a full install or can they just copy the new exe into the program directory? Or do I have to do more? I ask because I'm using the extension replace vi to change the .exe to .cfg for user config data to be saved but during builds, the more I use OpenG the more beta testers complain of broken features

OpenG is a set of vi's (mostly) written in pure G. So every beta-tester who tests your code in the LV development-environment needs the openG toolkit. In built exe it is no issue. The vi's are compiled into the exe like every other sub-vi. Regarding the licensing, Jim could you enlighten us?

[JPrevost]

Thanks. I guess I'm running into something else as my problem, not the OpenG VI's. Apparently the paths get all screwed up when dealing with vi's vs compiled exe's. I was changing the extension from .vi to .cfg for the config file but it wasn't working with .exe, oh well, this is going to waste my time figuring it out .

As for the subpanels, this is where I would bundle the many (20+) boolean data and send it to the vi that's embedded in a subpanel. From your reply, it sounds like bundling anything into clusters does do a hit on the performance... so I'll avoid it. Now the question goes back to the seperate vi for config data. How else is one suposed to send a LOT and read frequently from a seperate vi if not for clusters. It almost makes me wonder if I shouldn't stick to keeping the user configurables built into the main vi for faster recall.

[orko]

As for the subpanels, this is where I would bundle the many (20+) boolean data and send it to the vi that's embedded in a subpanel. From your reply, it sounds like bundling anything into clusters does do a hit on the performance... so I'll avoid it.

I wouldn't write off clusters so soon, since it sounds like your alternative is to wire 20+ boolean controls to a subVI? I'm fairly certain that would fall under the category of "overcrowded"

I don't believe that bundling would cause very much if any performance hit on your application, and would save tremendously on portability and maintainability of the code in later projects. Can you imagine dropping this subVI into a new VI and wiring each input up individually? Whereas with a cluster it's as easy as "create control" and you get all of the controls you need inside the cluster already labeled and GTG.

Now if you were passing along large sets of data, clustering probably wouldn't be the way to go.

HTH,

Joe (orko)

[didierj]

I wouldn't write off clusters so soon, since it sounds like your alternative is to wire 20+ boolean controls to a subVI? I'm fairly certain that would fall under the category of "overcrowded"

... Following.

From your first post I understood that you wanted to bundle/unbundle just to pass data into a case structure. But passing 20+ Elements to a sub-vi I would definitely also use bundling.

Regarding the paths: did you consider that in an exe the LV-path is of sort: <base-path>\<exe-name>.exe\<vi-name>.vi

[JPrevost]

<-- dealing with 200+ items that are used by the user to help control the system (engine fuel/spark controller).

Passing data comes from reading in a bunch of bytes from the serial buffer and then parsing out the bytes to subvi's that do the conversion work. Some bytes are broken down into bits and this is where the wires start to get crazy. I have over 170 bits that will eventually be passed on to the user in some form or another. Currently I'm working with about 100 and the wires are getting a bit out of hand. Some of the flags aren't used for anything special and so they are broken out of the byte array (full data packet) within the case structure making it easier but some of the bits are used for things like autotuning meaning its status needs to be read outside of the case. This is where it gets nasty. Wires going everywhere. Bundling them into a cluster would help. These are only boolean so from the sounds of it, the performance hit shouldn't even be measurable...

[Mike Ashe]

Is there some reason why you cannot use an array for so many items of the same type? With that many I just have to suspect that you could squeeze out some more program efficiency as well as wiring / coding style efficiency using arrays.

[JPrevost]

Is there some reason why you cannot use an array for so many items of the same type? With that many I just have to suspect that you could squeeze out some more program efficiency as well as wiring / coding style efficiency using arrays.

You mean, after I parse the data down into bits I should build them into a new array, pass that into the case structure and pull out only what I need that way? That could work except that every time I add something that is imbetween (indexed all over the place) I would need to rewire everything . If it's faster I'll do it. I'm just trying to make the program maintanable at this point and will be adding to it in the future as updates to the hardware get released.

What do you think about the subpanel. Is it bad practice to use sub panels if you only plan on loading 1 vi?