Serial transmit hangs unless app was just compiled

[mike118]

I am using a PCI-485-8 card under Windows 2000 and developing my app with VC++ 6.0. My app is opening two of the eight 422/485 serial ports (COM8 and COM10). If I have just compiled my application, everything works fine. On subsequent attempts to execute the same exe, execution hangs on a call to WriteFile. If, instead of using COM8, I use the RS232 COM2 or COM1, there is never a problem. What is even more peculiar about this is that the WriteFile call is being made on COM10. It appears that the state of the ports when two (or, I suppose, more) of them are utilized is being messed up. But why does a recompile of the app fix the problem?

[DiegoF]

Hi,

What NI-serial version are you using?. The lastest version is NI-Serial 1.45 and is available at:

http://exchange.ni.com/servlet/Redirect?id=8899629


I don't see how the compilation would *reset* the serial driver or hardware. When you execute the program, do you run it from the VC++ IDE or separately?. Do you run it using the debugger?. Does this happen on other systems?.

Also, just to complete the info. What service pack do you have installed?. The lastest is SP 3 for Windows 2000.

Could you attach a piece of the code you are using?. If you have a very simple example the reproduces the behavior that would be great.

DiegoF
National Instruments
www.ni.com/ask

[mike118]

I'm baffled by this too. In answer to your questions:
1) I'm using NI-Serial 1.45.
2) I'm running in the IDE only.
3) When I run it in the debugger, the problem goes away!
4) I do not have the opportunity to try it on another system.
5) I upgraded to Windows 2000 Service Pack 3; it made no difference.
I've attched a stripped down project that exhibits the same behavior. The output following compilation is to the DOS emulator window. When you exit from the program and restart, the DOS window pops up, but no data. I tracked the hangup, using printfs, to the WriteFile call in serialComm.cpp. Thanks!