7

I am developing Delphi application on Delphi 2010 XE RAD Studio under Windows 7. My application talks on the serial port non-stop. I am using AsyncPro for Delphi 2010. Serial communication and everything else on the computer I develop with works great without any problem. However, when my release version of my application is run on another Windows 7 system, serial communication completely fails. We probed the serial communication itself for an answer and found out that Request to Send (RTS) line is not dropped right after sending all the bytes, whereas on my development computer RTS line is dropped correctly.

Even when I explicitly drop the RTS line to low or false state, RTS line doesn't drop right away but after good 15 milliseconds. Thus, serial communication on my release version is failing.

Am I missing important information about Windows 7 and serial communication issues?

UPDATE: I just found the bug with my Aysncpro 5.0 for Delphi XE. It is weird. When my Delphi XE IDE is open or running, my program is communicating flawlessly. When I shutdown or close my Delphi XE IDE while my program is running, the same program doesn't communicate very well or it times out.

Chime in if you have any idea why it is happening.

Any help will be appreciated.

Thank you,

dsolimano
  • 8,870
  • 3
  • 48
  • 63
ThN
  • 3,235
  • 3
  • 57
  • 115
  • As I said, AsyncPro is what is happening. :-) Now you know it is a bug in async pro. Your inability to get the TComPort demo working is probably simple and trivial to overcome. Ask a question about that and I'll post a working demo for you. – Warren P May 28 '11 at 14:34
  • Is your application using BPLs (runtime packages)? – Warren P May 30 '11 at 05:08

3 Answers3

5

Last few times I saw random inexplicable crap like I tried everything, and was unable to solve it for months.

I found two different common causes:

  1. ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to TComPort.

  2. I found all kinds of strange flow control bugs in USB drivers. I found FTDI chipset USB-to-serial more reliable than others.

The Debug build not having the problem could be two things:

  1. Certain timing changes cause the USB device driver that was failing, not to fail.

  2. You actually have some kind of a thread problem, like a race condition, leading to your ASync Pro components messing up in a way that looks like something's happening to your port, but really it's ASYNC pro.

