Leaderboard

There's more than what is listed, but I'm going to say the ones that pop off the brain at first thought. This might be useful just in simply being accountable for them ... if they're acknowledged, I might be forced to make more effort to do it the right way. A list of my bad LabVIEW habits that would behoove me to fix: 1. Maximizing screens 2. Compulsive saving (esp ctrl+shift+s) 3. Not using autotool 4. When encountering a bug that I can't figure out, I sometimes resort to hack & check style. i.e., change something, run it, repeat 5000 times. 5. Not taking the time to build my own toolbox. i.e., cleaning up and generalizing modules that worked well, and putting them into the palette. Extra notes: 1. This is going to be difficult for me to change. I wish I could spend some time watching some experts develop, because I find myself spending too much time putting the mouse to the scroll bars to go where I want in the VI when not maximizing. The best developers seem to all use non-maximized screens, so I'm thinking there must be something that I'm missing. I develop slower when I'm using non-maximized screens. But I see the rather huge incremental benefit for not maximizing, I'm just not doing something correctly. I'm currently not maximizing in any case where it isn't clearly warranted, but it continues to be painful, and I don't see a light at the end of the tunnel. 2. My first impulse when I do something that I fancy is brilliant is to save everything (Don't lose that thought!!!). I certainly don't need to tell YOU folks how erroneous this is. I'm a fairly compulsive SCC checker-inner as well, largely because of this--I use SCC to revert changes that I didn't like. 3. I've been suffering through using it for the past few weeks, still not completely taken with it. I think this was in a Coen movie ... "I'm a tab man, damnit!" I'm very close to just switching back to not using autotool at all. I don't feel like I'm losing time by hitting tab and spacebar many times to do what I want. My main problem with the autotool is getting the cursor/tool for selection, sometimes it's only a couple pixels wide, and selection point is in a spot I wasn't expecting. 4. This relates to the fact that sometimes the best thing I can do when I have a real brain-stomper, either a bug or just a difficult algorithm, is to get away from the computer and take a walk, or perhaps just sit down with a scratch pad and pen (is it strange for an engineer to dislike pencils?). 5. These are modules that aren't candidates for openG, but are at least clean and reusable enough that I could save time on new projects. General: -Most of these are actually not particular to LV, but I use that far more than any other language. -I wonder if particular bad habits are more or less common in people who are self-taught in coding vs those who had either more uni training, or simply working with superior SW architects? -I also realize that there's been reams of books and thoughts on these concepts, but sometimes just writing it out yourself is a better route than reading tech blogs in the pursuit of improving your own habits. And in fact, the latter can be an addictive experience, and can lead to days where you started out with a task in mind and ended up "waking" at 11 am and realizing, jeez, I haven't done anything! With that recursive irony in mind, an article that I actually dogfooded was Graham's artice on removing distractions, particularly cutting your dev machine off from the internet: http://www.paulgraham.com/distraction.html ~~~~~~~~~~~~ Any bad habits you'd like to acknowledge?

Calling all CLA! Head on over to the CLA Summit 2011 Page and give your comments please. {EDITORS NOTE}:: It's in a private group so you must join first here CLA Summit 2010 was a huge success and this years will be better yet. Comments like "It was worth the airfare" which came from a CLA from Italy should convince you to not only attend but also shape the content and format. So once again http://decibel.ni.com/content/projects/cla-summit-march-2011/blog/2010/11/17/time-to-plan-for-cla-summit#comments See you all soon Norm Kirchner Sr RF Systems Engineer National Instruments ~,~ CLA, CTA, CPI, Defrock'd LV Champion General RF Nuisance

Name: Icon Editor API Submitter: jgcode Submitted: 25 Jan 2011 File Updated: 29 Jan 2011 Category: *Uncertified* LabVIEW Version: 2009 License Type: BSD (Most common) Icon Editor API Repack Extended. The original Icon Editor API has been recompiled to User.lib. This code makes calls to v.i's/.ctl's in the Icon Editor plugin directory which is not of a symbolic path. This may lead to linking issues and therefore the API was extended to accommondate this. The Icon Editor API has been extended to provide additional functions such as Class Library Refnum wrappers, Global Stores and helper VIs. See http://decibel.ni.co...t/docs/DOC-8647 for the source code of the Icon Editor API. Code snapshot taken as of 15/05/10. Note: This original Icon Editor API code be updated by NI in the future. The password for the Extended Icon Editor API Library is "jgcode". Click here to download this file

Yes, it's here. Thanks for the reminder to cross-post.

I am pleased to announce that the next two videos for the FRC 2011 season are now up on FRCMastery.com These are steps 3 and 4 in the The Seven Steps to FRC Robotics Success that Enable Training and Consulting Inc. has put together this year. Again, you can find these in the dropdown menu at the top of the page to LabVIEW for FRC – the same place steps 1 and 2 are posted. There’s a link to the 2011 videos there. In Step 3 we will: · Add a servo motor to the robot · Initialize the new servo motor by modifying Begin SubVI · Modify the Teleop SubVI to use the joystick to move the new servo motor · Modify the Finish SubVI to close the reference of the new servo motor In Step 4 we will: · Add a new digital input as a limit switch · Initialize the new Digital Input by modifying Begin SubVI · Close the reference of the new Digital Input by modifying the Finish SubVI · Modify the Teleop SubVI to replace the momentary joystick button with a limit switch Ben Zimmer -- LV Mastery Team

I am happy to announce a new round of videos for the FRC 2011 season. This year, Enable Training and Consulting Inc. has put together something we call The Seven Steps to FRC Robotics Success The first two videos are now up at FRCMastery.com with more to follow soon. See the dropdown menu at the top of the page to LabVIEW for FRC. There’s a link to the 2011 videos there. In Step 1 we will: · Start a new FRC LabVIEW robot project · Get familiar with FRC cRIO robot program structure · Deploy code to the cRIO · Explore the FRC Driver Station In Step 2 we will: · Add a joystick button to momentarily stop drive motors by modifying Teleop SubVI · Examine the LabVIEW Case Structure Plus, all of our material from the 2010 season is still available.