OpenDAX

Add comment April 30th, 2008 08:45am phil

About a year ago I wrote a blog entry about an Open Automation Controller. I have been fiddling around with one for over a year now and it’s starting to come together. I called it OpenDAX and created a website at http://www.opendax.org/

I have a pretty extensive blog there that documents the evolution of the project. I’m also trying to set it up as a genuine open source project. This will be my first real open source project so there is a lot still to learn but it’ll be fun.

Automation Controller Architecture

Add comment April 19th, 2007 11:09am phil

I have been trying to decide on a good way to build an automation controller. Primarily I’m trying to decide on the overall architecture. The controller will be written for Linux. I’ll try to keep it portable but it’ll be written for Linux. There are several ways to go about this but first a list of requirements.

All manner of data types should be supported. This would include arrays and custom data types. There would have to be some kind of base data type list. BOOL, INT, UINT, REAL etc. Then the system would have to deal with custom data types like timers, counters, alarms etc. as well as arrays of all of the above.

The data tables should be completely dynamic. A data point should be capable of being added and removed from the system at any time after the system is running. There may have to be some module ownership issues to contend with, but for the system to be truly useful it will have to be capable of staying online and the data table changing.

Modules should be loadable during run time. Any module of any type (even those that didn’t exist when the main controller was compiled) should be loadable into the system and also removable. The rest of the system should be immune to this.

The system should be capable of being redundant. This is probably far more difficult than I think it will be, but it’s essential. At the very least the ability to make the system redundant should be considered in the initial design because this will be very difficult to add as an afterthought later. The question is whether or not the system itself is redundant or should the modules have redundancy built into them. It may also depend on what is being duplicated, whether it’s a controller, and I/O module or an HMI.

The system needs to be efficient. I hate writing code that wastes memory or clock cycles for no good reason. This system needs to be useful on an old 486 or an embedded system. Not all the modules will make sense on these types of hardware (a GUI HMI for example) but the core system needs to be tight.

It should be very easy to program a module. Just a few pages of documentation and about half a dozen function calls should be all it takes to write a functional module. Obviously there will be advanced features that will require more knowledge but I’ve found that if the initial entry into a new system is difficult then few enter. Make it easy to build the first module and then slowly learn to improve it.

There should be some level of network transparency. A big question is whether the networking is done at the system level or at the module level. I’m leaning toward the module level because I’d like the core system to be as simple as humanly possible. Put the features into the modules. This may make redundancy a little more difficult however so I’ll have to put some more thought into it. This is starting to look more like a DCS than a PLC.

It would make sense to include some method of messaging between modules. Other attempts at Linux based automation controllers have a central data repository and that is the only method for modules to communicate to each other. I’d like to see a message based architecture along with some central shared memory. There are all kinds of ways to share the data. Some are more efficient than others. I don’t like the way MatPLC handles it. They duplicate the entire memory map for each module. I don’t want to do this. I can see some small duplication for modules that need to be able to manipulate fairly large amounts of memory in a small amount of time, but the module should have control of that. A ladder program module for instance might allocate it’s input table, make it’s computations then write it’s output table.

Now for the different architectures.

The first that comes to mind is a simple daemon process that controls all the data and modules. I doubt that a single daemon process would make much sense. At some point libraries would have to be built to ease the task of module building anyway so at the very least a library should exist from the beginning.

A library brings something else to the table, and that is the ability for some of the core to reside in the individual modules process space. This could help with efficiency. That brings up the second architecture. A single library that handles the entire system from database configuration to scan timing and memory updating. This is essentially what the MatPLC is. I like this idea but it seems that it might be more difficult to implement the hot-swap modules and dynamic data allocation in this environment. It seems to me that there needs to be some capability in the system to monitor the health of the modules so that it knows when to free the modules data and remove the modules messages from the queue. This would probably still be possible in a library but all of the information would have to be stored in a shared memory segment or message queue of some kind. There may be a way to have truly global data in a shared library but I don’t know how to do it. This would also generate some kind of cooperative multitasking arrangement. The process management side of the library would probably be at the mercy of the individual modules. This would not be acceptable but there may be ways around it too.