The easiest thing to do is to try it with a different USB to serial adapter, and if that doesn't solve your problem, I would be tempted to pull out AsyncPro which I have also had many random problems with, and either write your own serial port class, or use TComPort. I have some long experience using a TThread that uses a com port "reader/writer" class and have found this the most reliable way to go, because you can tweak low level elements of the Win32 overlapped-IO calls, directly to meet your needs, and also be sure that you don't have some extra complexity/overhead getting in your way. (AsyncPro's complexity and overhead, are a significant potential source of bugs.)

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • The thing is, Warren P, we have used AsyncPro for the last 7 years without a problem until Windows 7. Our software is pretty much established. So, we aren't expecting any crap of an issue with Asyncpro 2010. The fact that Aysncpro works perfectly on my windows 7 development computer and not any other Windows 7 system means that there is a difference in the driver or hardware is failing. I am just looking for suggestion or idea for a solution. Thank you. – ThN May 26 '11 at 20:47
  • +1 for TComPort. I've used AsyncPro for years but started to have problems with W7. – Brian Frost May 26 '11 at 21:40
  • What changed it for me wasn't Windows 7, it was the end of built in serial ports, and the ubiquity of USB to serial adapters. I never had trouble with AsyncPro until the vicissitudes of its handling of flow control signalling, and other similar issues, were mixed together with flaky usb drivers. It's also not unheard of to have problems due to a BAD USB CABLE. I have had problems go away from changing the USB CABLE out. – Warren P May 27 '11 at 02:11
  • Well, I tried TComport and the demo doesn't even work on my windows 7 computer. I think TComport is too simple for my application. My program communicates in RS485 mode with DTR enabled on the SerialPort. The program is not sending and receiving acii characters but bytes or hex values. As far as Asyncpro is concerned, is it possible that it is having problem communicating because the user logged in is not an administrator. On my PC, I am the only user and also the administrator. – ThN May 27 '11 at 15:28
  • TComPort is in fact perfect for RS485, and that's exactly what I used it for. More complicated code (AsyncPro) only causes problems in RS485. – Warren P May 28 '11 at 14:32
  • Yeah. I haven't used any components now for some years. I just add in a serial unit I wrote ages ago that uses a TThread + IO completion callback, much the same as yours, I guess. It worked on W2k and still works on D2009/W7 without any code change except string>ANSIstring and many wanings about implicit conversion – Martin James May 30 '11 at 13:41
  • Sorry for the lateness of my reply. Well, I believe I could use TComport in place of Asyncpro, but when I try to even run their demo application it wouldn't send even send out a single byte or a bit. I checked every thing to make sure I wasn't making any mistakes. Still, it TComport failed, but when I run Asyncpro it sends out packets but the RTS line stays up a longer than expected. – ThN May 31 '11 at 12:17
  • So skip both components and write your own Win32 API calls. It's NOT that hard! Open file, write to file handle, close file. Hard? No. – Warren P May 03 '12 at 01:19
5

Sounds like a timer resolution problem to me. I had the same problem trying to write to a USB FTDI driver using an event based timer with timeSetEvent()... When Delphi loads, it changes the timer resolution to less than 20ms, which made my app work fine. When the IDE wasn't running I couldn't get things to work below 20ms +/- 5ms (the default Windows resolution I believe).

To fix the problem, I call timeBeginPeriod(1) in the thread to set the minimum system wide timer resolution.

I believe this affects the resolution of other time based events, because I get better than +/-5ms accuracy on other (non-multimedia timer) wait events in my app when I use timeBeginPeriod().

So, what I'm suggesting is that somewhere in the AsyncPro code it's using some time based event or call back... That would be affected by Delphi's change to the timer resolution when it is loaded. Try calling timeBeginPeriod(1) somewhere in your app when it starts and see if there is a change.

Oh, and don't forget to call timeEndPeriod(1) when your app shuts down.

N@

Nat
  • 5,414
  • 26
  • 38
  • Interesting. On Embarcadero groups there was another issue with time - threads seemed to take 15-30 ms to get scheduled on app startup. I never noticed this because I always create mine at startup & never terminate or make any more. Just out of interest, I put a GetTickCount in a thread ctor in my current app and another GTC at top of 'execute' method. Sure enough, when my UI displayed the difference, I got '15'. Eventually, I tried running my app outside the IDE - '0'. I never had this nasty fiddling with system time with D5! – Martin James May 30 '11 at 13:29
  • Hmm.. my serial port code does not use any explicit timers, just that COMMTIMEOUTS thingy. I don't have any problems with hardware flow control, so perhaps you're right. Time to take apart Apro? – Martin James May 30 '11 at 13:33
  • 1
    @Martin - No need for timers, a 'Sleep(1)' will wait 15.625ms (with common hardware) with the default resolution, ~1ms with the finest resolution. Not particularly related with Delphi too, as Nat pointed out, it's set system-wide. Once an application sets a higher resolution, others use it too. The OP could have the same observation with, f.i. MSN messenger or Windows Media Player or whatever instead of the Delphi IDE. – Sertac Akyuz May 30 '11 at 16:51
  • Really interesting. I have never had much luck playing with this setting. Even increased resolution of timers only makes Windows performance slightly more useful. – Warren P May 31 '11 at 00:51
  • @WarrenP Well, it certainly makes my app perform quite well, I get a frame of data to my USB device 40 times a second with +/-1ms accuracy even on old hardware and whilst running multiple sound streams with (the horribly resource hungry) DirectShow api. – Nat May 31 '11 at 01:25
  • 1
    @Sertac Indeed, any app that changes the resolution can create the same effect. It's probably one of the only api calls left that an app can change that can directly affect other apps. Not really in a bad way, but it does make it hard to debug things sometimes! – Nat May 31 '11 at 01:26
  • @Nat, very interesting indeed. Your a life saver. I am happy to have found Stackoverflow. I added timeBeginPeriod within onShow event and timeEndPriod within onFormCloseQuery and it works. I even rebooted my system and started my program fresh before starting anything else. – ThN May 31 '11 at 12:38
  • Just in case people are wondering where these procedures come from, they are from MMSystem Unit. – ThN May 31 '11 at 12:54
  • ***IMPORTANT OBSERVATION*** After making the changes and running it for awhile, I noticed that once in awhile RTS line stays up for 15 milliseconds or longer. Thus, my serial communication times out say for every 50,000 good communication there are at least 100 timeouts. I thought should say something about that. Thanks again for the help. – ThN May 31 '11 at 14:07
  • @WarrenP Doe not surprise me at all! It would prevent a number of mechanisms that are used to allow the processor to throttle down. – Nat Nov 12 '13 at 03:40
1

This has to be a driver problem on the other machine, surely? Hardware flow control works fine on my W7 test box as well, (and Vista development machine). If your Apro has set the DCB correctly, and it sounds like it does because of your 'manual' tests, the driver should work...

15ms for a 'manual' RTS change from user mode is sad, but not at all unusual on Windows - that's why the driver should do it.

Rgds, Martin

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • after spending at least a whole day testing and testing. I have found the bug. My program communicates correctly when the Delphi IDE is running, but not when it is shutdown. Somehow a important library or file linked to the Delphi IDE is loaded at the start of an execution. That file is needed for my program to communicate correctly too. After rebooting my system, I started my application and it fails to run by itself unless the Delphi IDE is running. What do you think is the reason. – ThN May 27 '11 at 20:23
  • 1
    another IDE funny:( I've stopped running anything other than actual manual debugging from the IDE. I used to just hit 'F9' at the end of the day and see if my app was still running in the morning. Now I find the EXE with explorer and run it fromm there. The IDE certainly injects a couple DLL with threads on 'F9', but what they might do to affect the funtionality of COM ports I have no idea, I'm afraid. Still, one more thing for me to be wary of, so thanks, even if I have no answer for you! – Martin James May 30 '11 at 13:22