Clinto

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.

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.

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.

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.

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