multithread blocking

[macsmithAgain]

thanks for your reply Ben.

I have been thinking about creating a bat file as well as a Python script linked to labview via a telnet socket.  A CIN is another possibility.

I don't think the license server is causing the problem.  Part of the completion of Crunch is to write data files to disk after which it returns the license it was using.  I can see that both of these occur at the times they are supposed to.  The license server will always co-operate when there are licenses available.  To prove this, I have manually done the job that the labview vi is meant to do: I open 3 cmd windows, enter the crunch command to each of them (within a few seconds) and, when the first one finishes, issue the command again to that cmd window.  It starts immediately, even though the other two instances of crunch are still running.

Back in the vi, I do display start times for each of the loops (the vi I posted was a simplified version).  All three start times are always the same.

Thanks

Ian

[macsmithAgain · Accepted solution]

I tried three msdos batch files to run crunch but that showed the same symptoms.  Note, though, that I had to use the labview cmd vi to run the batch files.

I then tried three python scripts, each listening on a different telnet port and using os.system() to launch crunch.  In the vi application I used the various tcp vis to open, read, write and close.  This worked.  All three instances of crunch now run completly independantly of each other.

So there seems to be some obscure bug/feature of the labview cmd vi.

Ian

[Ben]

---

@macsmithAgain wrote:

I tried three msdos batch files to run crunch but that showed the same symptoms.  Note, though, that I had to use the labview cmd vi to run the batch files.

I then tried three python scripts, each listening on a different telnet port and using os.system() to launch crunch.  In the vi application I used the various tcp vis to open, read, write and close.  This worked.  All three instances of crunch now run completly independantly of each other.

So there seems to be some obscure bug/feature of the labview cmd vi.

Ian

---

Sounds like have the work-around you need but I am still curious and wondering if the Sys exec is somehow associated with your application but the DOS prompts look like unique sessions.

Ben