A serial port program to read data from external hardware.
This has good information, and a search button at the bottom of the page.
Please don't dismiss it because it isn't full of graphics, scripts, cookies, etc!
Click here if you want to know more about the source and format of these pages
Delphi Data Logging
This tutorial was put in level 5 for a number of reasons.
-- It relates to a large program.
-- As delivered, it requires that you have an external serial device. (You don't need one- see below.)
-- As delivered, it requires that you add components to your Delphi compiler.
-- There are bits of the coding which I am not 100% certain "work" every time!
So much for the bad news! The good news is that the sourcecode is provided, and you can get lots of good stuff out of it, if you will pick through "the bones". It would also be possible for an intermediate programmer to re-write the program, fixing it to read data from another source. Alternatively, this program might be your way into the world of serial i/o.
The work was done using Delphi version 2.
In a nutshell: The program is an interface to either of two devices which save you trouble. They are "little boxes" which, on one side, "talk" to your pc via a serial port, while on the other side, they take care of reading values from 1-Wire chips on MicroLans. They also have digital inputs (and, on the WeatherDuck, outputs). They are Peter Anderson's TM#128 and the WeatherDuck.
The TM#128 can read a variety of temperature sensors, e.g. the DS1820. It can also read the 1-Wire quad ADC (DS2450), the 1-Wire dual counter (DS2423), and the multi-use "battery monitor" (DS2438). You just plug them into the TM#128, plug it into your serial port, send a byte to the TM#128, and it "replies" with what each of the sensors attached to it are reading. It Just Worked the first time I ever attached one to my PC. No configuring. No hassle. You can change sensors between "Tell me what you see" requests.
The program.....
N.B.: If you tell the program that you have a WeatherDuck attached, the RTS and DTR output lines will be set high!!! (The WeatherDuck takes its power from these.)
You can just run the exe which came with the sourcecode. The PC involved doesn't need anything beyond the exe and the relevant external hardware. If you want to "play" with the software, feel free to connect a second computer, and run Hyperterminal in that.
When the program runs, it auto-detects any not-in-use serial ports. First select which sort of hardware you will be working with. (If you are using a second computer, use it to pretend to be a WeatherDuck.) You select the serial port your external hardware is connected to, and click the program's "Open Port" button.
At this point, you'll be able to send "stuff" to the external hardware, and see what response comes back. This was implemented during the debuggin phase of the project, and is left in place for those of you adapting the software for other external devices.
If the WeatherDuck is sent a single uppercase "B", it will start sending messages like the following every 90 seconds....
26.88,80.38,47,13,18,99,99,99
That message would mean that the WeatherDuck was "seeing":
Temperature was 26.88 C
(which is 80.38 F),
Humidity:47
Airflow: 13
Light level: 18
Input 1: 99
Input 2: 99
Input 3: 99*)
By the way- a little plea: Never abbreviate "temperature" to "temp", please? "Temp", with me, always registers as "temporary". "Tture" makes such a nice, unambiguous, abbreviation.
The program deciphers all of that for you, displays it on a panel.
If you are in the TM#128 mode, then the program will anticipate data of a fixed format arriving shortly after anything is sent to the external unit. The number of records may vary, but the format of the data is tidy.
In TM#128 mode, not a lot more is happening... it just looks messier because the program has to provide more display fields, as there may be several of any of the many devices the TM#128 supports. (By the way- if you bought your TM#128 before May '05, there's a $5 upgrade available to you. See Peter Anderson's site.)
Sorry.. the above is a rough sketch of the program's operation. I'm going to move on to considerations for programmers....
To use the serial port, you probably want to install one or more third party components in your Delphi. I have to admit: This is only the second time I've done it, as I generally don't like to do it. But I've had no regrets. I used the TComPort component from Dirk Claessens' site (Click on the "Downloads" menu item.) The program called "Example" which came with the component provided most of the "backbone" of my program. Of itself, the site says: "All downloads are freeware... use at your own risk." There is a whole bunch of interesting things, many related to TCP/IP.
Once you've collected and installed the TComPort component (it will be on the "Samples" tab of your Component Pallette if you haven't arranged otherwise), you should be able to compile my program, DD63, the subject of this document.
The Bad News: There are some loose ends within the program, at least there were when this note was written. But the Worst News is that I'm not sure I've got my use of the TComPort component exactly right. If you send the WeatherDuck an "L" when it is not in the "verbose" mode, it will respond with just a number, perhaps only two digits, e.g. "42". In some cases, this very small data packet seems to languish in some buffer inside the computer. I would like it to go all the way to my program, which would put the "42" in the memo on my form, and then the rest of DD63 would "do things" with the 42, as necessary.
I could not find a way to be sure that all data goes all the way every time, nor (which I think is probably where my answer, and the answer to other useful jobs, lies) could I find a way to ask the OS "is your buffer-of-data from the serial port empty?" If you can help me with these things, within the Claessens environment, please, please get in touch?
The Good News: If the WeatherDuck is sent a "B", I think that all of the resulting responses are long enough that you get the whole packet, without bytes being left behind. With the TM#128, you might have trouble when it is answering with just a single digit. (Which it does, to tell you the state of the onboard TTL input, when you have no sensors attached.) But! I didn't have a problem... it seemed to work okay, with the TM#128. In any case, as soon as you attach even one sensor, the responses are long enough to prevent the "languishing in buffer" problem.
That's it for now. I suspect that this tutorial will have a small readership. Surprise me with some emails, especially ones mentioning visits to my freeware / shareware pages, and I'll be glad to revist this, extend, polish, etc. I'm always interested to know a little about your circumstances... NOT your full personal details, but, e.g. "25 year old student, Rome, Italy. Working on program to... as part of..., etc."
I hope you found it useful... Remember there is a link for downloading the program and it's the source near the top of the page.
.. and click here, too, if you're feeling really kind! (Promotes my site via "Top100Borland")
Ad from page's editor: Yes.. I do enjoy compiling these things for you...
hope they are helpful. However.. this doesn't pay my bills!!! If you
find this stuff useful, (and you run an MS-DOS or Windows PC) please visit my freeware and shareware page,
download something, and circulate it for me? Links on your page to
this page would also be appreciated!
Why does this site cause a script to run? I have the traffic to this page monitored for me by Jazar Top 200 Delphi, and they provide promotional services, too. Click the "Help get this site publicity" link above for more information.