serial communication using CVI

[simbex]

Is the serial communication toolbox in CVI a wrapper for the Windows SDK serial functions?  What are the benefits of using the serial communication toolbox over Windows SDK serial functions like CreateFile?  I'm having some data corruption occurring in my application where a serial device is streaming data messages (using a proprietary protocol).  I do not believe the protocol or hardware is at fault since I can use a non-CVI based application and the data seem to be correct.  My CVI application also requires multiple file I/O operations to occur.  What is really confusing is that if I remove the file I/O operations from my CVI application, the occurrences of data corruption seem to be significantly lower.  Any thoughts?  I notice that the CreateFile Windows SDK function is used for both serial and file I/O and I'm wondering if this is why the two seem to be related......

Any help is much appreciated.

Jeff Chu

[TerryMoss]

It sounds as if you are having interupt problems.  Are you using a CVI Callback function to respond to the serial port?

Terry

[simbex]

I'm using InstallComCallback ( with a receive event mask set at 13 bytes, my messages range from 7 to 400 bytes) with a CVI callback function.  After further debugging, it also appears that the callback stops funcitoning  - I can place a breakpoint in my callback function and I never get there even though I know data are being sent to the serial port.  I've added a GetComStat() function that I poll periodically to see if anything bad is happening and it appears that everything is working fine.  Strange stuff.......

Thanks,

Jeff

[jr_2005]

I've only used the serial libraries a few times for my CVI programs, but I never did get the hang of the COM callbacks - I never could get them to work as I expected. So now I don't bother with them. I use a combination of conventional Timer callbacks, a decent input buffer size, GetInQLen() and ComRdByte(1) functions to tailor my applications and have never looked back.

JR

[TerryMoss]

That is strange.  If you can reduce the CPU load by disabling the file saving with a resulting increase the performance of the UART, then It sounds as if its some kind of setup with the UART, and performance of the CPU.

I use it in my application, and it it runs 24/7 with no problems, with all kinds of other things going on with the PC.   The one difference in my code is that I'm always looking for a carriage return before the call back activates.

I have seen other SW that misses data in the buffer if the data comes to quckly.

I would in increase the buffer size to a really large value to reduce the frequency at which the call back is activated, and see what that does.

Terry

[simbex]

Thanks for the input.  This is definitely a bizarre phenomena that I'm seeing and is something I haven't encountered in the past.  My serial buffer size is huge 65k  and I have multiple threads running in the background, although all the I/O operations (i.e. serial and file) are in the same thread.  The other strange thing that I'm seeing is that the Com Callback seems to stop functiong after some time (not sure if it also related to data throughput).  I know this is occurring when my notice my application stops functioning properly and I put a breakpoint in my callback routine (I know my hardware is still sending data) and I never get to my breakpoint.  Given this, I'm beginning to wonder if the callback routine is reentrant.  If it was, this would certainly be the cause of my problems.  My callback routine reads data from the serial port and copies these data to a circular buffer where another routine checks message integrity and processes the message as necessary.  This would certainly cause my data corruption problems.  Also, I noticed that using an InstallComCallback with a Receive Mask of n bytes requires the serial buffer to go below this threshold and then back above it to cause a event trigger.  With reentrant code, I may not be reading the serial buffer at the right instance in time causing the event trigger to never happen again.  Any thoughts?  All your help is much appreciated, this has been a very frustrating debug session.

Jeff 

[SoaringPingu]

Hi, This is an old post, but did you ever fugure out what the problem is? I'm getting the same problem and I have been thrawling the forum and so far found 2 people with the same problems, but none of the threads offer an eplanation to what is happening, so I'm still stuck with a com port callback that stops working after about 1 hour...

Cheers,
Mattias

[Sarah_R]

Mattias,

What version of CVI are you currently using?

Please let me know. Thanks

[simbex]

I never really found a good solution to this problem.  I ended up adding an async timer that polled the port at a predefined interval, not a great solution since it wasted cpu cycles, but a very predicatable and stable one (better tradeoff).  I was using CVI 7.0.

Jeff

[Mert_A.]

There was a bug fixed (305GPSQ6) between version 7.0 and 7.1 that was related to the RECEIVE event not being fired in under certain "data race" conditions.  Essentially, before the fix, if you responded to a RECEIVE event by reading only the number of bytes for which you were notified, and more data comes in before the callback finishes, then it's possible the input queue size may never drop back below the threshold count, so you will not receive further RECEIVE event notifications.  Low threshold counts are especially susceptible to this problem.

You can try upgrading your runtime engine to 7.1 or later to see if that fixes your problem, or you can ensure that you are always completely emptying the input queue in your callback function.  Doing the latter ensures that the input queue length drops below your threshold, and will re-enable the event notification.

Hope this helps.

Mert A.
National Instruments