Serial Comm Problem and cvirte.dll

[cobra kai]

After creating an installer for my application and deploying it on various laptops for testing, I encountered some inconsistencies across machines.  Namely, 2 of the 4 laptops are having serial communication issues with the target hardware.  My application is simply talking to a DSP via RS-232...these 4 separate machines that I am testing with are not hooked up together or anything...I just wanted to install it on a couple of different machines to see if the operation was consistent...and it was not.

On the 2 "problem" laptops the communication issues does not occur all the time, but it does occur most of the time.  On the 2 "good" laptops the communication problem does not occur at all.

All the laptops are Dells running windows XP not more than 2 years old, but the 2 "problem" laptops are the same model.  I can avoid this problem here in the lab by not using certain laptops of course, but this application will be going to the field where I will have not control over the computer this is being installed on so I am trying to get the root cause of the issue.

Now the problem:  My Lab Windows application is initially able to send and receive data over the RS-232 port, but something is happening where nothing more will then be transmitted from the Lab Windows application via RS-232.  The application is otherwise functionally properly, just nothing is physically transmitted out of the COM port (verified with a scope).  All incoming communication is fine.

Most of the time I will get some error at start up saying there is an error in my .exe and also refers to cvirte.dll, but there is not error number or much more information than that.  The error dialog also points me to a temp file it creates that I guess contains some information about the error, but it is pretty cryptic to me...see attachment.

So basically my application works great on some machines (no error dialogs and no comm problems) and not well (error dialogs and comm problems) on other machines.  All application installation were made from the same installer file.  I am using the ComWrt function for serial communications.

See attachment for temp file containing error information.

Any assistance would be greatly appreciated

Brian

[Wim S]

Hi Brian,

I'm having the same problem in my company (just to let you know that you're not alone  )

We have a driver board that we can update (firmware and embedded software) through RS232. To do so, a binary file is sent at 57600 baud, no parity, no handshaking. The outputQueueSize parameter of the OpenComConfig function is set to 50. After each block of 4000 bytes, the driver boards sends a checksum. On some of our systems, we get checksum errors, which means that there has been a communication error. On other systems everything works great. The checksum errors appears after a random number of blocks, sometimes the updates completes without any errors...

I never get an error at startup, like you do...

A colleague of mine wrote a small tcl script to do the same thing. With this script, no errors occur .

Message Edited by Wim S on 11-12-2007 04:15 PM

[cobra kai]

Yeah, that is one of the things we are using our RS-232 communication for too...but when my failure occurs I am not getting nearly as far as you.  Although my application is running through the functions to send data out of the COM port (as far as it is concerned data was sent) nothing is leaving the physical port so my DSP never see any kind of attempt to communicate...it is like the output of my COM port gets frozen...

[Wim S]

Are you using any handshaking? And what is the size of your output buffer used in OpenComConfig? I just read in the help that you can disable this buffer by setting it to a negative value. Then the data is written directly to the serial port. I'm working on that now to check if I get any improvement...

[cobra kai]

I am configured at 115000 8 N 1 with no handshaking and and output buffer of 32000 (which is much more than it needs to be).  I will try adjusting the buffers and see if anything changes.

[menchar]

Are you using CVI 8.1?

NI re-wrote the rs-232 library to target "real time" systems and they have changed the behavior of the rs-232 library Vs. 8.0 and previous.

We have an implementation that works with CVI 8.0 and earlier, but fails with CVI 8.1.  

My suspicion is that our serial port implementation is intolerant of closely spaced frames and that with the 8.1 rs-232 library it gets overrun and drops frames.

It sounds like this might be your issue.

Menchar

[Wim S]

Hi Menchar,

Yes, I do use CVI8.1. Is there a fix for this solution? Should I revert to the 8.0 rs-232 library?

[cobra kai]

I am using CVI 8.0.1.  Would it make sense to try an earlier version of the RS-232 library?  Are these "older" libraries freely available?

[menchar]

To my understanding, NI re-wrote the rs-232 library, which is part of the CVI runtime engine, for CVI 8.1.  The reason they give is to get better performance for "realtime" applications.  NI is claiming they can get "realtime" performance out of PC hardware if certain contraints are met.

A consequence of the rs-232 library changes in 8.1 has been that weak rs-232 implementations fail.  In our case, we have a serial port implemented in a Xilinx FPGA that isn't well done - I think it fails to manage the incoming byte stream quickly enough and gets into an overrun situation and drops frames.  We get checksum errors.  Several users have reported problems with rs-232 and CVI 8.1

I suspect the changes NI made have reduced the time in between frames, though this is speculation on my part.  They use the standard Windows serial driver, so there's relatively little they could have done to change anything else.  It could also be that they burst more frames at a time too I suppose when you output large buffers.

We have some serial port implementations that work just fine with 8.1, and some that don't.

There is a known race condition in 8.1 where if you have an output queue and you make a FlushInQ () call with characters in the queue, a race condition comes about and you can get a GPF.  So NI typically says "don't use an output queue".  You can specify -1 in the outqueue size in OpenComConfig.  NI says this will be fixed in the next CVI release whenever that is.

So if you have a serial port implementation that you suspect might not be up to snuff, you could try 8.0 and see if that "fixes" it by not stressing the serial port.

Menchar

[Mert_A.]

Just to clarify, the implementation of the library on Windows went through some changes going to version 8.1, but these were subtle changes not intended to change the semantics of the library.  Menchar mentions a GPF condition which unfortunately was also introduced (and is fixed in the coming release).  The changes were made to better accomodate a parallel implementation of the library for real-time (i.e. CVI RT) machines, but the two implementations are mostly separate.  The addition of the implementation for real-time platforms does not provide any new real-time capabilities to the Windows implementation.

Mert A.
National Instruments