Jump to content
_Y_

Compare two VI-s without human interraction

Recommended Posts

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!

 

Share this post


Link to post
Share on other sites
  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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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..... :frusty:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by Rolf Kalbermatter

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.