Writing a Kicking' Program
Anatomy of a HAL Program
Hal Programs are installed via the Task section of the HAL Automation Setup Wizard. However, opening Automation Setup is practically the last part of the process of writing a Program.
The first thing we do is design the program. The design process essentially consists of opening your favorite text editor (Note, I did not say “Word Processor”. There is a difference, and although you can certainly use Word or similar for this purpose, something simpler is usually easier to work with. I prefer Notepad to Word, but lately I have begun using a free tool
called “Perl Code Editor”) and writing the basic elements of the program as if you were writing any other program.
This serves two purposes. First, it lets you think of the program as a single entity. Second it builds documentation of the program that you can later use to troubleshoot and modify it. Since HAL will not let you place comments in the actual Rules and Macros, use this document to hold your comments, and be generous with comments.
Most importantly, do NOT go anywhere near HAL or the HAL Automation Setup wizard until you have completed your program. It may seem redundant to write everything twice, and no doubt when you go to enter the program in HAL you will find mistakes and assumptions about HAL constructs that were incorrect. You need to change your program to accommodate the necessary changes. But complete the written program first, update it as it changes and keep the document consistent with the actual HAL Program.
Trying to write even a simple program from memory, holding your logic steps in your head as you turn them into rules, and trusting that you will remember the thought processes behind them (that you would put in comments if HAL would let you) is a certain path to buggy and unmanageable programs.
Trust me, design and write the entire program first, do flowcharts and complete the parallel document before you go near the HAL Automation Setup wizard. The task of installing each rule from your document into the wizard will seem tedious, but the time spent trying to troubleshoot your mistakes otherwise will be a lot more so. You will be glad you designed the program and created the documents first.
Introduction
The first thing you should write is the introduction to your program. Referring once again to our HAL Program for Swimming Pool control we see an example of an introduction section that details the Functions the Program provides, the hardware being controlled, and even a diagram of how they interact. This is very helpful in documenting exactly what we are doing.
Element Definitions
Strongly typed languages such as Pascal force the programmer to define all the variables used within the program. This helps avoid silly programmer mistakes caused by misusing variables. Such strict rules are often annoying, and modern languages have relaxed these sorts of restrictions. Perl in particular requires no such thing, and in fact intentionally allows misuse of variables. This can be useful but is also a two edged sword, as it makes mistakes easy to make.
Nevertheless the basic idea of thinking carefully about your program elements and documenting them is a sound one, and useful even for Perl programs. Referring again to our example, we see a block labeled Var. This is a Pascal convention and in HAL Programs Var is meaningless. But it does serve to designate to a programmer reading the listing that this is the place where the various elements that play a factor in the program are listed.
| 
