TestStand - using DLL doesn't work on all PCs

[parkerfly]

We are using custom designed test hardware that is controlled via serial port.  A DLL was created that we access in teststand to command our test hardware through the serial port.  It's working on all but 2 of our computers - on those the sequence generates a Run-Time Error that says

An error occurred calling 'InitializeCommPort' in '_Signal_Generator' of 'Active X DLL Drivers For DLB and Shockwave'

ActiveX component can't create object

Source: DLB_Driver

I'd say this is actually a problem with our installation of our DLL, and not TestStand, but thought I'd see if anyone has any idea why we are running into this problem.  We all have identical computers - same OS (win XP Pro), same hardware, same software, same DLL (installed on all computers from the same network drive source.)  We followed the same process to load our test software on each PC.  We tried to unregister and re-register the DLL, with no success.  Any ideas of what else we could try to get this to work on all of our machines?

Thanks!

-Bill

[TerryS]

Hi Bill,

Are you able to call that DLL and function from another program, i.e. C/C++, VB, etc, without receiving this error?  Or, do this only happen when you call it from TestStand?

[parkerfly]

I don't have anything else on that PC from which I know how to call that DLL, but the exact same installation (same OS, DLL version, PC) works on 3 other PCs that we have... We also tried to unregister/register both the DLL, and the MSCOMM active X control with no success...

[TerryS]

Hi Bill,

Do you get an error when you try to call any function from that .dll on that computer or just this function?

Try to run the attached example.  It has a sequence that creates an ActiveX object that communicates with a VB .exe.  Let me know if you receive the "Cannot create ActiveX object" error.

Message Edited by TerryS on 10-11-2006 10:57 AM

[parkerfly]

It also fails when calling other functions from that dll -see attached jpg for another example.

Your test code did run successfully - no errors....

[parkerfly]

One other thing to consider, and I don't know if this has any bearing on this, but having admin rights may be an issue?

On laptop 1, I have admin rights and installed our software on it.  Another engineer that does not have admin rights on that laptop can successfully run the test software.

On laptop 2, I also have admin rights and installed our software on it, same versions, same procedure.  A different engineer that does not have admin rights on that PC can't get the test software to run.

On laptop 3, a different engineer has admin rights, and installed the same software when she was logged in (I walked her through it, so same procedure) and she can't get the test software to run on that PC.

I don't know if this has any bearing on the problem we are seeing, but thought it was worth mentioning...

-Bill

[TerryS]

Hi Bill,

Are all three laptops identical, i.e. specs, system settings, etc?  There has to be a system setting or installation error that is causing these differences.

Is it possible for you to post the .dll that you are calling, so I can test it out?

[parkerfly]

Yes, all of them should be identical.  We got them all at the same time a few months ago, and nothing should have been done to change any of them.

I'm still trying to get permission to send the DLL out, but something else that may add some insight - I created a labview VI that could control our external hardware from the serial port, works with no problems on my laptop.  When I put it on one of the machines that gets that TestStand problem, I get the attached error message.  I also attached the vi.

I'd assume that labview accesses the com port in a different manner than our DLL does (the DLL was written in VB, so it shouldn't have anything in common with the labview code.)  The VB code that the DLL uses to initialize the COM port is:

Public Sub InitializeCommPort()

Set SerialComm = CreateObject("MSCOMMLIB.MSCOMM")

If SerialComm.PortOpen = True Then
  SerialComm.PortOpen = False
End If
SerialComm.CommPort = SigGenCommPortNumber
SerialComm.Settings = "19200,n,8,1"
SerialComm.InputLen = 1
SerialComm.RThreshold = 1
SerialComm.PortOpen = True

End Sub

It has to be something with the COM port setup in some of our laptops, but I don't have a clue what it could be.  I compared all the settings for COM1 in the device manager on a working and non-working laptop, and everything is the same... any ideas of what else I could look at?

[DWeiland]

Have you ensured that the COM ports on the malfunctioning laptops are working properly?

First and foremost I would recommend doing a simple loop back test to ensure there isn't a hardware problem. You can find instructions on loop back tests here:

http://digital.ni.com/public.nsf/websearch/E22DA85E97818DE78625678C0069BFC9?OpenDocument

Hope this helps.

Message Edited by DWeiland on 10-20-2006 04:45 PM

[parkerfly]

I haven't tried a loopback test, but we have successfully used a different program through the COM port that does not use our DLL on those PCs...