I’d like to stick with the library only approach if it’d work. I can’t get my mind around how module and data table registration would take place in a library only situation. It’s simple enough to have the library store the data structures and process information in a shared memory segment and then deal with them with semaphores and such but I think this may simply be too complicated.

The implementation that I am leaning toward is a central daemon process paired with a library of functions to handle data transfer and messaging. The advantages that I see for the library is that there can be a distinction on what is contained in the modules process space and what is contained in the core. The daemon would be somewhat “kernel-like.” It would handle the module processes and data map issues that were central to the core. It may actually become the core. A large amount of data concerning each module (which tags it owns, its dependancies, etc.) could be managed in this core. Signals could be sent to module processes from this process if need be and the redundancy of the modules could be handled from this process.

The obvious disadvantage of the central daemon process is the single point of failure that it becomes. A set of processes that share a common library don’t necessarily have any single point of failure other than the modules interdependencies. An HMI module could fail and the logic modules could still keep running. The central daemon would have to stay running or all the modules would become useless. The logic modules could still operate without the HMI module but nothing works without the core daemon. This is where redundancy comes in. This core process would need to have the ability to transfer control to a similar module on another machine. All the better reason to keep this thing simple and let all the heavy lifting be done at the module level

A slight departure from this method would be a completely modular approach similar to a modern PLC. Everything is a module, with a common library to emulate a backplane. This is similar to the library only idea except that there would have to be some kind of “controller” module to handle all of the “other” modules. The main drawback that I see in this architecture is redundancy of code that would happen inside the “controller” modules. The controller itself would almost need to be some kind modular code base so that a user could have ladder programming or launching scripts etc. There would also be portability issues with modules that could work with one type of controller but not with another. In essence this would become the central daemon idea. The obvious benefit is that there could exist multiple controllers in one running system but really there is nothing preventing that in any of the other architectures either. The difference is how the data gets passed from module to module and how messages are handled.

Another drawback to this approach is the assumption that this thing will “control” something. It may exist on a particular computer simply to act as an HMI to the controller that is on another machine.

The final architecture that I can see is one where there is a single running process with dynamically loadable libraries to act as modules. This is basically how PAM (Pluggable Authentication Modules) works. This has some major drawbacks. The biggest is the ease of developing new modules. The first requirement that I listed above is the easy creation of modules. A dynamically loadable shared library doesn’t fit that mold. It also precludes being able to use interpreted scripting languages as modules. It also may not be very portable. All modern desktop operating systems have dynamically loadable libraries but there are some issues with this on smaller embedded systems. There may be some licensing issues involved here too. Did I mention that a wayward module could bring down the whole system. I’d rather have the modules as separate process and let Linux do what Linux does best, handle processes.

Now about licensing. I spent some time last night reading about the GPL. I had about decided that I was going to release the main core process program as GPL software and the library as LGPL. This may still be the way to go but I need to think hard about the LGPL. There are some commercial implications for this software. To truly turn into something useful it would need to have some commercial support. This means that companies and consultants need to be able to write proprietary modules and sell them to their customers. Another benefit of the LGPL is one of I/O for commercial hardware. Allen Bradley could write a binary module to talk to some of it’s controllers. I would like to be able to limit the users ability to write logic modules for customers and keep them proprietary but I’d like for big automation companies to be comfortable writing I/O module while still protecting their intellectual property (sorry FSF didn’t mean to say bad words).

