I’m Jason Firth.
Merry Christmas, and happy new year!
On my “About me” page, I wrote: “With this blog, I have a few goals: I’m hoping to get some of that information together so control professionals from all over can use it. I’m hoping to take some of the extremely cryptic academic work out there and simplify it for industry.”
Recently, I was speaking with someone from the aaOpenSource project, which was started in part by the guy at the Archestranaut blog over at Avid Solutions. I definitely recommend the blog. It isn’t always updated, but when it is, there’s some great information there.
One thing we both agreed on was that this industry needs more openness and sharing.
I started my “programming career” such as it is in open source. I started off by learning GWBasic, then progressed to QBASIC, then learned Visual Basic and C++ and a bunch of other programming languages afterwards. It might be a bit sacreligious for the hardcore programmers out there, but I always enjoyed BASIC, because compared to many other programming environments, you don’t need to micromanage as much. The runtime library contains most things you’d need for simple programs, so you don’t need to manage library binaries or header files. Eventually, I ended up using the FreeBASIC project. It’s very much like a C++ compiler with a very comprehensive runtime library built in. I ended up contributing a small amount of code, and working as much as I could to improve the documentation for new users.
No matter what programming lanugage I was learning, whether it was gwbasic or C++ or assembly or php, open code was a crucial piece of my learning experience. It was much easier saying “What does correct code look like?”, than trying to decipher sometimes archaic documentation. Having a library of code snippets to call upon means you can focus on solving the novel parts of your solution, rather than reinventing the wheel.
Two pieces of code in particular were things I was particularly proud of improving upon when I was back in high school were a graphics routine, and a keyboard handler.
In DOS programming, and particularly real-mode DOS programing, you end up having to manually handle your graphics to a large degree. I found some code demonstrating a simple pixel set routine for 320×240, a video mode called “ModeX”. It has some really cool features, such as allowing you to draw to an off-screen part of the video memory while showing a different part of the video memory. This is called “Double buffering” when there is an onscreen page and an offscreen page, but ModeX supports two offscreen pages and one onscreen page, called “Triple Buffering”. The most difficult part of programming this to run quickly is that there’s all sorts of insanity in how you write pixels properly. You have four “planes” which you have to write to, and each plane has the graphic laid out in an odd way. The original code showed me how to initialize the video mode, but the code for placing a dot on the screen involved calculating the memory location (involving a multiply and a divide), and setting the plane. After months of staring at the code, I came up with a clever way of writing an entire plane’s pixels in one step consisting only of additions, then I could write an entire screen with only 4 plane shifts. Without the original code showing how ModeX worked, I would have had nothing to start from, and I probably wouldn’t have gone with the arcane video mode without some sample code to start from. Without open documentation, the person who wrote that code probably never would have had a place to start.
Another challenge is key detection. For multikey applications, you have to capture each button press and unpress to determine the keyboard state. To accomplish this, you must create an interrupt handler to replace the existing DOS keyhandler, which only captures one key at a time. Then, you must continuously poll the port. I found some novel tweaks to the code to allow more accurate polling of the port and recording (and retrieval of) multikey values. Without the original code showing how raw keyboard polling worked, I would have had nothing to start from, and I probably wouldn’t have gone with any sort of continuous multikey detection without some sample code to start from. Without open documentation, the person who wrote that code probably never would have had a place to start.
These are small programming problems, but they’re how I started to learn. Without the documentation and open code, I never would have had a place to start, and never would have learned the fundamentals I use to solve problems on a regular basis today, a decade later.
However, our industry is built upon certain open standards. The PID, for example, or Zeigler Nichols tuning, or 4-20mA, or 3-15 PSI. Everyone who learns about the trade needs to learn these things, and by learning them, doesn’t need to reinvent the wheel later.
One thing that should be immediately obvious is that all those standards are from 40 years ago. In some ways, it’s like our trade hit a time warp, and although we’re seeing more and more new technology, it’s all a black box. Some specialized experts understand them, but they’re in the minority.
I come from a few industries where people believe that if you hoard information, and ration it out in little bits, that’s how you stay valuable. I don’t believe that. I believe that the way we stay relevant is by proving to the world all the interesting ways we can provide value to their organizations. We’re tube benders, but we’re not just tube benders. We’re cable pullers, but we’re not just cable pullers. We’re calibrators, but we’re not just calibrators. We’re documenters, but we’re not just documenters. We’re programmers, but we’re not just programmers. We’re electronics techs, but we’re not just electronics techs. I could go on all day, because our trade and profession is so broad, we end up with a view that is equally broad. Instead of being jealous and trying to protect this information, we should be teachers, trying to help each other, and also the other disciplines become better. If we try to go alone, to fend for ourselves, then we’re going to be swept away by the tide of all the new stuff we need to keep on top of.
That’s one big reason why I wanted to start writing this blog, because I was able to build upon the work of others, and I’d like to continue to do that. Together, we can build the future.
Thanks for reading!