Is there a limit to how large a VI can be?

[TMC-RickP]

That was my first thought.  I get an error that says there is only 28 connector panes allowed and I have many more than that and LabVIEW cannot create a SubVI.

[10Things_Rob]

Rick,

You need to bundle your wires into clusters. That will help a lot on this problem and readability as well.

-- Rob

[Ben]

function(){return A.apply(null,[this].concat($A(arguments)))}

Alabama-RickP wrote:

That was my first thought.  I get an error that says there is only 28 connector panes allowed and I have many more than that and LabVIEW cannot create a SubVI.

I posted a pitctorial solution in this thread

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=490461#M490461

It handles that challenge.

Ben

this is a preview of what you would find if you looked at the link I posted.

[TMC-RickP]

I will need to bundle 11 controls of different types for 38 machines that use these 11 controls.  I will still need more than 28 connector panes.

[TMC-RickP]

Ok Ben,

I am still trying to grasp and swallow the Action Engine concept.  It is kinda moving slowly for me.  Thanks and it sounds like this is the solution when I can get it into my head.

[Elijah_K]

Here's an example of how I manage the references in an application with a complex user interface.  For the sake of staying organized, I use a sequence structure (strictly for the sake of organization) and I group UI elements and bundle them into a strictly type-def'd cluster.  The cluster on the far right is just a strict type def that contains the smaller strict type defs.  In my opinion, this makes it easier to add / edit / update the controls while minimizing changes to my application.

Note: I have intentionally hidden part of the diagram, but scrolling is only required in one direction (as recommended by the NI Style Guideline)

[Evan R.]

I've often used this solution as well. I bundle my control references into a cluster and pass the cluster around.

I am curious about this however:

What are the performance and/or memory trade-offs of doing so? Do they outweigh the aforementioned and agreed upon benefits of scalability, modularity and maintainability (not to mention readability...)? For me I think the answer is often yes, but at what point does passing around these huge clusters cause you performance penalties.

Thanks,

Evan

[LuI]

EvanR. schrieb:

What are the performance and/or memory trade-offs of doing so? Do they outweigh the aforementioned and agreed upon benefits of scalability, modularity and maintainability (not to mention readability...)? For me I think the answer is often yes, but at what point does passing around these huge clusters cause you performance penalties.

Evan,

again, do yourself the favour to type-def your clusters for easier maintenance.

And, to answer your Q:

Performance and/or memory usage is - when passing data - tightly connected. And memory size of clusters is not that much larger that the sum of all the clusters components. Type definition increases, but this is probably 'centrally' stored so does not consume much RAM. Take a look alt LabVIEWs documentation relatede data structures and representation.

The data itself can consume much more memory when it comes to strings or arrays, so you might prefer integer and/or simple values.

And to provide numbers: contemporary PCs have data transfer rates CPU <-> RAM of ~5GB/s, so some Bytes or kB cost you µs's...

Greetings from Germany!

--

LuI

[Ben]

EvanR. wrote:

I've often used this solution as well. I bundle my control references into a cluster and pass the cluster around.

I am curious about this however:

What are the performance and/or memory trade-offs of doing so? Do they outweigh the aforementioned and agreed upon benefits of scalability, modularity and maintainability (not to mention readability...)? For me I think the answer is often yes, but at what point does passing around these huge clusters cause you performance penalties.

Thanks,

Evan

Performance memory

If implemented as I have shown, the refs sit in the SR of the AE and are read from there. No hits.

Scalablilty, modularity, maintainablity, readability.

Again as I illustrated,

scalablilty -  type def hadle that

Modularity - GUI stuff is seldom re-usable (beyond XControls and trial tricks). THe sub-VI sued to set the screen settings can be re-used by calling the same method.

Maintainablity - Dirt simple since everything is organized. The check for control ref validity serves as a sanity check and tells me as soon as I start teh app that I forgot to wire that new control ref.

Readablility - It's LabVIEW, what else do I have to say?

Ben