NI smartcams + VBAI provide a really neat and fast way to get results in image processing - however, predicting their performance is close to impossible. Information like "DSP coprocessor" is nice, but it's not adding any information that I can use.

I have benchmarked the devices that went through my hands with some standard resolutions+ROIs and algorithms, so I have some idea, but most of the time I just wonder "Would this work on a 1774?" "Would it work on something slower?" I usually call an engineer and try a loan device, but this takes time and rather static concepts.

I know that algorithm runtimes (especially the more complex ones) strongly depend on the sample data, so it's not just a matter of scaling, but even an estimate (like 8-12ms) would improve my experience rapid prototyping.So, I'd just use Profile->Performance Meter -> Profile for NI 1772..
 

For large projects it becomes cumbersome to set VI properties individually for each VI. I know there are few scripting methods available to do this. But in general it would be good to set the desired VI execution properties in "Environment" options available under "Tools --> Options" menu.

Thanks

Amit Karia

Life can be a real beach when working on a load of high-performance VIs which have a bug somewhere.  First spend half an hour un-setting "Subroutine" on a tree of VIs, then find the bug, spend another half an hour re-enabling sub-routine execution and then spend a further half an hour finding the last subVI you forgot because you've noticed a problem when benchmarking......

How about setting a VI to conditional subrouting meaning that it retains its subroutine status until you place a probe or breakpoint in it  (It would be nice if calling VIs adapted also of course).  As soon as the breakpoint / probe are removed, return as normal to subroutine execution.  Man would this save a lot of time.

Shane.

Hello!

I hold many different revisions of my projects on my PC, and am not currently using Perforce or any other source control.  As the mass compile tool stands now, if I were to mass compile a directory which contained the latest version of my project, it would search through all of the files on my hard drive and link or relink VIs to the first version of files that it finds.  My project would basically link some Vis correctly and to old or outdated versions of VIs or DLLs in some cases. 

I would like to suggest that the mass compile feature in LabVIEW allow the user to specify the folder or hard drive location where the desired source should be located.  Currently we're only able to point towards the directory where the broken links exist.  It would also be nice to have a checkbox feature to include the subdirectories below the top level desired source directory.

Cheers!

Shawn S.

I find that my code window quickly becomes filled up with comments and notes.  Could we, maybe, have a small comment icon, which we can put in the code and which displays the comment when you hover your mouse pointer over it? 

  My present workaround is to put larger comments in the documentation window and number them, so that I just have to put a reference number in the code.  Maybe these two documentation devices could be dynamically linked together somehow.