We need FRC version of: CMP compare two VIs.vi

[j_osh_o]

In order to enable collaboration in the development process, we need some way to see the changes made to a VI.  NI provides a vi to accomplish this: CMP compare two VIs.vi, but it is disabled in the FRC version of LabVIEW due to licensing.  I know NI has given us a lot for free already, so I understand it may not be practical for NI to provide us with a license for this vi.  My questions to NI engineers or the community are as follows:

1) Can NI provide us with a "crippled" version of "CMP compare two VIs.vi"

2a) Is there a freeware version of this vi?

2b) Is there an experienced developer out there who would like to make one?  I would be willing to assist but I have no idea where to start.

[StephenB]

The VI Compare tool is included in the Professional edition of LabVIEW. You can see its functionality here: http://digital.ni.com/public.nsf/allkb/3493C58EA0E842FA86256F86006142C0?OpenDocument

Unfortunately LabVIEW FRC is built from the Full edition of LabVIEW which does not contain this tool. I have contacted R&D and it doesn't look like we will be able to 'activate' it for this past season's LabVIEW FRC. It's usefulness has been noted and considered for the next season's LabVIEW FRC.

[sciencewhiz]

Put me solidly in the camp of wanting LabVIEW professional (or at least the compare/merge and source control integration parts).

When I started mentoring a few years ago, the team did source control by periodicly copying and renaming the entire directory. That worked for backup, but misses the major advantages of source control (history tracking and simultaneous work). We set up CVS and now everyone is comfortable with source control, which I think will greatly benefit them in their careers (I meet many people at work who only use source control because they have to, and are missing the great benefits).

This year, we still used CVS with LabVIEW, but it felt like we were back in the old days of only creating backups. Without graphical compares, it was very hard to reconstruct the history. Without merging, we couldn't work on the same file at once. We tried to mitigate that by making small files, but that didn't always work out. It also seemed like many times, changing one file affected many others, and I never did figure that out completely. In speaking with my manager at work, he also complained that it was very hard to use source control with LabVIEW. If we can teach everyone now how to effectively use source control with LabVIEW, it may help the adoption of LabVIEW in industry, as some of the misconceptions get broken down.

[StephenB]

Hey Sciencewhiz,

I know we use perforce here for development. Also, while I can't say anything yet about new releases, know that source code control compatibility is a major focus for our LabVIEW R&D team... so be on the look out for improvements in our upcoming products.

In the mean time, this may be of some use: http://digital.ni.com/public.nsf/allkb/C751F800E258087B86257535006DB160?OpenDocument

Take care.

[j_osh_o]

Hi sciencewiz, thanks for your comment.  I had planned on doing exactly what you describe: keeping the VIs small and using the mk-1 eyeball for diff functionality, although I had some concerns about whether this worked or not.  It sounds like you really tried your best to use source code control for LabVIEW, but it was just not workable.  I suppose we could use locks, but I know that would be problematic.

Last year we used the C++ library to program our robot, and there was difficulty getting enough students to participate in coding due to the learning curve for C++.  In my mind the entire purpose of FRC is to get more students participating.  If it really isn't workable to use source code control for LabVIEW, we are really in a bind.  On one hand we have C++ and Java, which have tough learning curves, especially for a 15-year old who is doing this purely for fun in his or her spare time.  On the other hand is LabVIEW, which is easy to learn but impossible to collaborate on, so if we "succeed" by getting more students to participate, we "fail" because we will end up stepping all over each other.

[sciencewhiz]

I wouldn't characterize it as "not workable" but defintely harder then I'd like. We didn't use locking, and after seeing how many times LabVIEW updated a file for an unknown (to us) reason, I think it might cause problems. We have a bunch of commits that say "no idea why this file was updated". We didn't have any major problems, just a lot of small annoyances.

The main reason I posted was so that NI knew it wasn't just one person who wanted the professional version. We definetly do to.

[sciencewhiz]

I'm glad to know that NI is working on the source code control compatibility, hopefully that alleviates my managers bad feelings about LabVIEW. I hope that NI will provide (at least those capabilities from) the professional development system for FIRST teams next year, to alleviate our concerns.

Thanks for bringing this up with R&D.

[sciencewhiz]

Is there any chance of getting LabVIEW 2009 and LVCompare.exe next year? The integration with TortoiseSVN sounds very helpful.

[MarkBlack]

FRC 2010 will be using LabVIEW 8.6 not LabVIEW 2009, but it will include LVCompare.exe

[j_osh_o]

Thanks for the update!  Can you provide a link to the announcement that this will be available?  Also, LVCompare.exe, to my knowledge, is a program that allows your SCC program to call "CMP compare two VIs.vi".  Heck, I have LVCompare.exe installed on my machine right now, but it can't do anything useful because I have no access to the vi of interest.  Perhaps you have confused the two?