Leaderboard

We'll be going through a major site upgrade this weekend. It will start Saturday night and should only last a few hours. It's a very exciting upgrade and will give the site some cool features. You can read about them here. One of the key improvements is search. We'll have to see how that works in practice but anything is better than what we have now I guess.

After a decade of programming LabVIEW, I have to admit I still get bitten by stupid mistakes. Today's mistake is one I'd like to share because it's so simple and yet, I had to take a long lunch break to clear my head before I finally nailed it. In the pic above, I simply give the user a list of available ports and lines for a selected DAQmx device. The user selects one or multiple lines and I pass it down to create a task. And this is the solution: Using the Array to spreadsheet primitive adds a end of line at the end, which was carried an couldn't be filtered later down the road by DAQmx "Create Virtual Channel.vi". I hope to save you some pain by sharing my misfortune!

Or simply use the OpenG 1D Array to String VI, which I believe works around this issue.

I would also check to see that the machine is not using any compression and/or encryption on the hard drive. /J

How does the application behave in safe mode? How much "junk" is running in the background that isn't mission-critical?

I had this same problem and was never able to figure it out. It was like the computer had a vendetta against any exe built using LabVIEW. Only happened on a few computers and the only way to fix was to rebuild the computer from scratch. I questioned our corporate antivirus filters, but was unsuccessful at figuring out where the problem lays. The frustrating thing was that these were exe's that I had used for a long time and now all of the sudden are loading very slow on particular computers but all other applications worked fine. Maybe because it isn't an approved application? Hope you find your answer because I'd like to know too. Bruce

Moreover, do you have a fair bit of code which runs before the user will see any UI? If so, throwing some logging around and see if you can pin-point what's hanging up.

Hi Wim, 1 GHz doesn't sound like that much nowadays. When are the plugins loaded? Can they be the cause of the long load time? Have you tried disconnecting any network peripheral? (or connecting to any) Is the swap file being used during the starup of your application? Ton

To be clear: the upcast coercion dot has no effect at runtime. It is not the same type of performance penalty that the coercion dot from int to double represents. We've talked about wanting two different coercion dots, but that's hard to provide since red appears to be the only color that most people can see in that small a space and there's no way to put a different pattern when you only have 6 pixels. So all the coercion dots look the same. Typedef to not-typedef-but-still-same-type (and vice versa) is another coercion that has no runtime performance penalty.

Initially we did it because we followed the same rules as VI Server, which does show coercion dots for the hierarchy of control refnums (wire a Knob refnum wire to a Control Refnum terminal and you'll get a coercion dot). Later we figured out that it helped you recognize whether or not automatic downcasting was operating or not. But I'm still in the camp that wishes we had different colors of coercion dots for different cases.