Compare two VI-s without human interraction

[_Y_]

Hi all,
 
I need to compare two VI-s dynamically, i.e. by my LabVIEW program. Unfortunately, the single solution found does not differ much from conventional VI-comparing tool supplied with Professional version of LabVIEW.

 

This is what I found:

1. LVCompare.exe allows launching comparison of two VI-s but it exposes results in conventional UI. However, I need an output that can be processed automatically: string, array of strings or something else.
2. NI_procmphier.lvlib:CMP compare two VIs.vi seems to be designed for such needs. However, I cannot get it working. It has no description and its BD is password-protected. All terminals are recommended, so the number of combinations is infinite. 

• Can some of you advice a method for dynamic comparison of VI-s?
• May be some of you know how to use CMP compare two VIs.vi? 

Thank you!

 

[Neil Pate]

1. NI_procmphier.lvlib:CMP compare two VIs.vi 

 

Where did you find this library? I do not seem to have it in my LabVIEW directory.

[joerghampel]

\vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi seems to do what you ask for (see screenshot).

[_Y_]

Where did you find this library? I do not seem to have it in my LabVIEW directory.

 

C:\Program Files (x86)\National Instruments\LabVIEW 2013\project\procmphier.llb\CMP Compare two VIs.vi

 

 

\vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi seems to do what you ask for (see screenshot).

 

Thank you very much, it is the solution! 

 

By the way, I have no idea what for terminal "application reference" is used. My problem is solved without any need in this derminal but I probably miss some pearl?

[joerghampel]

By the way, I have no idea what for terminal "application reference" is used. My problem is solved without any need in this derminal but I probably miss some pearl?

 

You can read up about application instances here. If you don't wire the terminal, it most probably uses the instance of your calling VI.

[_Y_]

You can read up about application instances here. If you don't wire the terminal, it most probably uses the instance of your calling VI.

Yes, it seems so. But what is the use for this terminal? Enabling to work with VIs belonging to the caller program without name conflict?

[joerghampel]

Yes, it seems so. But what is the use for this terminal? Enabling to work with VIs belonging to the caller program without name conflict?

 

I haven't used this VI much myself. I agree that name conflicts are the most obvious reason for wiring an application instance. Also, it probably won't work in the Run-Time Engine. And if you call it from the Tools menu, you might or might not want it to run in that application instance (NI.LV.Dialog).

 

Perhaps someone else with more experience can chime in?

[hooovahh]

I haven't used this VI much myself. I agree that name conflicts are the most obvious reason for wiring an application instance. Also, it probably won't work in the Run-Time Engine. And if you call it from the Tools menu, you might or might not want it to run in that application instance (NI.LV.Dialog).

It won't work in the Run-Time engine for several reasons, one is generally there is no block diagram, and many scripting things don't work.  As for the application instance.  If you launch it from the tools menu, you may want to pass in the instance that the user already has open.  So if I already have my project open, it might be a good idea to use that instance because it is already loaded in that instance.  When using a tools menu there is a couple useful property nodes for Application >> Menu Launch >> App, and VI.

[shoneill]

Indeed, not wiring the instance can have some awkward side-effects.  LaunchingLVCompare.exe from a SVN client for example will try to open it in the CURRENT context.  Running LVCompare on an FPGA target is not something I've yet managed to get working.....

[NicoEMC]

I just read this topic.

Be careful with SCCSup Compare Two VIs : if the vi have the same name, there is no error and no difference will be return.

[Rolf Kalbermatter]

On 6/24/2019 at 11:06 AM, NicoEMC said:

I just read this topic.

Be careful with SCCSup Compare Two VIs : if the vi have the same name, there is no error and no difference will be return.

There can't be as LabVIEW can't and never could load two VIs with the same name into the same application instance at the same time. So it will load the first VI, then attempt to load the second, seeing that it is already loaded, then compare the two. Obviously there isn't any difference between the two.

While you could argue that the function could check the two VI names to be equal before attempting to do anything, you also have to consider that this function is not your average Joe toolkit. It is fairly advanced and there is something to say about not sanity checking every possible error on every VI boundary down several hiererachy levels. If the user of this function wants that check it's easily done before calling this function. If he forgets such trivialities he may not be the intended target audience for this function.

Edited June 26, 2019 by Rolf Kalbermatter