Tips and best practices for translating C into LabVIEW? SERIOUS newbie...

[F._Schubert]

This won't help the original poster at all, it's just for grumpy old men splitting hairs.

I did some digging on LAVA, so I can quote AQ from NI R&D:

It's found in this thread about by-ref LVOOP using DVR's in post 3.

What you are asking for is not possible, at all, in a dataflow language. A raw pointer to data on a parallel by-value wire cannot be constructed meaningfully. Ever. That would completely destabilize LabVIEW's parallel architecture. The whole point of a data flow wire is that *nothing* other than the upstream primitive that created the value can modify that value. Nothing. If you have raw pointer access to the data on a parallel branch, you will almost always create wholly unpredictable behavior or a crash, with the crash being highly likely.

[..]

We fully support references. We do not support pointers at all. But you don't refer to a piece of the block diagram. You refer to an address in memory. That other, parallel wire, does not refer to that piece of memory. It refers to its own piece of memory.

Felix

[SynergyMike]

Maybe I should have started a new thread, but here goes...

Ok, I'm totally lost now.  Locals are bad and property nodes are worse, so wires are the way to go.  My only trouble is that I'm trying to re-write some large VIs that make extensive use of both locals and property nodes, with maybe 50-100 values to keep track of (e.g., alternately written to and read from at any given time and in an order determined in part by operator actions and in part by data from external devices).  Since using property nodes let me move a lot of code into sub-VIs, I was in the process of converting all the locals into property nodes instead - apparently this was a mistake.

I've also read that excessive clustering produces a big performance hit too, but the VI connector pane should be limited to a certain number of connections to keep things readable.  Am I really going to want 50-60 shift registers and a whole raft of sub-VIs then?  Is there one way to provide the least memory overhead (the PCs we have here are all single core processor, minimal memory boxes), or should I just strive for some sort of compromise?

Regards,

Michael Tracy

Synergy Microwave

[F._Schubert]

Use Clusters. Make them Type Def's.

For performance, minimize overlapping controls from the clusters and don't nest them to deep. I've seen the performance penalty on older PC's (about 10 years old, Win 2k), you see it while editing, not while running. Don't put arrays in the clusters that need to be resized frequently.

Group logical. For 50-100 you might get done with two layers only (So inside the big cluster there are several clusters with meaningful names). 

Felix

[tst]

The main issue with locals or Value properties is rarely performance. Unless you're reading huge amounts of data, this is less likely to bother you.

The big problem with them is the potential for race conditions, although in the context of this thread the big problem is that they are "like" something that you have in C, but in practice they're different in some important points, which is why I was strongly advising them in this case. When you have something that looks familiar, you grab onto it, even if it's completely wrong for you.

I would say that in your case, if the code works and you don't want to do a complete rewrite, you could theoretically use the method you describe, but keep in mind that you run into the danger of having race conditions. There are other ways of making data globally accessible, such as global variabes, LV2 globals, GOOP, etc., but it's impossible to say what would be relevant to you.

As for the cluster, It's the same deal as the first paragraph. Unless you have a huge number of elements in the cluster (or a lot of data), you should feel free to use clusters. Just make sure to make them a typedef.