If an end user developed a module to do PID loop calculations and then decided to box them up and sell them without also distributing the source, we’d all lose. But if Allen Bradley would have otherwise written an I/O driver for the PCICS card except for the GPL then that would be equally as bad. I’m torn. Perhaps we need to have two libraries. One that can be used simply as an I/O module library (no access to another modules data) and release that one LGPL and then fully functional library would be released under the GPL. Then any actual improvements to reusable logic type modules would be free and large hardware vendors could still write I/O modules for their hardware. It’d be hard to succeed in this industry without being able to communicate with existing hardware. How ’bout a linux box controlling a ControlLogix rack full of I/O. Pretty cool idea huh?

There are issues also associated with the end user of the software. Say for instance you are hired as a consultant to build a system for a client. In the process of this work you build a module specifically for that client, and that client has you sign an NDA to protect an idea on the way they operate that particular process. The GPL still seems to work in this environment. The GPL says that you have to distribute the source code if you distribute the binary. The consultant would not be able to give his custom module to the client without the client also getting the source code. The client could choose not to distribute the module beyond that and therefore would have no obligation to distribute the source code. You the consultant would be bound by the NDA not to distribute the code to another client, so the client is protected. The one that is not allowed to protect his code is the consultant.

It’s important to note that this only applies if the consultant writes a module that links against the library. If he simply configures the system in a certain way and then writes some ladder logic code that is then interpreted by a ladder logic module, he is not required by the GPL to release the source of his ladder program to the client. This is one of the reasons that I would like to see the logic modules implemented as interpreters and not as module compilers. It gives an otherwise weary consultant a way to keep his code proprietary and still maintain the integrity of the GPL. Interpreters like Ruby, Perl, Python and Java might fall in the gray area. The bindings would be in the language and as such the bindings would be open source but the programs themselves would probably not fall under the GPL. This is okay with the spirit of the project because it’s the bindings that we’d want to see as a part of the community so that others could use interpreters as modules but the community doesn’t really care about how to control a bar-fooing process.

I think I’ll probably start down the path of using a central daemon process with two libraries. One LGPL library limited to accessing it’s own data map, anther full featured library released under the GPL. This seems like the simplest solution and simple generally means better. I may find some reasons to change but the only other option is the library only approach and it just seems far too complex to me. I’ll starting dreaming up data structures and interfaces and see how it all starts to fit together. Please feel free to give me some comments on this.

My New Mac Book Pro

Add comment November 8th, 2006 11:50am phil

I’ve had my new 15″ 2.33 GHz Core 2 Duo Mac Book Pro now for a couple of days. I really do love the thing. It only took a couple of hours to get it out of the box and get all of my iTunes, Mail, iPhoto, Documents and such transfered over. It probably didn’t need to take that long but I didn’t use the Migration Assistant that probably would have done it in a few minutes. I kinda liked the idea of having a clean start so I just copied what I needed.

I have Windblows XP running on a VM in Parallels. This is something I must do for work, otherwise I wouldn’t bother. It runs faster than many of the PC’s around here. It’s so much faster than my Virtual PC / Windows 2000 combination that I had on my G4 PowerBook that a comparison can’t really be made. It’s like not running it in a VM at all. It runs so fast it feels like it’s native. I guess I can see why somebody would want to run BootCamp but I don’t. I’d prefer for Windows to stay where it belongs; Inside another window.

The only complaint that I have about Parallels is the way the serial port is handled. In VPC I could assign one of the actual Mac serial ports to the virtual com ports in VPC. In parallels the best I can see is assigning it to a socket. There may be a way to get this to work but I haven’t fought with it too much. Since the MBP doesn’t have a com port on it anyway, it has to be USB so I just loaded the USB drivers into the XP VM and it worked okay. I liked the VPC way of doing it because I always had better luck getting USB -> Serial devices to work in OS X than Win2k. I did manange to get an RS-232 converter and an RS-485 converter both working yesterday and got all the Modbus work done that I needed.

