Getting error 1172 when trying to call a DLL

[Clinto]

I have a truly international problem! I'm a product development manager in California. I have a team in China that is designing a LabView-based test fixture to run automated tests of a printed circuit board that is going into mass-production next month. A software engineer in Mexico wrote a DLL in C# that LabView calls, then the DLL sends commands to perform some of the tests. We sent the DLL from Mexico to the engineers in China, and every time LabView calls the DLL, we get error 1172. I attached a Word document that I received from the engineer in China that describes the problem. It has screen shots that illustrate what he is seeing. (Don't worry - the Word doc is clean. I have opened it and viewed it and scanned it for anything malicious. It is clean.)

I hope the attached Word doc has enough information to help somebody diagnose the problem. If you need more information I will provide it ASAP - but there will probably be about a one-day delay, because I have to forward the questions to the team in China, then get their reply the next day, then post it here.

Here is a bit of information that might be relevant that is not described in the attached word doc - it is about the communication channels (plural) between the PC and the DUT:

The printed circuit assembly that we are testing is installed in a bed-of-nails fixture. The primary channel of communication from LabView/PC to the test fixture is via good old-fashioned printer port. (We toggle lines high and low on the printer port to send commands to the test fixture. And responses come back via lines being toggled high and low.)

But the DLL is written to communicate with the board under test via a second communication channel. The DLL communicates through a USB port on the PC. We have a device plugged into the USB port that converts USB to serial (RS-232) and then the commands from the DLL are sent directly to the board under test via serial. I.e. the channel for DLL commands is: LabView --> PC --> USB --> RS-232 --> board under test

Replies from the board under test are sent back on the same channel: board under test --> RS-232 --> USB --> PC --> LabView.

The attached Word doc mentions a driver from "FT". That is the driver for the serial-to-USB converter (on the little dongle that is plugged into the USB port).

I really have my fingers crossed that this forum can help us solve this problem. The test fixture was supposed to be released to the electronics manufacturer three weeks ago for testing on a pilot production run. Our production schedule is getting hit hard until we can solve this problem. Thanks in advance for any help.

DLL error picture.doc

[vugie]

What from the DLL knows which port to use?

Does it assume some port number? (FTDI base deviced each time they are plugged in, they may appear with different port number)

Is FTDI based device (serial-USB converter) made by you or your partners or it is just a commercial one?

Are serial connection parameters on FTDI properties page set to the same values as the device on the other side of serial cable expects?

I see that FTDI is now in VCP mode (virtual Com Port). Is it a state DLL was written for?

I don't think you should do anything wit FTD2XX.DLL. Only if you want to bypass your Mexican DLL.

[Clinto]

Thanks for the reply Vugie. I will forward your questions/comments to the engineers in China. As soon as I receive their answer, I will post it here.

[Rolf Kalbermatter]

Well, it's obviously the .Net DLL that is doing something wrong. So the first question to me would be, how was this DLL even tested? I would recommend to try to test it for instance with a Visual Basic test program, unless the programmer is willing and able to use LabVIEW himself. It could be a lot of things, from obvious programming errors in the C# code, to setup errors for the type library that LabVIEW then uses to generate the correct interface stubs, to simple setup errors such as the need to first call some other methods in the library to configure certain things, such as the FT communication port to use, before you can run the test method. So the .Net exception could be a bug in the C# such as referencing invalid objects, but it could just as well be an exception thrown by the code on purpose since it can't perform anything without the proper setup information.

[Clinto]

Hi Rolf - thank you for the reply. The C# programmer tested the DLL pretty thoroughly, including downloading LabView 2011 and making sure LabView could call the DLL. That test passed at the development site in Mexico. But when the developers in China tried to call the DLL they get the error. I'll forward your comments to both teams (in Mexico and China) and if they have any questions or comments in response, I will post them here.

[ShaunR]

Hi Rolf - thank you for the reply. The C# programmer tested the DLL pretty thoroughly, including downloading LabView 2011 and making sure LabView could call the DLL. That test passed at the development site in Mexico. But when the developers in China tried to call the DLL they get the error. I'll forward your comments to both teams (in Mexico and China) and if they have any questions or comments in response, I will post them here.

Was the assembly tested on a windows box with a Chinese or Japanese localisation? My first thoughts with Asian-only issues are the problems (and Labviews issues) with Unicode string handling. The problem you have (as Rolf is saying) is you have a black-box that is't happy and no way to tell why it isn't happy (Labview can only tell you it isn't happy).

Presumably the author of the assembly has a test harness of some description. Can you send that out to China and see what error log it produces (if any).

[vugie]

Another common international problem is localized decimal point.

[Clinto]

Thanks for all the responses. This is a great forum.

I'm forwarding all questions/comments to the development team. I'll come back with their replies as soon as I receive them.

[PJM_labview]

Not exactly what you are asking for, but if I understand your description of the configuration, I don't see why you need the DLL in the first place. Just buy one of the various USB to RS232 converter (I personally use Keyspan) then use VISA from LabVIEW to communicate (over RS232) with the DUT. I realize that this is probably not an option at that stage, but I though that I would mention it.

PJM

[Clinto]

Not exactly what you are asking for, but if I understand your description of the configuration, I don't see why you need the DLL in the first place. Just buy one of the various USB to RS232 converter (I personally use Keyspan) then use VISA from LabVIEW to communicate (over RS232) with the DUT. I realize that this is probably not an option at that stage, but I though that I would mention it.

PJM

Hi PJM,

Thanks for the comment.

The code for the DLL calls was already written before we started to develop the LabView app and fixture. It's pretty low-level stuff, using a custom serial communication protocol that we developed for device-to-device communication. And the dongle with the serial-to-USB converted was also already developed as a component in our consumer product. Rather than re-doing all that work, our goal is to just port it over to our test fixture. Unfortunately, LabView and the DLL don't seem to want to talk to each other.