Serial Comm Problem and cvirte.dll

[menchar]

I should have stated FlushOutQ ( ) , not the in queue.

The changes may have been small, but I can guarantee you there's a difference that affects our (probably poorly designed) Xilinx serial port.

Menchar

[Wim S]

I suppose a possible solution would be to use ComWrtByte in a loop, instead of ComWrt. But I'm afraid this would seriously slow down our update process, since the files we are sending are sometimes close to 1MB

[menchar]

We might do that very thing so as to be able to move forward with the CVI version rather than stay frozen at 8.0 because some goober doesn't know how to do a serial port in VHDL.

We'll be in a position soon to put an analyzer on the port and figure out what's really happening.

Do you see a difference 8.1 Vs. 8.0 or earlier?  With us it's very dramatic.

You may be able to run your 8.1 developed app using the 8.0 runtime engine, so long as you didn't use 8.1 specific features.

I suspect that if you're licensed with 8.1 there's some way to get an older version of the full IDE.  I am able to do that but we are on a volume license server here.

If you don't see a difference 8.1 Vs 8.0 or earlier, then you have some other problem.

Message Edited by menchar on 11-14-2007 11:08 AM

[Wim S]

A few days ago I installed CVI8.5, and recompiled my project. Unfortunately, the RS232 problem has not been solved. Now, I use ComWrt in a while loop. In each loop, I send 10 bytes and wait for the output queue to be empty before starting the next loop. This seems to work much better, without any significant loss in speed.

Still, we did not have this problem when using CVI7.1 and CVI8.0

[menchar]

This all makes sense if you have a serial device that's not able to keep up with a fast incoming data stream and when there's no flow control of any kind.

Sure sounds as if you're overflowing the input buffer on the device.  The delay allows the device to work off the incoming frames and keep pace.

CVI 8.5 RTE has the same changes to the rs-232 library that NI made at 8.1.

Menchar

[Wim S]

We do have a flow control system to prevent input buffer overflow on our slave devices. When the input buffer is filled up to a certain level, the slave sends a warning message to the PC, which then pauses the byte stream, until the slave sends a new string, saying he is ready to receive more data.

I think it's more likely that the slave misses bytes because of a small error on the bautrate, as you suggested in one of your previous posts...