The battery life on the MBP seems to be comparable to the old PowerBook. It does run considerably faster. I played around with some iMovie stuff yesterday and compressing video was quite a bit faster than on the old G4. I like the screen, I’m still torn on the keyboard. I loved the keyboard on my PowerBook as soon as I touched it, and this one is close enough to not be an issue but I don’t know if I like the new texture. They are both better than any cheesy Dell keyboard.
The remote seems rather pointless. I can see it’s usefullness on a Mac Mini but I doubt that I’ll use it much with my MBP. It works well it just doesn’t have any use for me. The iSight camera works well but again I don’t see the point. I just really don’t want to do any video conferencing. Maybe I’ll find a use for it now that I have it but I never had a need to go out and buy one.

The power brick is quite a bit bigger and I guess that is to be expected, because the battery is bigger. I guess I’ll get used to it. I love the little magnetic power adapter. It seems like it holds on a little too tight but it’s really cool how it goes in without any help. You just get it close and “click” you have power.

I like that it has the two USB ports split between each side. I was always having to install a USB hub on my PowerBook because the ports were so close that some flash drives and other peripherals couldn’t both be installed. This way I can pick which side to plug the devices into as well.

I don’t think that I like the Superdrive being on the front as much as I liked it being on the side. When the computer is in my lap it seems a little clumsy but this is minor and moving it to the front allowed for the USB port to be on that side and so it was worth doing as far as I’m concerned.

To sum up, you’ll get my MBP from me when you pry it out of my cold dead hands.  The screen is very bright and crisp, it’s fairlly light, it’s very small.  It’s blazing fast, and has plenty of RAM and HD space.  It’s a Mac so it’s better than any Windblows computer anyway.  Now I just have to look forward to Leopard.

Lilliput Touch Screen on Xubuntu

Add comment June 20th, 2006 07:57pm phil

I am writing this down so that I can remember how to do this next time. If you find it helpful and it saves you some time then I am glad to help.

The first thing to do is to install the build-essential package. This installs gcc, make, gdb etc. To do this type this…

sudo apt-get install build-essential

Install the tcl development package…

sudo apt-get install tcl8.4-dev

Install the kernel source package…

sudo apt-get install kernel-source

sudo apt-get install linux-headers

Remove the touckitusb driver from memory with…

sudo rmmod touchkitusb

Then down load the drivers from http://www.egalax.com/eg/drivers.htm

Follow the instructions with the driver.

To create the tpaneld.conf file just run the touchcfg file and it’ll create it. Then reboot. Once it reboots it should be a simple matter of running the touchcfg program as root and running the configuration program.

Open Letter to Instrument Pilots

Add comment June 10th, 2006 05:51pm phil

Dear Instrument Rated Pilot,

I really do appreciate the time, effort and money that you put in to earning that instrument rating.  I really do, and I will probably do the same some day when I get some of these other things in my life out of the way.  I’m sure that it makes you a safer pilot and I know that it increases the usability of the aircraft that you fly, but why do instrument pilots on IFR flight plans think they can ignore everything they learned in their primary training about avoiding aircraft?

I once had a non-pilot tell me a story of an airplane ride that he took with a friend on a beautiful clear day.  When he asked his friend about the identity of a landmark the pilot friend had to dig his glasses out of his bag because he couldn’t see without them.  When my friend questioned him on this his reply was, “I’m on an instrument flight plan.”  Can you see the folly in this?

Why do instrument rated pilots think that they can sit back and relax and not watch out for other aircraft when they are flying around in visual conditions?  Air traffic control can only separate you from other IFR aircraft.  They will try, when the radar is working, to separate you from all the aircraft that they can see on radar.  That assumes that they can see you on radar.  Just because you are on an instrument flight plan does not mean that ATC has you on a radar screen!  Besides it’s very unlikely that they will have that sailplane circling at 12,000 feet on radar.

When you are flying in IMC you don’t have to worry about a VFR airplane.  That is why VFR pilots have ceiling, visibility and cloud separation rules.  I promise to stay out of your cloud if you’ll promise to watch out for me when you are in clear air.  Obviously if you are above FL180, please feel free to take a nap.  I’m not up there with you.

