LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Impossible "LabView: This dynamic subVi cannot execute because the needed vi cannot be found" error

Solved!
Go to solution

Dear all,

 

today I received an annoying error during the execution of a Modbus application. It seems to me a bug in the language.

 

The error is quite clear, "LabView: This dynamic subVi cannot execute because the needed vi cannot be found", and LV even suggests the offending VI and the VI that raised the problem (the IO operation of the Modbus library, see below).

 

The point is that the problematic VI is this write request:

 

Write.png

 

while this read request (structurally identical to the write) works perfectly:

 

Read.png

 

All the VI seems in the right place (members of the Modbus Master class), no errors are reported by the IDE during opening of the project (the error is runtime) and I can open the files from the souce browser under the Modbus Master.lvclass.

 

I have no idea of how to solve this problem. I hope somebody has a clue of what is going on.

 

Sincerely,

 

0 Kudos
Message 1 of 6
(3,867 Views)

Hello,

Try to mass compile the folder where this API is stored.

Guilherme Correa
0 Kudos
Message 2 of 6
(3,840 Views)

Thank you Guilherme,

 

I tried to:

 

1) mass compile the API (in vi.lib) ->  no avail (no errors) 

2) mass compile the API (in vi.lib), my project libraries and my project -> No avail (few errors relatd to dead files)

3) Clear the cache and the mass compille the API ->no avail

4) Clear the cache, mass compille the API, my libraries and my project ->no avail

5) Clear the cahe , mass compile vi.lib, my libraries and my project -> no avail (very long)

 

I did this also with the IDE closed. Nothing changes.

 

Sincerely,

 

0 Kudos
Message 3 of 6
(3,814 Views)

It is difficult for (most of) us to scrutinize your code from a picture.  Please attach the actual VIs so that we can "poke" at them, maybe even test them to see if we get the same error you are seeing.  It might be even more helpful if you wrote a tiny test routine that made up some simple "fake" data for the Write so that there was a complete program to test.  Alternatively, you could Compress the folder containing your entire Project and attach the .zip file ...

 

Bob Schor

0 Kudos
Message 4 of 6
(3,804 Views)

Dear Bob,

 

I am aware of that. I thoug that this was so wired that could have trigered some ideas. Something simlar must have already happened to somebody working with classes.

 

Regarding the debugging, I can include the VI, but nobody will test them without my hardware connected via Modbus to their PC. Even setting up a small test case is quite long for me now and I will do it only if I don't receive answers for some days or I don't solve the problem myself. Release of the whole project is not possible.

 

Thank you for the time,

 

Download All
0 Kudos
Message 5 of 6
(3,797 Views)
Solution
Accepted by topic author alanturing

Dear all,

 

I have somehow solved the problem myself. I noted down and share the steps I followed with the community because I still can't believe I made it:

 

1) I removed the dynamic dispach option from the input and output class connectors of "Write File Record.vi"

2) Executing my main test I noticed that the VIs using "Write File Record.vi" (for example "Write File1.vi") did not know anything about it anymore (black question mark appeared in place of my icon at the call point)

3) Drag and dropping the calling VI itself  on the block diagram (i.e. "Write File1.vi" on the block diagram of "Write File1.vi", I know that this is absurd... it was a miastake!) was enough to re-establish the internal link to the file (I got back my icon...)

4) When I fixed all the calling VI I switched back the class connectors of "Write File Record.vi" to dynamic

5) The problem seems to be gone

 

Note that in my case, the connectors of the VI calling the class method (e.g. "Write File1.vi") were not dynamic dispach because they are not class members, I don't know if this may be part of the problem.

 

However, this seems definitely a bug. Hope this is useful for the next who will stumble on it.

 

Sincerely,

 

Message 6 of 6
(3,779 Views)