Running a plugin executable

[Yamaeda]

Don't forget to set Working folder to the same as Executable folder on the System Exec node.

/Y

[m3rl3n]

Thanks - All great suggestions.

The Z: drive is a mapped local drive. We have a number of different systems / configurations on the one PC and the way we keep the disparate systems separated from the others while running is to map each main system folder as the Z: drive using a batch file to start. That way the software can use the same directory structure while each system is a base folder (does that make sense?).

Remember too, all of the other plugins work fine....  I think I have narrowed it down to an issue within the T.exe although I have no idea what or why...

My next step is to try using application control methods rather than the system exec.vi and / or take out the NI_xml.lvlib usage and see if there's something there causing issues.

I'll let you know what I find...

[m3rl3n]

yeah...  scratch that about the application control methods. That won't work in this case.

[m3rl3n]

I ripped out the two VIs (I know I said four, but it was only two) that were contained within the NI_xml.lvlib and being used to save some configuration stuff, and the program now starts up perfectly fine.

I'll try to burrow down to see if there is a specific part of the code that caused the issue or if it was a fluke.

[m3rl3n]

I'm not sure if this is the issue or not. It seems weird that the T.exe would run when double clicked, etc, but not when running through the A.exe.

In drilling down, I have found in the "Get First Matched Nodes.vi" and the "Get All Matched Nodes.vi" contained in the NI_XML.lvlib (LabVIEW 2016) are truly the offending vis for this. If I take them out, T.exe launches with no problem. If I put them in, I have the same issue.

What's interesting is in both VIs, the "Node In" control is a Refnum, but the input to the function "XPathEvaluateContextToNode" in the library "DOMUserDefRef.*" is a Type Numeric and Data Type of Signed Pointer-sized Integer.  In thinking about it, this is probably correct, but it the first think that popped out to me.

I will bypass these methods for now and if needed in the future I'll find a different means of programming the same functionality.

Thanks for all of your insight / input.

[m3rl3n]

I had a thought...

I started to wonder if the reason the T.exe had an issue with starting from A.exe is because there was already an instance of the two VIs already in use on A.exe and when T.exe was started there was a conflict of references.

That is not the case. There are no components of NI_XML.lvlib used in A.exe.

[Ben]

When run as an "exe" they run in different process contexts.

Ben

[m3rl3n]

Yes, I understand that. That's one of the reasons this has me stumped.  There should be no difference between running it by double clicking the executable, through the dos shell, or the dos shell as called from A.exe, but apparently there is...  something.

[Ben]

Did read that A.exe was written in an older version of LV?

If so did you try to regen A.exe in a new version?

Ben

[JÞB]

---

@m3rl3n wrote:

Yes, I understand that. That's one of the reasons this has me stumped.  There should be no difference between running it by double clicking the executable, through the dos shell, or the dos shell as called from A.exe, but apparently there is...  something.

---

Yes, there is something!  z:\ is mapped through the OS to <//Domain/>