TestStand 2012 SP1, Batch Model Error

[jhedr]

I am getting an Error 509; User-defined error code.  Details says:  An error occurred while performing batch synchronization on the step.  Screen shots of the Sequence and Error Message that caused the error.  Only happens on/after the 3rd or 4th Batch, was happening on 4th now seeing on 3rd batch with this sequence.  The ScanWorksCOMServer.dll was not built by me, it was with ScanWorks for JTAG Testing.  Any ideas?

I

[Branch_Support-NIC]

Hi jhedr,

So is there any way that you can step into the CVI DLL in the ScanWorks Disconnect step, and see where the error exactly is happening?

How many batch sockets do you use? has this always been an issue, or the program used to run?

We need to get more information in order to troubleshoot this error better. Maybe if you can contact the owner of the code, and see if they can provide more information on this error, it would be great.

Please let me know.

[jhedr]

The DLL is built by Asset-Intertech, we do not have source code.  They supply the DLL and a the CVI generated Library.  This is new code, I can call the Connect/Disconnect as many times as I want within the sequence.  Once the Batch Completes, and I run the Batch again (3+ times) we get the error.  At first it did not appear on the Disconnect, it was appearing on another Batch Serial Step.

[CoffeeBreak]

 Jhedr,

As Branch_Support-NIC stated it would be extremely helpful if you could try and contact Asset-Intertech to find out more information regarding the error code 509 that they defined.

Is there a specific reason why the Check Single Thread Return and the Sequence Call steps are skipped?

[jhedr]

I will try contacting Asset.  The reason the steps are skipped is they aren't needed.  I was trying to see if just doing the Connect/Disconnect presented the issue, and it does even when running only 1 socket.  The error says it is an error while trying to perform a Batch Synchronize, so I do not think it is their problem as it only occurs if the steps are set to Batch One-Thread (Didn't try serial or parallel), if not set to Batch Synchronize the problem does not appear.

[CoffeeBreak]

 jhedr,

I am currently delving into this issue to track down more troubleshooting steps. I am also working with the other Applications Engineer that owns the service request for this issue.

[dug9000]

Something that the dll might be doing that would break batch synchronization as well as many other things is if the dll is uninitializing COM for the thread which calls into it after having failed to initialize it due to TestStand having already initialized it for a different COM apartment (i.e. TestStand initializes its threads as MTA, but the dll might be trying to initialize as STA).

See the following:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms695279%28v=vs.85%29.aspx

When CoInitializeEx() returns RPC_E_CHANGED_MODE, the caller must NOT call CoUninitialize() or they will be uninitializing COM for someone else's (in this case, the TestStand engine's) call to CoInitializeEx() because their call to CoInitializeEx() failed and did NOT increment the reference count to the COM initialization.

This has come up in the past with other COM using dlls written by 3rd parties. You might want to ask the developers of the dll you are using to take a look at this post and see if this is the case with their code or not. If so they should update their code to NOT call CoUninitialize() if their call to CoInitializeEx() returned RPC_E_CHANGED_MODE (really if it returns anything other than S_OK or S_FALSE they should not be calling CoUninitialize(), they could use the SUCCESS() or FAILED() macro as well to be more future proof).

If I am right about the cause, you can also workaround the problem by running all of your code which uses the dll in an STA thread from TestStand. You can do so by using the sequence call step with the new thread setting and the advanced settings for the thread set to use an STA thread and then a wait step after the sequence call to wait for the thread to complete.

Hope this helps,

-Doug

[Steve_Altaffer]

Realize this is an old thread but thought I would provide my experience.

We had the same issue in 2012 using TS 2010 SP1 and ScanWorks 3.13 but only when there was TS Flow Control Steps executed while ScanWorks Server was loaded. The same workaround was provided however only to call blocks containing Flow Control Steps in a subsequence launched in new thread and Wait for thread completion. Our latest Project has added a Sequence File Callback full of 'If' steps so the problem resurfaced. I solved it by opening the ScanWorks COM Server (and open Project/Design) in a subsequence launched in a new thread (and the Wait) but did not use STA and it solved the problem. All othe ScanWorks calls (Load/Run Actions, Disconnect) are in the TS thread with no issues noted to date.