LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running top-level VI indicated as bad by exec:state

Solved!
Go to solution

Hey guys,

 

I have Labview 18 SP1 running on a windows 10 computer. I have two LV projects on this computer. In project 1 I run the top level VI, which is just working fine. Since project 2 is somehow dependend on the top-level VI from project 1, I thought it might come in handy to check if the top level VI from project 1 is running. This check is performed from the top-level VI from project 2. The check is based on this snippet: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YIEJCA4&l=en-US

 

Now, when I run the top-level VI from project 1 and try to check its execution status from the top-level VI from project 2, it simply returns "bad". If I check the status of a subVI from the top-level VI from project 2 (which is not running at this moment), it indicates "idle". When I check the status of another, new VI (path is the desktop) with a simple while loop and a stop button I get the status "Run top level". So I guess the snippet code itself should work.

 

I triple checked, that the path to the top-level VI from project 1 is correct. However, I have no idea why it always returns bad, though the VI is running. Maybe it has something to do that the top-level VI of project 2 is part of a project?

 

Any help is welcome.

0 Kudos
Message 1 of 9
(1,437 Views)

It's bad because it's locked, because it's reserved in another instance.

 

If you'd open the VI (for editing, not dynamically) in project 2, it will be locked too, I assume.

 

If you really want the run state, you'd have to get a reference to Project 1 context, and open the VI's reference from that reference.

0 Kudos
Message 2 of 9
(1,435 Views)

Hey wiebe,

 

Thank you for your response. I was trying to do what you suggested but since I am quite new to the method stuff I was not able to.

 

Could you provide me with a small example VI or code snippet? You could also point me to the correct methods in order to get a reference to the project running the VI of interest.

 

best wishes

Slev1n

0 Kudos
Message 3 of 9
(1,331 Views)
Solution
Accepted by topic author Slev1n

This does seem to be a typical problem that only happens because you're quite new.

 

I personally never did this, because I never needed it, because I probably solve this on a higher level.

 

You might be trying to work around a problem that you shouldn't have in the first place. It's hard to advice on that without knowing a lot more details. There might even be a good reason to want this... 

 

You will run into problems if you ever want your code to run as an executable.

 

Anyway, this seems to do the trick:

VI From Other Project.png

 

 

0 Kudos
Message 4 of 9
(1,327 Views)

Hey wiebe,

 

Thank you for the snippet. I had to rebuilt it since it is LV 2020 and we have 2018 but this is fine, it works.

 

Maybe some more background to the situation on my side. This is a university lab with a high fluctuation of students using (and sometimes expanding) the programs for our measurement setup. Hence, an executeable is not planned nor is the code intended for that.

Nevertheless, am I interested in improving my understanding towards rather large/complex VIs or LabVIEW project setups in general. This could help me avoid such shortcomings in the future.

 

What would be your general approach if you have two (or more) larger VIs, which are basically independend but are interfering with each other in some occasions, e.g. some info is exchanged via shared variables? Would you put them in one project? Would you trigger execution of one VI by the other?

I know there is no simple answer to that because it always depends on multiple circumstances but maybe you can give some advice.

 

best wishes

Slev1n

0 Kudos
Message 5 of 9
(1,320 Views)

@Slev1n wrote:

Hey wiebe,

 

Thank you for the snippet. I had to rebuilt it since it is LV 2020 and we have 2018 but this is fine, it works.

 

Maybe some more background to the situation on my side. This is a university lab with a high fluctuation of students using (and sometimes expanding) the programs for our measurement setup. Hence, an executeable is not planned nor is the code intended for that.

Nevertheless, am I interested in improving my understanding towards rather large/complex VIs or LabVIEW project setups in general. This could help me avoid such shortcomings in the future.

 

What would be your general approach if you have two (or more) larger VIs, which are basically independend but are interfering with each other in some occasions, e.g. some info is exchanged via shared variables? Would you put them in one project? Would you trigger execution of one VI by the other?

I know there is no simple answer to that because it always depends on multiple circumstances but maybe you can give some advice.

 

best wishes

Slev1n


If it were me I would generally use some type of messaging API in the applications. This would be some sort of client/server model where each application has some well defined API that other applications can use to get data, change configuration or whatever other functionality is needed. You could use network streams to implement this. Though I usually use a TCP/IP based client server model. You could also implement a simple REST API as well.

 

Another easier approach would be to uses files to exchange information. applications place the data in files in well defined folders on the PC and other applications can then read those files to get the data. This generally works well for simple data exchanges. Not so much if you need to actually make other requests of the system.

 

I generally stay away from using network shared variables.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 9
(1,303 Views)

@Slev1n wrote:

Maybe some more background to the situation on my side. This is a university lab with a high fluctuation of students using (and sometimes expanding) the programs for our measurement setup. Hence, an executeable is not planned nor is the code intended for that.

Nevertheless, am I interested in improving my understanding towards rather large/complex VIs or LabVIEW project setups in general. This could help me avoid such shortcomings in the future.

 

What would be your general approach if you have two (or more) larger VIs, which are basically independend but are interfering with each other in some occasions, e.g. some info is exchanged via shared variables? Would you put them in one project? Would you trigger execution of one VI by the other?

I know there is no simple answer to that because it always depends on multiple circumstances but maybe you can give some advice.


The executables help a lot with trackability and bug tracking. So experiments can be linked to a version. Of course, this might not apply either.

 

I'd look for an API like either a communication protocol or a plugin structure, like packed libraries. 

0 Kudos
Message 7 of 9
(1,294 Views)

Thank you both for your valuable input. I will keep that in mind for the future.

 

best wishes

Slev1n

0 Kudos
Message 8 of 9
(1,277 Views)

What solved to me:

 

Build an EXE only with the VI that has Bad State. Run the EXE. The Front Panel Appears with broken arrow, click to show the errors.

 

In my case some libraries where not found in exe mode (in development mode, everything ok).

 

Than add these deppendencies to "Allways included" in Build properties.

0 Kudos
Message 9 of 9
(284 Views)