LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview 7.1

I am trying to deploy TS 3.1 seq with LV 7.1 vi's and Operator interface. Operator interface works fine with just the TS and LV rubtime engines present. Some vi's that work with the full dev system installed won't work with the LV Run Time engine only, when called from TS (specify module). Some vi's do work. All vi's work when the full Dev System (LV 7.1) is present.
 
TS returns an error "vi is not executable" No LV error code.
 
One specific vi that the LV RTE won't run is any vi created by TS 3.1, but the LV RTE also won't run some of the vi's created by LV. All the vi's either came with LV 7.1 or were created in LV 7.1. No other versions were used.
0 Kudos
Message 1 of 10
(4,033 Views)
The runtime enginge is only capable of executing vi's if all sub vi's are present. The LabVIEW development environment has a lot of subvi's that are simple vi's. When you build an executable, these vi's are included so the rte can execute the main vi. Typical examples of these vi's are "Merge Error.vi", a bunch of picture control support vi's, and three button dialog sub vi's.


You have a good change that it will work if you copy the vi.lib subdirectory in your vi file hierarchy. Otherwise, you can put all your vi's in a new vi. Then build a new executable, with the option that puts all sub vi's in an external llb. Then delete all your own vi's from the llb, so the original vi's will be used. Put the remainder of the llb in the subvi hierarchy, so the rte will find them.


Hope it helps,


Wiebe.
0 Kudos
Message 2 of 10
(4,016 Views)

Thank You for your response.

I understand that all sub vi's have to be present for any vi to be executable. It is my understanding that the Test Stand deployment tool was supposed to find all these vi's and place them accordingly. Attached is one vi that the system says is not executable. It has three sub vi's, which have their own sub vi's etc etc One of them is located in the vi.llb. (I did copy vi.llb to the target computer abd still got the error) and I can't find the other ones (using "find vi's on disk" utility). They are locatable in their particular pallettes but not in the file system (at least I don't know how to locate them). They are  vi's that don't have  block diagrams.

GTB

0 Kudos
Message 3 of 10
(4,000 Views)
Hi GTB,

I hope you are doing well today! Are you able to build and run the application in LabVIEW only, with no TestStand?
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 4 of 10
(3,978 Views)
All the vi's individually run in labview only (full dev). The entire thing works perfectly if the LV and TS full dev environments are present. The OI works, loads the seq and actually works with just the RTE's present as long as I don't use the vi's it doesn't like. A screen shot of the error is attached. I fixed some of the problems by taking any vi created by TS and re-making it in Labview.
 
The whole application is written in TEST STAND using LV vi's as the specified modules, so no, it obviously won't work at all without TS.
0 Kudos
Message 5 of 10
(3,969 Views)
Hi newnew,

There are a couple of causes for this error, and here are the KnowledgeBase articles about them.  Let us know if these don't resolve your issue.

Why Do I Get Error -18002 "VI is not executable" with TestStand?
http://digital.ni.com/public.nsf/websearch/7A806984E7ACB66E86256A50006C2F26?OpenDocument

Receiving Error Code -18002 in TestStand From Custom Substep After Changing Computers
http://digital.ni.com/public.nsf/websearch/7B3D68B5AEE7BD65862571A200325BB3?OpenDocument


Gavin Fox
Systems Software
National Instruments
0 Kudos
Message 6 of 10
(3,944 Views)
After a little more experimentation, the problem seems to be with the "Read Characters from File.vi" and possibly its sub-vi's.
0 Kudos
Message 7 of 10
(3,940 Views)

Looks like our last replies crossed in the mail.

I can't find any command in TS 3.1 that is "Assemble test vi's etc" The only thing I have done is use the "Deployment Utility"

0 Kudos
Message 8 of 10
(3,929 Views)

OK,

It does not appear to be anything you have mentioned so far.

It definitely has something to do with your "Read Characters from File.vi" and its sub vi's.
If I make an .exe with just this vi using 7.1 app builder it runs on the source computer, and the target computer (which only has the RTE's on it).

If I use the same vi (Read Char from File) directly as a specified module it will run in TS as long as I am in the LV DEV environment. If I switch to the LV RTE (configure adaptor) on the same computer (source computer) I get the non-executable error. Yet, it is working perfectly from LV dev and as a stand alone executable on the same machine at the same time.

I got rid of any other versions of TS or LV, plus all their folders, re-installed TS 3.1 from scratch, mass compiled etc

Again, the only time I get the error is when I try to run the vi in TS  configured to run with the LV 7.1 RTE.  In any other combination, on the same machine, with LV 7.1 RTE or DEV, it works. The source machine has the full TS and LV systems on it. The target machine has only the RTE's on it.

I still cannot find "TestStand "Assemble VIs" tool " in TS 3.1

0 Kudos
Message 9 of 10
(3,893 Views)
Hi newnew,

Sorry about that part of the KnowledgeBase.  The "Assemble VIs" TestStand tool is now part of the Deployment Utility as of TestStand 3.0.  The Deployment Utility will place the support VIs together.  If you go to the "Distributed Files" tab of the Deployment Utility, and click the "LabVIEW Options" button, you can choose to "Lock VI Diagrams" so your VIs can run without the development system.

Gavin Fox
Systems Software
National Instruments
0 Kudos
Message 10 of 10
(3,867 Views)