ComWrt problem

[Humph]

Hi. I'm using LabWindows/CVI 5.0.1 and have been asked to add a serial line device. It's not working as expected and seems to demonstrate the problems described by others of Windows not sending the characters immediately. I've read all the problems about multi-threading in later upgrades and setting the buffer size to -1. My understanding is that this won't help or is not an option in 5.0.1. My question is: will adding a ProcessSystemEvents () call AFTER the ComWrt call force the output of the bytes directly. My code wants to issue a 6 byte character string then wait for a 12 byte string from the device. So will the sequence ComWrt, ProcessSystemEvents(), ComRd work as expected?

[GlennPierce]

The CmtWrt documentation says that the processor is interrupted to send the data that is sitting in the output queue.
If you want to make sure the data is sent before execution moves on monitor the output queue.

i.e. something like

// Pseudo code

while(OutQueueLen() > 0) {
    Delay(0.001);
}

If you have multiple threads writing then make sure you are using locking to keeps the writes separate.

Message Edited by GlennPierce on 12-21-2007 06:52 AM

[Humph]

I'm now thinking that this might be a ComRd problem, do we need a new thread? The ComWrt and ComRd I mentioned are contained in a Timer CallBack Routine running every 40 msecs. I removed the ComRd from the loop and the eventdata2 in the Timer CallBack parameters shows a rock steady 40 msecs. With the ComRd back in, it lengthens out to 120msecs. The hardware guys insist that they can see 6 bytes written and within a couple of msecs 12 received from the device. Is there any way I can monitor this by software?

[ebalci]

Hi Humph,

I personally solved the problem by setting the write buffer length to -1.
But if it did not work for you I know by experience that calling a delay function causes the waiting bytes to be sent to the COM port.
Therefore, the pseudocode suggested above should work fine.
You can use GetOutQLen function to get the number of bytes waiting on the output buffer.

Hope this helps.

[RobertoBozzolo]

Hi Hump,

we very often are using timers to handle serial communication and ALWAYS have ComWrt and ComRd in the same function without need to spawn different threads for writing and reading from the port.

Setting serial output buffer to -1 is indeed a solution as it writes directly on the output port without passing through OS driver, thus removing one possible cause of delay in transmission. Unfortunately as far as I remember this possibility was introduced starting from CVI 5.5, so no luck for you in this case ... Couldn't you upgrade your development system?

We use two different methods to handle serial communication: the first simply has a fixed Delay () after write and uses GetInQLen () to determine if a valid response was received from the device. One slightly more complicated system uses a loop after ComWrt: the loop exits either for enough characters recevied from the device or for timeout.

In a few occasion I tried using outp () instead of ComWrt in the seek for a more deterministic way to write to the queue: the system is indeed working but I am not sure to have achieved a significative improvement in that direction. Anyway, in that cases writing function was structured as follows:

int    j, x;
char    msg[32];

strcpy (msg, "string");
//ComWrt (com, msg, 6); 
for (j = 0; j < 6; j++) {
  outp (IOadr, *(msg + j));
  for (x = 0; x < lup; x++);
}

where IOadr is the phisical address of the com port, as can be viewed in device manager (normally 0x3F8 for Com1 but it depends on your hardware confuguration). The loop in x introduces a very small delay between one character sent and another.

Message Edited by Roberto Bozzolo on 12-24-2007 05:46 PM