Thoughts on Raspberry Pi GPIO Program Organization

As I sit here performing my continuing education so that I can keep my standing as a master electrician, I thought I'd write a little bit of philosophy on organizing a program to operate, read, or manipulate real world devices through the GPIO pins (General Purpose Input Output) of a Raspberry Pi.

In my work, I do a lot of controls involving computer operated systems to govern air-conditioning and heating systems of large facilities, specifically hospitals. These systems go by such names as building automation/management systems (BAS, BMS) or energy management systems (EMS). In addition, I have also done work with computer controls often found in facilities, factories,and industrial sites. These are usually called programmable logic controllers (PLC). Many of these systems now connect via Ethernet/TCPIP networks and communicate with webservers and application servers.

Therefore, when I look at a Raspberry Pi used to control real world devices (lights, relays, etc.), I don't see a single board computer, I see a controller. A controller is a device that accepts input, gives output, and uses a control program to perform a task or purpose.

How then do industrial controllers (my term) organize their control programs in order to keep things all going correctly. The following is a system that I've seen on many controllers. It is a logical progression that controls activity so that no one control statement (piece of code) or I/O command can cause bad effects in the real world.

However, before we look at that organization, I need for us to learn at least one definition: a point. In the parlance of my field, a point is a discrete amount of data connected to an input or output, but can also be an intermediate value or data point. Points can be inputs (binary or analog), outputs (binary or analog), or variables/values (place holders or references like setpoints).

With that out of the way, let's look at a standard controller operational model:

1. Upon power up, initialize all points (names, descriptors, types, ranges, etc.) to their default state (on for some, off for others, etc.).
2. Start a watchdog or program timer. Running to the end of this timer will often cause the supervisory program to stop the program, put points into safe states, and issue an operator warning.
3. Start working through the statements and functions in the control program. In some controllers, there are multiple programs and the program counter steps from start to finish on each program until it reaches the end.
4. Once complete with stepping through the logic of the program(s), the controller collects the final disposition for all outputs. No output changes state while the program(s) are being scanned. All outputs will change state at the end of the last control program. The reason that a controller would wait until the program(s) has completed scanning rather than immediate output changes is because different programs or control statements in the programs may change the output state of a point multiple times as it passes through all the program logic. This could cause bad effects to equipment if it is allowed to start and stop in milliseconds (sometimes) during the program. The state of the output after the last line of program code determines the final output state.
5. Command all outputs and read all inputs (though input scanning can take place higher in the order).
6. Rinse, wash, repeat and do it all over again.

Whether you as a programmer writing code for a Raspberry Pi need this level of organization is up to your own judgment. Very simple projects might not, but I like to consider that a computer with the computing horsepower of a Pi should be considered for larger scale functions. Any time the job is large or if we are going to drive real world devices (fans, compressors, motors, heaters) where safety is important, we should consider the organization of our programs as equally important as the individual logic for individual pins.

Since I am new to Raspberry Pi programming, I would like to hear from others in their experience of writing code for the Raspberry Pi in the real world. Do you organize your control programs similar to this method? Are you more immediate in reads and writes of GPIO pins? I'd like to know. Thanks for listening.