Steen Schmidt

Hi. On a desktop PC I can get the file version or build number of a DLL or EXE by using the Win32 API in LabVIEW for instance. Has anybody got a clue to how I can do this on LabVIEW RT? I'm using LabVIEW RT on both PharLab and VxWorks targets, so additional applause is given for solutions that work in both cases. And I'm not talking about getting a built VI's revision number through its history node - these are general non-LabVIEW DLL and EXE-files (a Simulink model built into a DLL with Realtime Workshop for instance). Cheers, Steen

QUOTE (Aristos Queue @ Mar 21 2009, 11:04 PM) I haven't checked since 8.5.1, but I hope NI is abandoning the current PW scheme, since it's fairly shot through with the newly exposed MD5 vulnerabilities. Cheers, Steen

QUOTE (Neville D @ Apr 1 2009, 10:24 PM) 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) 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