Jump to content

Compare two VI-s without human interraction


_Y_

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!

 

Link to comment

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?

Link to comment

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
Link to comment

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?

Link to comment

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?

Link to comment

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.

Link to comment
  • 4 years later...
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
Link to comment

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.