Use ZylSerialPort component to easily communicate with external devices on serial port connection, such as modems. - support for Delphi/C++Builder XE7.

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. 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. 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. 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! – May 30 '11 at 13:29. 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: • ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to. • 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: • Certain timing changes cause the USB device driver that was failing, not to fail. • 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.). 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.

Little Fighter 2 1 9c Executive Orders. – May 27 '11 at 15:28. 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. – 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. Altium Designer 10 0 22 Keygen Software 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! – May 30 '11 at 13:22.