LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1043 when calling "CMP Compare two VIs" from NI_procmphier.lvib in runtime exe

Solved!
Go to solution

There is an NI library called NI_procmphier.lvib which contains "CMP Compare two VIs.vi"  When I use "CMP Compare two VIs.vi" in my project, compile it to an Exe then run it, I get

 

Error 1043 occurred at an unidentified location

Possible reason(s):

LabVIEW: The property or method is not supported in this version of LabVIEW.

 

It is an Exe made of single vi with nothing but a call to "CMP Compare two VIs.vi" written in LV 2017 and the runtime is definitely installed.  So it made me wonder, is there some reason NI_procmphier.lvib or its functions cannot be included in a runtime executable? "CMP Compare two VIs.vi" is a locked vi, meaning you cant' view its block diagram without the NI password, but that can't be it, we use function from NI libraries all the time. 

 

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 1 of 10
(1,125 Views)
Solution
Accepted by TeraTech

The method that performs the compare is supported in the LabVIEW IDE, but it is not included in the run-time engine. In general, properties and methods in LabVIEW that support development tools in the IDE are not implemented in the run-time engine.

0 Kudos
Message 2 of 10
(1,096 Views)

Thanks Darren. Is there some way to which NI library methods are IDE only? Other than generally, that is.

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 3 of 10
(1,085 Views)

In your case, the method being called is a private method inside a password-protected VI, so there wouldn't be a terribly easy way for you to identify the method as being unavailable in the runtime engine. However, for all public methods, their context help should identify whether or not the method is available in the run-time engine.

 

Here's a screenshot of the private method inside that password-protected VI. You can see that the method's context help does have this designation:

 

cmp.png

0 Kudos
Message 4 of 10
(1,079 Views)

@Darren wrote:

The method that performs the compare is supported in the LabVIEW IDE, but it is not included in the run-time engine. In general, properties and methods in LabVIEW that support development tools in the IDE are not implemented in the run-time engine.


Strictly speaking there is also something called Fully Featured Runtime (lvffrt.dll). Some NI tools use that.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 10
(988 Views)

Rolf, I purposely didn't bring up the FFRTE because I highly doubt it would help in this situation, or the majority of situations where people have assumed in the past that it could possibly help. 🙂

0 Kudos
Message 6 of 10
(947 Views)

It might theoretically help. But it is a minefield, legally as I have no idea about what license you would actually need for it, technically as it is a pitta to get it installed and used by a tool consistently.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 10
(941 Views)

Thanks all. In my case, I didn't need an exe because I plan to distribute it, but just out of convenience. I have a file compare app that I use for all non-LabVIEW things.  It doesn't have LV hooks so I wanted to create a little exe that could be called when it need to compare two VIs.  Since I will only (likely) be doing VI compares while developing, I guess I could create a batch file or other script to launch/communicate with LV development, but really wouldn't know where to begin. I assume LV dev environment must have an "API" or some such way to automated things? I say this because VI Package Manager seems to start up LV if not already started. I have seen that a LV Exe can accept command line parameters, does the LabVIEW.exe accept command line parameters? Would that be the way to do it or is there a better or other recommended way to "make calls" to the LV development?

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 8 of 10
(873 Views)

There's already an EXE available that will compare VIs: 

 

Configuring Source Control with LVCompare.exe - NI

0 Kudos
Message 9 of 10
(870 Views)

Thanks, but LVCompare can't handle VIs with the same name, even when the paths are different. When LVCompare is used with source control, the source controls takes care of temporarily renaming the file which avoids collision. I am using a compare app, not a source control to do the comparison, so I need to write something that will copy and/or temporarily rename one of the VIs to be compared, then deleted/un-rename it when done. EDIT: And I'd rather do that file copying/renaming in LV than a batch file or other scripting language.

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 10 of 10
(864 Views)