Please understand that you still have a responsibility to yourself, your passengers and everyone that you are sharing the sky with to See and Avoid anytime you are in visual conditions, whether you are on an IFR plan or not!

Another thing that really bugs me is when you guys make position reports at non-towered airports with all that IFR verbage.  I’m sorry that I don’t know where you are when you say, “3 mi south of the Silky intersection on the Smooth VOR 23 approach”.  All you accomplish when you make a call like that on a nice Saturday afternoon is bragging about the fact that you know some instrument stuff.  There may be some in the pattern that know where you are but that 50 hour private pilot doing touch-n-goes doesn’t have a clue.  You probably get just as aggrivated when you fly into a new airport and someone give a report like, “I’m two miles east of the old salt mine.”

Oh and instrument approaches (practice or otherwise) don’t give you right of way over VFR aircraft.  The right of way rules don’t say anything about what type of flight plan you have filed.

I wish I had a nickel for every King Air that has gotten on the radio and said something like…”xxx traffic this is King Air XYZ were on the inbound NDB 8 miles north of the ZYX intersection, blah, blah, blah, blah, any traffic please advice.”  (I guess it’s good that your asking us to tell you where we are because we don’t know where in the hell you are!)  Then leave the freqency to talk to approach some more only to come back a minute later and say, “xxx traffic this is King Air XYZ on 2 mile final for runway 18.”  Nevermind that I called my crosswind, downwind and base legs and the two people behind me did too.  You are the commercial pilot on the instrument flight plan so you must have right of way so I guess I’ll go around.  Some day that little cub with no radio is going decorate the nose of that turbine driven diesel guzzler that you fly and then where will you be.  I guess you’ll be screeming “But I’m on an IFR plan!” all the way to the ground.

I once had a King Air pilot ask me my postion.  I told him that I was abeam the numbers on the left downwind.  The next thing he said was that he was on a right base.  (This was a busy airport with left hand traffic).  I immediately called and said that I was turning left base, and his answer was, “We’re on a right base, we’ll see if we can sneak in here in front of you.”  I had to go around to avoid him.  He was higher than I was, he was further away and flying the pattern backwards, but for some reason thought that he had right of way over me.

Be safe out there.

Windows Vista

Add comment May 30th, 2006 05:28pm phil

Today (for some unknown reason) I decided to take a look at Micro$oft’s Vista page and see what all the hoopla is on this perpetual marketing drive known as Windows. It seems that they have copied a lot of the Mac OS X Tiger features. What are known as Widgets in OSX are Gadgets in Vista. The fancy new search feature in Vista is called Spotlight in Tiger, and we’ll see if it works as well.

The part I really liked in the Vista Hype was the security tab. Here are a few quotes…

Microsoft believes the best approach to stopping malware is to layer security features.

This is just a fancy way of saying… “We don’t have time to fix the low level problems with our operating system so we are throwing a bunch of band-aids at them.” Didn’t Microsoft invent most of the ‘features’ that malware writers exploit?

In addition to using these built-in Windows Vista features, you should help keep your computer healthy by using antivirus software such as Windows OneCare or an antivirus solution from one of Microsoft’s partners. Whichever option you choose, remember to update your antivirus software regularly. These updates are generally available through a subscription from your antivirus vendor.

Microsoft’s solution for everything, “buy something else.” It’s often thought that Macs are more expensive than PC’s. Once you buy the spyware scanner, the virus blocker, the disk utility package and all the other little things that seem necessary under Windows, my PowerBook was a pretty good deal.

I really enjoyed the Networking section too.  Other than a few improvements in Wireless networking (most notable being the introduction of WPA2) there was nothing about making computers actually talk to each other.  It was all about drawing pretty pictures of all the problems that your Windows computer is having talking to other Windows computers.  All the while my Mac is talking to all of your Windows computers and printers (plus the Novell, and Linux boxes) that your Vista machine can’t seem to get working, but now you know why, because you can see the picture of the other computers with their little red ‘X’s on them.

