Delphi open source component: TComPort

The TComPort component was originally written by Dejan Crnila, it was modified a bit by other people, including me, among others. It didn't need much tweaking, other than a bug fix here and there, and support for new Delphi versions as it came along. The latest version 4.11b is available on SourceForge here.

Like a lot of developers who need to do serial communication, I started using Turbo Power's very capable AsyncPro product, which is still alive, and doing well. I have said some negative things in the past about AsyncPro, because the complexity in it mixed poorly with the complexity in my products, and when I had to debug things, I found it really hard to debug AsyncPro. But I should introduce a policy here on Delphi Code Monkey; I intend to publically do penance for stupid things I have said in the past. AsyncPro is a fabulous component set, and nothing negative I have said in the past should be held as more correct than the simple fact that lots of people use, and still use AsyncPro, and are happy with it.

Nevertheless, as a person who believes strongly in the "smaller is beautifuller" concept, almost to an absurd degree, and who has found that the less code I put in my application, the less my application breaks in horrible ways, I still prefer TComPort for the cases where I need to do serial communication in a delphi app.

TComPort seems like exactly what I needed for my purposes. So what were my purposes? I wrote applications that did the following things:

1. Talk to industrial or scientific or laboratory equipment, over an RS-232 or RS-485 link. Some of this equipment including Programmable Logic Controllers, using a common protocol called "Modbus RTU", or simple Ascii (text based) serial protocols, some with, and some without checksums. For modbus capable PLCs, I wrote a descendant component that does Modbus client communications, for Delphi, that can talk to a wide range of industrial and process control, and scientific equipment that implements this protocol.





2. Talk over a direct cable link, or a modem link, to equipment at a remote site. This is incredibly powerful. One application I wrote in the mid 1990s had dialup remote control of an emergency power grid that could be remotely activated by the power utility company in a major midwestern US city, whenever the grid needed additional capacity.





Here are things that I didn't need TComPort to do, things that would make AsyncPro a better choice than TComPort:

3. I did not need a full featured "video terminal emulator" that did fifteen different terminal emulations, including a reliable VT-52, or PC ANSI terminal emulation. You might need this, if you had to connect to an old computer system that provided serial terminals.

4. I didn't need to use the file transfer protocols from the BBS era, that include XModem, and ZModem.

Back in the DOS and BBS days, long before the Internet, those of us who used to "go online" used to do so using DOS programs called "Terminal programs", and plastic boxes called "modems", that let your plain old phone line talk at incredibly high speeds, between 300 and a few thousand bits per second. Just about everything that you could do in Telix, you can do in AsyncPro. AsyncPro (formerly from TurboPower, now open source) is better than TComPort, if you need a full featured video terminal emulator, or x/y/zmodem file transfers. If you still wanted to write a Telix for Windows in Delphi, Async Pro would be perfect for you.

So having given AsyncPro its due, let me proceed to why I like TComPort:

A. Small, Fast, Light.
B. Simple thread and event model.

One common place that serial ports still show up these days is in the IT world. Sometimes you might have a network router, or VPN box, that has a serial terminal that you might want to talk to. At one of my old workplaces, we had a building alarm system that had a serial port cable. We logged the alarm activity on our servers, using a little capture program, originally in VB, which I rewrote in Delphi.
Just because.

If you want to drop a component on a form, and talk through a serial port, check it out. Your programs can remotely interact with, control, or supervise a wide variety of equipment out there. You could even attempt to write the Auto-Dialer that figured so prominently in the 1980s movie War Games. Please don't hack our national electrical grids though, or I will have to hunt you down and give you a wedgie. Also the CIA and FBI might want to talk to you. Be good. Thanks.

If you have problems with this component, you can talk about it on the forums on sourceforge, and we'll try to help you out.

I could use a little help getting the component working again in C++Builder, so if you're a C++Builder expert out there, please check in with me. We need you.