How to get your team members aster LV developers

[MikaelH]

We all know that Quick Drop is a good tool to make you faster, and in combination with shortcuts, you’ll be even faster.

 

To get all LV developer in my team to use the same shortcuts, I push the same shortcuts to everyone, but how do you remember all the different shortcuts?

To solve that I made a small Quick Drop Practice application, feel free to play and modify it so it suites you.

And if you have time to improve it, upload your version :-)

 

How it works:

It reads your current QD BD Shortcuts, and adds them to an array.

It then opens an empty VI BD and asks you to drop a VI (e.g. Build Array), on the BD.

If you haven’t figured out the shortcut within 5 seconds, it shows the shortcut so you can memorize it.

After it find the right VI on the BD, it deletes it and moves to the next shortcut.

 

Have fun.

QD-Practice.viFetching info...

[Ulf]

  On 5/1/2013 at 10:54 PM, MikaelH said:

We all know that Quick Drop is a good tool to make you faster, and in combination with shortcuts, you’ll be even faster.

 

To get all LV developer in my team to use the same shortcuts, I push the same shortcuts to everyone, but how do you remember all the different shortcuts?

To solve that I made a small Quick Drop Practice application, feel free to play and modify it so it suites you.

And if you have time to improve it, upload your version :-)

 

How it works:

It reads your current QD BD Shortcuts, and adds them to an array.

It then opens an empty VI BD and asks you to drop a VI (e.g. Build Array), on the BD.

If you haven’t figured out the shortcut within 5 seconds, it shows the shortcut so you can memorize it.

After it find the right VI on the BD, it deletes it and moves to the next shortcut.

 

Have fun.

QDpractice.png

QD-Practice.vi

You have too much time(or quick tools) Mikael...

[MikaelH]

  On 5/2/2013 at 5:20 AM, Ulf said:

You have too much time(or quick tools) Mikael...

My job is to make sure my team works faster and more efficient, and also have more fun, I just need to add some high scores as well then we can have a competition :-)

[hooovahh]

  On 5/2/2013 at 6:11 AM, MikaelH said:

My job is to make sure my team works faster and more efficient, and also have more fun, I just need to add some high scores as well then we can have a competition :-)

Very neat.  How do you distribute the quick drop shortcuts to your team?  I've been using VIPM, I wasn't sure if there was anything else people use.

[MikaelH]

I use SVN :-)

It's so easy.

We have a shared LabVIEW 2012 repository, that all the companies LV computer check out into their LV 2012 folder.

TortortoiseSVN will of course complain that there are files in the folder, but that's fine.

 

In this repository I've not added all files under the LabVIEW folder, but most stuff under user.lib (where we have the companies common VIs, and of course OpenG) and instr.lib (where we all the shared instrument drivers, more than 100 lvclasses)

But I've also checked in all RCF files needed, the QD plugins and of course GOOP Development Suite.

 

To update the LabVIEW.ini file with QD shortcuts, we have a VI in the repository that updates the shortcut so everyone gets the same.

 

I found this way easier than vipm, to make sure all development system uses the right sets of VIs.

I suggest you try this, it's so easy, and has been working really good.

//Mike

[Yair]

  On 5/2/2013 at 12:38 PM, MikaelH said:

I found this way easier than vipm, to make sure all development system uses the right sets of VIs.

I suggest you try this, it's so easy, and has been working really good.

 

The main problem with this (other than that you need to edit reuse code directly in user.lib, or vi.lib, which is what NI recommends now) is that when you have a new version of LV you now have a repository which has VIs saved in version X used for version X+1, X+2, etc. If you save them (because LV will ask you to after recompling, unless they have separation enabled), then when you want to update, you will get conflicts. If you want to edit the reuse VIs, then you have to do in the oldest LV version, which is reasonable until you get to a point where you want functionality which isn't in the old version. Then you have to decide to skip the functionality, stop using the old version or force the old version to only update to version X of the code.

[hooovahh]

  On 5/2/2013 at 12:38 PM, MikaelH said:

I found this way easier than vipm, to make sure all development system uses the right sets of VIs.

I suggest you try this, it's so easy, and has been working really good.

//Mike

I'm also going to side on Yair with the version issue.  At times I've had up to 9 versions of LabVIEW installed on my machine at once.  Unless you have a separate folder (or repository) for each version of LabVIEW there are going to be some issues for me using it.  And if you do have a separate location for each version then, when there is some bug fix I now need to fix it in each location.

 

Also I don't know how I feel about editing a users LabVIEW.ini.  On the one hand it should be no different then adding tools menu items, or quick drop functions, but for some reason I feel like the LabVIEW.ini is a place for a user to customize LabVIEW the way they prefer it.  What about the dreaded Auto Tool argument?  Am I to force all developers to not use Auto Tool (or force them to use it)?  Sure the majority of the settings we can all agree on (insert auto-feedback, terminals as icons, separate compiled code), I'm just thinking about the few that are user specific.

 

I also like the fact that I can take one VIPC file which can contain all internal and external reuse code, and settings, and take it to a computer that is offline.  There are many times where a PC will be in an environment where internet is not an option and bringing reuse tools and components (as well as SVN) are difficult.  Now I just grab one VIPC which is a snapshot of the reuse used on a project.  This is also great for configuration management because years down the road I can say exactly what VIs were used from the user.lib.  I guess SVN could do that too with revision tracking so that's not as big of a deal.

 

I'm glad it works for you but there are too many reasons for me to not use SVN for these types of changes. 

[MikaelH]

Yes, I do have a repository for every LV version :-)

Also every time I release/build an exectutable, I tag both the Project Folder (e.g. MyTestSystem-PN:123546-Rev:C12-2012-05-03) and also my LabVIEW repository (LabVIEW2012-2012-05-03-MyTestSystem-PN:123546-Rev:C12), that way I can alwasy get back to the environment I had when I did the build.

 

In case you don't have an internet connection, I would go with a VIPM package.

 

For the LabVIEW.ini file, we only update shortcuts to use a company defined shourcut list, but the VI we run to update the LabVIEW.ini file also updates all your prefered settings.

So the user selects his name in a drop down list and then it will configure all his LabVEIW.ini files to his taste.

Yes I did mean all, this is how my LV folder looks like.

 

 

 

 

[todd]

Cool! Thanks for sharing!
By the way, a variant constant's class name is "constant", which is missed by the scanner.

[MikaelH]

If anybody have time to update it and make it better and more fun/addictive to use, please feel free to share.

I thought about adding it in the Project Secondary provider start-up VI, so the users have to get X of Y correct QD placements within z seconds, before it lets then continue using LabVIEW.

Maybe depending on their score, they'll need to do it more often

 

So suddenly when they do a LabVIEW2012-folder update, they get this function installed automatically.