DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1003 only when launched from API tester

Solved!
Go to solution

Hey!

 

I recently ran into a very strange problem with one of my DQMH modules. When I try to launch it from the API Tester.vi I get error 1003 telling me that the VI is broken or bad. The main VI for the modul is perfectly fine, has no errors and can be launched from any other VI that is calling the "Start Module.vi" but not from within the API tester. 🤔

 

After taking a look at the start routine for the module the error is obviously caused by the Exec.State method inside the "Get module Main VI Information.vi" and to be honest I'm not really sure I understand how this is even working for all the other modules. However I can't figure out what's wrong with the API Tester so I really hope that someone else might have a solution for me.

 

Unfortunately, I can't upload the files here because I'm not sure if my company will even allow me to do so.

0 Kudos
Message 1 of 5
(2,029 Views)
Solution
Accepted by topic author Jens_S

Maybe you accidentally dropped your Main VI as a subVI on the diagram of the tester? That would cause it to be reserved for running when the tester runs (assuming this is a singleton), which means you would be unable to launch it?

 

Perhaps set breakpoints in the tester, and have the Main VI panel open. When you run the tester, see if the run arrow of the Main VI changes state.

0 Kudos
Message 2 of 5
(2,024 Views)

Hey!

 

That's a good suggestion, found it!

 

Jens_S_1-1635868524502.png

 

I have a rather "dirty" request where I can send the Module name as a string and the Module will start the corresponding API Tester for the module. If I start the API tester first and then try to start the module this VI will break because of the static VI ref.

 

To be honest I'm not sure how to do this in a better way. If I start my application by it's launcher.vi everything is working fine. Later when build into an actual application there is no way to launch the API first and then the application itself so maybe it's no to bad?

0 Kudos
Message 3 of 5
(2,016 Views)

I'm glad you found the issue. If you want to remove those static links, you could build the path to the tester dynamically then call Open VI Reference by path. You could replace the Static VI Ref wired to the Open VI Reference function with a VI reference constant that defines the conpane but isn't a static VI ref. These changes would remove the static linkages to the tester VI from your code. You could then change the code to check the state of the VI when opening a reference to it, and if it's already running, don't try to run it again.

Message 4 of 5
(1,994 Views)

Thanks for your hint to do it the right way. Done everything but the Vi reference constant cause I have no clue how to do this. Getting the ref constants (not only for VIs) is always something that bugs me in LabVIEW.

 

As far as I understand the VI ref is used to define the frontpanel elements and the datatypes. If I try to use a non strict VI ref the Start Asynchronous Call break cause it needs a static VI ref.


Maybe you can enlighten me how to do this?

Edit: Got it!

 

Open API Tester.png

0 Kudos
Message 5 of 5
(1,973 Views)