Teststand 3.1 getting stuck at "Get Next Request" step inside ProcessTestSockets step of Batch Model.

[kevmi2ca]

My application will work fine for days and then, all of the sudden, it will freeze at this step. (There is some Dequeueing going on in this step.) If I Break All it just ways "waiting".

Any help is appreciated.

[AndrewMc]

What does this step actually do?  Describe everything that goes on in this step or post the code.  My guess is that this step is waiting on something to occur (perhaps a race condition) which is never happening.

[paulmw]

---

@AndrewMc wrote:
What does this step actually do?  Describe everything that goes on in this step or post the code.  My guess is that this step is waiting on something to occur (perhaps a race condition) which is never happening.

---

I believe he is referring to NI's part of the batch process model that receives messages from the batch process model dialog.  In my version of teststand the sequence is called ProcessTestSocketRequests inside BatchModel.seq.

Did you modify this sequence?  This dequeue step should be set up with a timeout (I see 1 second in TS 3.0).

Is the batch dialog stopped when this happens?  The dialog is where the messages in the queue are coming from.

[AndrewMc]

Hey Paul,

Thanks for pointing that out.  I read the message without actually looking at the title. ; )

Nice questions, Paul.  The default batch process model for TestStand 3.1 should have a timeout on that step configured.  Kev, can you verify this in your process model?  Do you have any disabled sockets or anything at this point?  Do you see any correlation between when this behavior occurs and any other factors?  That is, what is the status of execution at the point right before freezing?

Message Edited by AndrewMc on 08-29-2007 07:47 AM

[kevmi2ca]

Thanks for the responses guys.

Yes, it's the ProcessTestSocketRequests inside BatchModel.seq that's given me the problem.

I think I figured it out...

The test step is a VI which communicates with a DUT via Telnet (with error cluster tied from Labview to Teststand). If the Telnet session errors out, the the program seems to freeze instead of moving to the next step. Btw, I have "Ignore Error" selected in the Execution tab of Station Options menu so I don't get the RunTime Error window.

What I'm thinking is I'll disconnect the error cluster so Teststand never even sees the error. My while loop will stop on error, my step will fail, and teststand should move to the next step. I'll run some tests to verify - I can simple unplug the Ethernet cable to simulate a DUT failure.