Trouble with TestStand running VB DLLs compiles in separate threads

[tuxamation]

I have an application that uses DLLs written in VB 6 to manipulate hardware. The hardware is Stepper Motors controlled via the NI CAN bus card, and two instruments controlled via the GPIB PCI card. I have written the two DLLs to use the same NI PCI GPIB and the same NI CAN BUS card. (One instrument per DLL and One Motor per DLL)

Test stand is then creating the DLLs and running them in separate threads. I have the one DLL Call in a subsequence running as a separate thread, and the other DLL is in the main sequence. I have a GOTO step with preconditions set so that the main sequence only continues after the separate thread in the subsequence is finished.

The problem I am having is that these D
LLs work OK when I run them both in the VB debugger. The program even works when I run the main thread in the debugger, and the subsequence is run compiled.

The problem is, that if I try to run both of these DLLs compiled It seems as if the subsequence DLL never executes.

[Scott_Richardson]

To Tuxamation -
Nothing comes to mind as to why this would happen. VB 6 automation DLLs are used all the time for code modules.

Note that when MSVB debugs a DLL, it is actually running the DLL as an EXE server within the MSVB process and not in TestStand's process that is using it. I typically found that there is typically a subtle difference in behavior between running the server as an EXE or DLL server.

A simple way to determine if the TestStand call is reaching your DLL is to place a MsgBox function call in the DLL entry point and immediately return, ie. bybassing your existing code.

So, if the call is being made to your DLL, you could then enable the Visual Basic project option on the Compile tab, "Create Symbol Debug Info" and recreate your VB DLL.
You can then attach Microsoft Visual Studio (C++ debugger) to the TestStand process, open the file that contains the entry point in to DLL that TestStand calls, set a breakpoint, and see if the breakpoint is reached.

Scott Richardson

[tuxamation]

Scott,

I believe you are right. I actually noticed that if I wait long enough the two DLLs run consecutively rather than in parallel. (even though the one is in a subsequence as a separate thread) If either one is in the debugger they run in parallel. It seem I could make the simple one an EXE, but I�ve got a silly question.
How to I get pass parameters into and out of a VB exe? I need to pass in stepper motor position and GPIB address.

Thanks

[Scott_Richardson]

To Tuxamation -
Most hardware drivers can only work within a single process at a time. If your DLL or EXE that accesses your hardware is the only component that will use the hardware then you should not have a problem, that is a different component in the TestStand process should not try to use the instrument.

TestStand can pass the GPIB related information to the ActiveX EXE server and the server can talk to the instrument. This is all done using parameters to the methods that you call on the server itself. ActiveX/COM handles all the communication of data between processes for you. To a TestStand ActiveX step there really is no difference between a DLL server and an EXE server.

The typical downside to using an EXE server is that trans
ferring of data between processes is slower than using a DLL inprocess, and the invocation of a method is a little slower because it is not a direct function call.

Scott Richardson

[tuxamation]

Scott,

I made an EXE that mirrors my DLL and everything works well.

Thanks,

Tuxamation