Leaderboard

NI is uploading projects to GitHUB, so the LV community can help out in development. The GOOP Development Suite will be one of the first projects they will try out. I hope many of you will help NI, to make this product better. http://vishots.com/category/live/ http://youtu.be/abXD7M7-Y1Q

"Labview is packed with wonderful pieces at the cutting edge of fashion with an emphasis on collections by young up-and-coming designers, who are very much in vogue." -- https://cityguide.b-europe.com/en/lyon/shopping/labview-p-107snc220 (Photo was taken by someone from CERN.) And, it's funny that the shop next door sounds like LAVA'erie And, I've updated my outdated avatar to a newer pic from the CLA Summit 2013 in Paris, France -- seemed fitting

Hi, I posted this question in OOP forum, but may be the right place is here... Have you experienced that LV takes very long time to build executables when you use a certain number of classes? I have noticed that when my app uses many classes (e.g. 30 classes) LabVIEW IDE slows down ("busy pointer" appears very often during VI editing) and compiling executables takes more than half an hour. It's not due to my machine because larger projects are built in less time if they don't contain so many classes. Are there properties that can speed up the build?

The Draw Flattened Pixmap doesn't accept an array or output an array. If want more information about a function open the context help by pressing CTRL + H, or clicking on the help button then mousing over the function. From here you can click Detailed Help for even more information.

Try this: ModifyImage.vi Cheers, Mike

I came across another way of slow down a few years back. I inherited a machine control application that consisted of one main VI going over 10MB size, and a whole bunch of subVIs doing stupidly little. The main VI consisted of several stacked sequence structures with up to 100 frames and almost every frame contained a case structure that was only enabled based on a global string that contained in fact the next state to execute. Basically it was a state machine with the sequence frames consisting a grouping of states and to get to one particular stage LabVIEW had to run through each sequence frame, most of them doing nothing since the case structure inside did not react on the current state. Talk about a state machine turned inside out and upside down and then again some. Selecting a wire, node or subVI in that diagram was slooooooooooow, as each of these actions caused a several seconds delay. Moving a node was equally slow as each move caused a similar delay. It was a total pain to do anything on that application and it needed work as it had several bugs. I invested several days restructuring the architecture into a real state machine design and placing several logical sub state-machines into their own subVI, also removing about 99% of the several 1000 globals and once I had done that, the whole editing got snappy again. The main VI had been reduced to about 1MB and the different sub statemachine VIs together took mabye another 4MB of disk space. Replacing all the globals with a few shift registers had slashed the disk print of the VIs almost to half. I did make the driver VIs a bit smarter by moving some of the logic into them instead of copying the same operation repeatedly in the main VI but getting rid of the enormous number of sequence frames as well as the many globals that were mostly only a workaround for the not existing shift registers did both get the disk size down a lot as well as make the editing again a useful operation instead of being simply an annoyance. Surprisingly enough the runtime performance of the original application wasn't really bad, but the redesigned system hardly got ever over 5% CPU usage even when it was busy controlling all the serial devices and motion systems. How the original programmer ever was able to finish his system with such an architecture and the horrible edit delays for almost every single mouse move I can't imagine. It for sure wasn't a LabVIEW programmer and I later learned that he had only done Visual Basic applications before.

My observation is that when there are many classes in a project, LV IDE shows the busy cursor as well as the compilation time increases, much more than in projects that have the same number (or higher) of VIs, but without classes. My supposition is that OOP has been innested in LV recently, and LV IDE manifests a different behaviour when we use OOP. What is your opinion about it?

This post has been promoted to an article

This has become common place in my larger application which also uses classes extensively. I'm not sure if it's the actual use of classes, or the proliferation of VIs as you start to get a bunch of read/write accessors, or perhaps the dependency trees that get mapped out between the various classes. Regardless, any simple edit of a VI is followed by 1 second or so of "busy" cursor during which the IDE locks up for recompiling etc. I've been dealing with this so long I hardly notice anymore, editing VIs just has a built in cadence where I make a change, wait, make a change, wait... Build times for this application used to take about 45 minutes, but now that 2011 SP1 hit it managed to get down to 15 min or so. I have not noticed a large change in the "wait" duration from SP1 though.

Hi All, i realized this fast example that enable LabVIEW to view\controll Google maps Enjoy Ciao,