LabVIEW
Labview 2011, Is this the buggiest Version ever?
Roger,
The build problem that I am experiencing is not source control related.
Even Disconnected from SC, it still won't build an rtexe that will run on the target.
Below is a taste of some different wire patterns and my "thread" base class methods, create, register, run initialise destroy, I use this sort of pattern extensively.
You can also see a ancestor class calls with different headers.
I looked at my heirachy and found I had added glyphs to about 25% of my classes, So, I am a bit lazy as well.
I guess I have been adding them to important classes and base dynamic functions
Looks like slick LVOOP code to me. 
Are you _sure_ it does not run on the RT? Crashes or just takes a long, long time to start?
Have a good looooong look in the CPU/memory load of the target in the "Distributed System Manager"?
As long as LVRT is loading up on the target the memory and CPU will be changing a lot and with such a large class hierarchy it could take a few minutes(!) for everything to get up and running from the rtexe, specially on the relatively slow c/sbRIO's.
Also, if the problems are path-based lookups of classes and methods, I use the following pattern(s) (red arrow indicates base class method:
or:
Seems to work for me "most" of the time since building (rt)exe's makes all path references go haywire, so it is better to let LV help me out find the correct paths. Maybe this is what you already have? "just sayin". 
Br,
/Roger
I have a 5 minute start time on my rtexe's for crio/cfp.
(If you have any cool ways to combat this I am all ears!)
This problem manifested itself on a PXI and went away when I unchecked the seperate code checkbox.
I had similar symptoms with NP shared variables attached to arrays and/or typedefs (Has been in known issues list for 12 months now). I suspect that these two bugs may be intimately linked.
Don't use path based lookups like yours, I haven't been able to figure out how to get them into an .exe without immense pain so I have avoided them like the plague.
Have been using For loops with iteration parallelism to run an unknown number of threads.
Is a bit buggy though, if you don't pre-configure the loop with a figure greater than you max number of threads it won't run them concurrently.
(Loop vi's are re-entrant!)
@Timmar wrote:
I have a 5 minute start time on my rtexe's for crio/cfp.
(If you have any cool ways to combat this I am all ears!)
This problem manifested itself on a PXI and went away when I unchecked the seperate code checkbox.
I had similar symptoms with NP shared variables attached to arrays and/or typedefs (Has been in known issues list for 12 months now). I suspect that these two bugs may be intimately linked.
Don't use path based lookups like yours, I haven't been able to figure out how to get them into an .exe without immense pain so I have avoided them like the plague.
Have been using For loops with iteration parallelism to run an unknown number of threads.
Is a bit buggy though, if you don't pre-configure the loop with a figure greater than you max number of threads it won't run them concurrently.
(Loop vi's are re-entrant!)
Aah, been there done that I suppose.. 🙂
Path based lookups are the way to go for some specific cases where dependencies cause headache (xcontrols, etc..). Otherwise, I agree that they should be avoided.
Makes me wonder why NI don't provide some usable middleware LVOOP frameworks instead of every "Joe LVOopCoder" have to create their own?
Yeah, iteration parallelism didnt work on my sbRIO the last time I checked, so I dropped those.
For example, running 2 threads with different overridden method(s) for doing some fun string stuff.
Performance seem not to be a hot topic for the NI LV team these days?
Slow compiler, slow execution, slow when building exes, etc..
Ironic that NI is focused on pushing test systems as one of their main topics, but fail to do that on their own stuff?
Br,
/Roger
