The functional test department of our electronic subcontracting firm burns in several products for our customers, some for several days. Our burn-in chamber runs over the weekend, and has several safety features. In the event of a power failure, for example, the oven shuts itself off and remains off until someone physically verifies that everything is okay.
This is a problem on weekends, especially long holiday weekends. Once, the oven shut off about ten minutes after everyone had left the building, and it remained off for the weekend. As a result, we decided to set up something that would monitor the oven. Therefore, in the event of an actual oven shutdown, some alert would be triggered that could be monitored by anyone. After several different suggestions, I decided to go “hightech” and put up a web page where the status of the oven could be viewed at any time. To simplify the problem, I broke it down into several stages:
- Design a circuit to convert the oven status to computer-readable format (see the figure).
- Write a computer program to talk to the oven circuit and record the status information.
- Write a computer program to transfer the status information to a web server on the Internet.
I was already familiar with the Microchip PIC series of microcontrollers, so I selected a PIC16C54 for the interface. With an 8-MHz clock and a MAX232 TTL-to-EIA232 level converter, I could transfer data at 9600 baud between the controller and a PC. The planned chain of events was to wait for any character on the serial port, then send a text line containing “On” or “Off,” depending on the state of the oven.
To determine the state of the oven, an optoisolator was attached to the low-voltage control circuit of the oven (24 V ac). The result is a logic 1 at the microcontroller if the oven is on, and a logic 0 if the oven is off. An LED was also attached to an available I/O pin as an “alive” indicator.
On the PC side, I chose to use Perl under Linux to collect and disperse the information. I found the Perl language very easy to understand, with very little research. The first script (see note at end of article) performs the following functions:
- Record the current date and time in a string.
- Open the serial port and send a line feed.
- Receive characters from the serial port until a line feed is received.
- Filter the text string to remove extraneous leading and trailing characters. The result is a text string containing “On” or “Off.”
- Attach this line of info to the end of a log file (oven.log).
- Replace the one-line document (status.txt) with an HTML-formatted string containing the same information.
- If the on/off status is different from the last time the oven was checked, append this information to the “panic.txt” file.
- Wait a minute, and then start the process over.
A second routine was needed to transfer data to the web site. I used Perl, because it has FTP functionality in shared libraries, which make FTP transfers very simple. All it does is:
- Initialize a link to the FTP site.
- Supply a username and password.
- Change to the appropriate directory.
- Send (“put” in FTP terminology) the “oven.html” file.
- Close the connection.
I call this from a shell script that creates “oven.html” by concatenating several files, in order. To make this repeat every ten minutes, the shell script is called from another Perl script, which loops on a ten-minute period. Even though these are scripts and not compiled programs, they can still be called directly.
Despite the apparent complexity, it works. I debugged each stage, but the further I progressed, the easier it became. In the event of a power failure, the computer reboots, checks the oven monitor, and automatically updates the web page.
Our first test occurred during the July 4th holiday weekend. The oven didn’t shut down, but everyone in our department delighted in checking to see if it was still running. The computer that’s doing the work currently resides on my desk; it is dual-boot (Windows ’95 and Linux) and automatically boots into Linux.
The upshot of all this complexity is added flexibility. The PIC microcontroller has plenty of available RAM for program updates, as well as eight I/O pins still available for connection to various devices. Because I have full control of the interface on both sides, changes to the interface are easy to implement, and easy to debug.
What’s next? Probably the first change will be to add a second optoisolator to the IC to monitor an additional burn-in chamber. This will require code changes in all the programs, but the foundation is already there. Beyond that, I’d like to add graphics to the web page. I’m also looking into collecting temperature data using the microprocessor and posting that to the web site.
The PIC assembler listing and the Perl Scripts discussed in this article can be found on Electronic Design’s web site at www.elecdesign.com.—Ed.