subVIs are unreferenced when creating an .exe?

[00engineer]

Hi again, 

Below is a snippet and a screenshot of another reference to a subVI without placing the subVI into the mainVI itself.

When I replace the above reference by actually placing the subVI into the mainVI, and run this aspect of the program, I get this error:

Possible reason(s):

LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
Command requires GPIB Controller to be Controller-In-Charge.

Method Name: Control Value:Set

"UnlockDirect" not found

Below is a screenshot and a snippet of the block-code after I place the actual subVI into the main VI (which causes the above error).

Can either of you or anyone else please help me with why I am getting this error? The selected method/answer worked for other aspects/sections of the program, but not this one!

Thanks so much in advance!

[altenbach · Accepted solution]

You really need to attach your VI and subVI. The snippet does NOT include the subVI, but that's where the error occurs. What happens if you enter correct control values in the subVI and run it alone?

Note that originally you did not wire the error output of the subVI, but the error of call by reference node. These are completely different. We don't even know if you have automatic error handing enabled.

Also note that you can wire the string directly to the case structure and make one case "set Data Path" and the other "default". Case structure selectors accept a wide variety of datatypes (Strings, booleans, integers, enums, etc.)

[00engineer]

Thank you,

You pointed out something that wasn't obvious to me (the error output of the subVI).

Once disconnecting that and re-routing the error handling wire to the other end of the case structure, the program and subVI worked as expected.

I appreciate your help!

[JimB.]

---

@00engineer wrote:

Thank you,

You pointed out something that wasn't obvious to me (the error output of the subVI).

Once disconnecting that and re-routing the error handling wire to the other end of the case structure, the program and subVI worked as expected.

I appreciate your help!

---

So you no longer have anything going into or out of the error in/out terminals?

If that's the only change you made then I would guess that the error still exists, but that your doesn't have automatic error handling turned on so you are not seeing it. (You can check that in the VI Properties under the Execution section.)

Did you try running the subVI on its own as suggested? Step through the call to see where the error actually occurs? As was pointed out, the error occurs inside the subVI, so its contents would be more relevant in why this is occurs.