Cluster reference in subvi

[salikatt]

I have several clusters on the main vi that holds user settings for charts (i.e target value, upper/lower limit etc). I have created references to each cluster. I will use this references in a sub vi that will write currect settings to a INI file by using the OpenG.

The method I have been used is to link the cluster reference to subvi as a refnum, then property node to get the cluster values that is written to the INI file.

I find this a bit difficult, especially to keep control of which clusters referred to wich refnum. Anybody know a better way of doing this?

Thanks!

[jgcode]

If you are only writing the value of the cluster to the .ini why not just pass by wire so you can follow you code using dataflow?

Or is there some particular reason to use references/property nodes?

[salikatt]

QUOTE (jgcode @ May 27 2008, 02:06 PM)

If you are only writing the value of the cluster to the .ini why not just pass by wire so you can follow you code using dataflow?

Or is there some particular reason to use references/property nodes?

It's jsut the way the clusters are arranged on the block diagram. It's going to be a lot of wires around. But I guess it's better than the other solution with reference/propoerty nodes then.

[Justin Goeres]

QUOTE (salikatt @ May 27 2008, 12:57 PM)

It's jsut the way the clusters are arranged on the block diagram. It's going to be a lot of wires around. But I guess it's better than the other solution with reference/propoerty nodes then.

Generally speaking, using Property Nodes & References just to avoid block diagram clutter is a seductive, but wrong approach. It seems like a great idea, but as jgcode pointed out, it means taking a shortcut around dataflow. That can lead to really, really hard-to-find bugs in your code later on. For small, single developer projects you can probably get away with it, but it's better to just use good practices from the outset so you don't have to worry about how it scales later on.

As for the more general problem of block diagram clutter, there are various ways to deal with that, including functional globals, decoupling of controls/indicators from the data they contain, by-reference and/or by-value objects, etc.

[salikatt]

QUOTE (Justin Goeres @ May 27 2008, 09:26 PM)

Generally speaking, using Property Nodes & References just to avoid block diagram clutter is a seductive, but wrong approach. It seems like a great idea, but as jgcode pointed out, it means taking a shortcut around dataflow. That can lead to really, really hard-to-find bugs in your code later on. For small, single developer projects you can probably get away with it, but it's better to just use good practices from the outset so you don't have to worry about how it scales later on.

As for the more general problem of block diagram clutter, there are various ways to deal with that, including functional globals, decoupling of controls/indicators from the data they contain, by-reference and/or by-value objects, etc.

Ok, I'll stick to the recommended method. Thanks!

[Neville D]

Coming to this a bit late, but there is also the issue of speed. Using property nodes instead of wires is the slowest approach.

Wires (best speed) < Locals < Property Nodes (worst speed)

Neville.