Water Fueled Cars

Add comment May 19th, 2006 09:04am phil

It seems that some ’scientist’ has ‘discovered’ a way to turn water into H2 and O2 and then burn it in an engine (thereby converting it back into water) to make power. This is bunk!! I don’t care what process you use, or what ‘discovery’ you make. It doesn’t matter whether you vibrate the molecule, heat it, electrify it or tickle it, there is NO way that you can get more energy out of a system than you put into it. It takes more energy to break the water molecule apart than you get from burning the H2 that’s produced. The Second Law of Thermodynamics guarantees this to be the case regardless of the technology.

Hydrogen could be a great fuel. It is true that the only byproduct of burning hydrogen is water. Fire is an oxidation reaction. If you oxidize hydrogen you get water. It’s a wonderful thing, except that there aren’t really any hydrogen mines out there. The predominate source of hydrogen production is natural gas. There are some refinery processes that produce hydrogen and I’m sure that there’s a tiny bit of it in air that could be extracted by expending an enormous amount of energy. This remides me of the cartoon of the toothpick factory where they use a whole tree to make one toothpick.

Electrolysis is the process that causes water to split into hydrogen and oxygen. The process requires large amounts of electricity. Electrolysis may be the way to proceed, but we have to stop thinking of hydrogen as an energy source and start thinking of it as an energy storage mechanism.

The biggest problem that the electric car has is energy storage. Batteries are very expensive and their energy density is terrible. Batteries are getting better all the time but they are not quite ready for the masses. If we use the electricity to make hydrogen then use the hydrogen to power the car then we have something worth thinking about. There are a couple of problems with this idea. One is how to store the stuff. When you take a molecule of water (H2O) and split it you get hydrogen and oxygen in the perfect mixture to burn. In essence you’ve made rocket fuel. You will want to separate them as quickly as possible and get rid of the oxygen. We also need to pressurize the hydrogen for storage. This takes more electricity to accomplish.

The second problem lies with the efficiency of the electrolysis process. I don’t know what these efficiencies are but if it can be done with a fairly small amount of wasted energy then we’d have an energy storage mechanism that can store a lot more energy than a battery could. It would also eliminate the whole charging cycle for the car because the hydrogen production would work around the clock.

I don’t know if this idea is remotely feasible because I don’t know what the efficiencies of the processes are. I may do a little more research and see if it’s even possible. I’ll let you know.

Getting Things Started

Add comment May 17th, 2006 09:40pm phil

I just installed this blogging software (Wordpress) onto my web server. I have never really used a ‘blog before but I decided to give it a try.

I suspect that I’ll spend a lot of time on these pages commenting on the days events. I’m sure that I’ll do a fair amount of talking about airplanes. There will be the occasional debunk of the latest free energy ideas. Knowing me, there’ll be a lot of controversy over this whole universe-happening-by-accident stupidty known as evolution.

I promise that there will be no talk about Hollywood or who was that last to leave on Survivor. I couldn’t care less who Tom Cruise is married to or what his kids names are.

First X-Country Trip in N727WB

Add comment November 11th, 2005 09:13pm phil

Less than 24 hours after I flew off the test hours on my RV-7, Shannon and I climbed in it and flew to Littlefield to see my family. We sat in the terminal at West Houston Airport for a couple of hours waiting for the ceiling to lift. As it turned out we left a little early and we wound up running into some some low clouds and had to land at Hearne and wait about another hour.

We finally got to Littlefield and with all the delays it still only took a little over 6 hours to get there. That’s still 3 hours better than driving and it’s a whole lot more fun. We had great weather on the way home and it only took about 2-1/2 hours to get home. That is what it’s all about.

Hearn Municipal Airport