Testimonials

Hello,

I purchased COMM-DRV/CE for $189.95 on Sept 27, 2005. Everything is working great. I was wondering if there were any upgrades you would recommend?

Thanks for such a great product!

Scott Marhefka
eng@npas.com

Thank you for all the support

I got the problem fixed.

I again removed the COMM-DRV++ program and removed all traces of the dll, I also commented out all the code and removed all the cdrv*.lib and the cdrvppport.h from my project cleaned and rebuilt it.

Reinstalled the COMM-DRV++ program and copied all .lib and the ".h" into the project removed my comments and cleaned and built the project.

no "time expired message"

So thanks again, it was very surprising in this day and age to get that kind of support Keep up the awesome work.

Cheers,

Jim Doyle
HLS HARD-LINE Solutions Inc.

WCSC,

 A month or so back, I called tech support regarding a problem with ZMODEM file transfers.  I was really puzzled because I had been using the CommDrv/Lib product for many months and had a ZMODEM file transfer function already in place and functioning.  I recently changed the way I was handling file names and about the same time, I started having problems with file transfers.  Most of the time, the file would seem to start, then quickly abort. 

 I talked to Edgar concerning this behavior and with a few simple questions answered; he was able to assist in resolving my problem.  He explained the process in which ZMODEM performs its handshaking and determines what action to take on a file transfer.  It seems that many of my files were identically named and existed on the target PC.  A few modifications to directory management and our files were transferring just fine again.

 I really appreciate his understanding the urgency of solving this problem and his desire to see our application back to normal operating capabilities.  Our Unmanned Aerial Vehicle (UAV) is back on schedule and our application has a robust data link. 

 Thanks again Edgar,

David Kanazawa

david.kanazawa@nrl.navy.mil

CACI

Naval Research Laboratory

Washington, DC

Hello Again,

Thank you very much for your excellent advice concerning the RS-232 character latency delay in Win32!  I sincerely appreciate the time that you took to write this detailed and quick response, knowing that it may not even lead to a sale.  I am very impressed with your fine technical support and knowledge, and will consider your company first whenever I need to purchase serial hardware or software.  I will also highly recommend your company to all of my friends and colleagues who work with serial devices.

Unfortunately, (due to use on a wide variety of hardware platforms and operating systems) I am unable to use COMM-DRV/NT for this project, but I will consider it whenever possible.  I also may need to purchase one of your USB/Serial multiport devices or the SI-Scope software in the future, so hopefully, your kind efforts will soon bear fruit for WCSC.

Your advice about the Windows COM driver delaying the interrupt for three character times when the FIFO is not full is absolutely correct.  In doing extensive research on the internet with Microsoft, developer-oriented web sites, etc., nowhere did I find this fundamental driver behavior explained.  WCSC obviously knows the Windows drivers better than most of the people at Microsoft do!

I had actually played with the FIFO settings several days ago, as a potential fix to this problem.  However, I did not reboot the PC after making the change.  Usually, people in Redmond have to reboot their PCs just to change the TV channel they are watching, so I should have known better!  I suppose that Microsoft may have begun to suppress the infamous "You must reboot your PC for these settings to take effect." message boxes, in order to counteract this perception.  However, it is nice to know when a reboot is really necessary, and I should not have been naive enough to assume that this setting could be changed dynamically.

By the way; it may be of interest to you to know that the cheap, consumer-grade Belkin USB-to-serial adapter that I was experimenting with did not behave any differently when I changed the FIFO settings, even after a reboot and re-enumeration.  I have heard from many sources that the drivers for these low-cost devices are poorly developed and do not support many RS-232 modes beyond the plain vanilla "8, N, 1, no parity" modes, and this seems to be the case.  I would bet that many of the settings for these devices are either ignored or simply non-functional.  Knowing this, I will always be sure to use your USB adapters for production line use and any other circumstances.  In the past, we had contemplated using a low-cost USB adapter on a production line, but, in retrospect, this would just have been an invitation to receive more 3AM "wake-up" calls from production.