Steen Schmidt

QUOTE (Neville D @ Apr 1 2009, 10:24 PM)

That being said, if you describe your problem, there might be other ways to debug your code.. tracking state transitions by logging to file, looking at the front panels of VI's or subVI's one level down, running on your RT code etc. You could even do what I did, have a version of the code running on windows and debug your re-entrant VI's there.

Neville.

Hi Neville.

I am debugging my code in the ways you suggest, so I'm getting the results I need - I'm just saying that it's extremely cumbersome compared to desktop applications, and I wish I could debug reentrant VIs on RT directly. This's probably just one of those things that'll never see an improvement.

Cheers,

Steen

QUOTE (Neville D @ Apr 1 2009, 08:12 PM)

You can run or application (not executable) currently on RT and you can open front panels and BD's of re-entrant VI's with no problem..

It is a bit slower since it has to download all the VI's but it still works.

N.

That you must explain to me please - I've had many NI people here in Denmark crunching it over, and they say it can't be done. How do you open the BD of a clone running on LabVIEW RT and put a probe on it? The last two years I've worked almost exclusively on LabVIEW RT on very large simulation projects, and I'd be delighted if I've somehow missed this.

Cheers,

Steen

Hi.

How about debugging of reentrant VIs on LabVIEW RT (Real Time)? I often need that, or, as a temporary workaround, the ability to specify the target on which to open a VIs front panel on. The latter would entail that reentrant VIs should maintain a copy of their front panels, even on RT, and that this front panel could be spawned on a remote Host, and then connected to the block diagram of the reentrant Vi on the RT target.

Cheers,

Steen

Hi.

Since so much focus is on multicore and parallelism today, isn't it time for a true parallel For-loop structure? I know the compiler reputedly has some capability for unrolling unrelated cycles in a For-loop, but I still haven't seen any real-life cases of tangible performance gains from this. I often encounter For-loops with a dynamic number of cycles, but where each cycle is unrelated to the others (initialization of N instruments for instance, where N is only known at runtime). I'd like to see an option in the context menu of a For-loop saying something like "Run in parallel if possible". This would defeat shift register capability of course, among other things. The compiler obviously already has the ability to determine cycle-to-cycle relations.

Cheers,

Steen

I actually logged in to post a few suggestions or wishes, and this was exactly one of them. I really wish we had the option to show clusters as (descriptive) icons instead of controls or indicators. You can already do this with refnum controls for instance. It would be faster (performance-wise) and easier than the workarounds suggested above.

Cheers,

Steen