Frequently Asked Questions - Honeywell UMC800 Reference Manual

3.6 Frequently Asked Questions

"Why do I get a stream of zeroes out of the port when I try to write to it?"
If the DCB (device control block) of the port has not been written since the computer was booted, you will
get garbage out of the port. CElnApi::SetUpPort writes the DCB; call it at least once and the problem
should disappear. Note: you cannot set up an open port.
"Why do I get physical errors every time I call CElnApi::TransCeive?"
Did you remember to open the port before attempting to transmit? Did you remember to check the return
value from CElnApi::OpenPort? Don't assume that OpenPort will succeed. If you try to open a driver that
is attached to COM1 and your mouse is on COM1, the system will not give you a handle to the port. Ditto
if another concurrently running app or thread is using the port.
"Why does my message from the computer to the instrument get cut off in the middle?"
The timeout (the second argument in the constructor) is used both as a receive timeout and a transmit
timeout. In other words, when you call transceive, the message from the computer to the instrument must
be sent in less than timeout milliseconds. Otherwise, NT will assume that something has gone awry with the
UART. When the instrument replies, the reply must be received in less than timeout milliseconds.
Otherwise, we assume that the instrument that we are talking to is not there.
When calling the constructor, consider the longest message you expect to send and the longest reply you
expect to receive. Set timeout to a number slightly greater than the larger of the two.
"Can two CElnApi objects exist simultaneously, each on a different port?"
Yes.
"Can two CElnApi objects exist simultaneously, both on the same port?"
Yes, but only one CElnApi object will be able to open the port at a time. This is true whether or not the
same thread owns both objects.
"Can I spawn a thread, then pass it a pointer to the app's comm driver?"
No. Two concurrently running threads cannot access the same CElnApi object simultaneously. Instead,
pass the constructor and initialization arguments to the thread and let it instantiate its own CElnApi object.
The thread's driver can be attached to the same port as the app's driver, but only one of them will be able to
open the port at a time. In fact, as a general rule, Windows NT disallows the practice of two concurrently
running threads having pointers to the same object. If you do this, NT will generate an exception.
"If I dynamically allocate a CElnApi object, will it use a lot of heap space?"
No. The driver does not maintain an internal receive buffer; you must supply a pointer to an external
receive buffer when you call CElnApi::TransCeive.
"What happens if a CElnApi object is destroyed before it closes the port?"
The CElnApi destructor handles this automatically.
"Will the driver work with Windows 3.1?"
No, it's 32-bit code.
8/99 RS232 Communications Reference Manual
PC Communication Driver
Continued next page
23