Modules
Mon, 06/25/2007 - 02:28 — phil
- We need an IL (Instruction List) interpreter module. Preferably one that meets the IEC 61131 standard. Other logic languages such as ladder, function block etc. could be written to compile to IL and then there'd only need be one logic module type.
- An alarm handling / logger needs to be built.
- Historical logging module
- HMI module is very important. This would come in two parts. The runtime and the development environment. The most logical fit for a file format would be SVG. There is a project called librsvg that intends to implent the SVG specification. So far they have the static redering done but no animation. It'd be cool if somebody would be willing to go help those guys out with OpenDAX in mind. In the meantime maybe some kind of Javascript library for using browsers would work.
- It would make sense to build some kind of Web Module. This might be more than one module. It could be a set of PHP bindings for large sites and/or it could be a wrapper around one of the small web servers. It could even be a standalone web server module if the application needed to conserve memory. It would need many of the same features of the HMI module. What would really be cool is if there were a web module that could serve as a runtime engine for the HMI. There is a lot of room for creativity here.
- Asterisk / Callweaver module. Asterisk is an Open Source PBX (Private Branch eXchange) phone system. Callweaver is a fork of Asterisk and is very similar. Many automations systems need some kind of access to the phone system. It makes no sense to reinvent the wheel here when there are two very good projects already out there that we can inteface with. This could be used as a remote interface to the system, a callout alarm system and just about anything else somebody could dream up that would involve connecting an automation system with a phone system.
- The Comedi project is developing a set of device drivers and library functions to standardize the interface to quite a few data aquisition cards and devices. A module to interface to teh Comedi libraries would give us access to all of those cards and devcices.
- NMEA Module for reading GPS data. I found this library.
- Some home automation modules for Insteon, X-10 etc.
- A MATPLC module might make some sense, too. We don't really compete with that project we are just different.
- A module to talk to the GPIO on a Gumstix computer.
- Generic Parallel port module.
- Generic ASCII serial port module (probably add serial port functionality to the Lua module
- Davis Weather station module
- Arduino Module - It'd be cool to be able to manipulate the I/O on an Arduino from OpenDAX.
- Open Source USB I/O - This would be more than just a software project, I envision this as an Open Source hardware project with some common interfaces to the I/O and an OpenDAX module to communicate to them. How cool would that be?!
- There are an endless number of industrial protocols that would be nice to have. There are some serious problems with licensing on some of these. Modbus has been opened up and we have a Modbus module. DF1 shouldn't be a problem since it is open as well. I don't know that much about any of the others. I know that OPC will be a problem even after the UA specification comes out because of licensing issues. There is GE Genius Bus, Foundation FieldBus, Profibus, ControlNet, K-direct and many others that I don't even want to try to list. These would be great to have but they may require a clean room reverse engineering effort to implement legally. There may be ways to write drivers that utilize hardware interfaces on some of these and I think there are hardware vendors that would probably help (Weed, SST, etc.). Modbus is the lowest common denominator in industrial communications so we should be able to integrate with anything, but Modbus has some serious problems when it comes to large amounts of different types of data and anything that needs to be "real time." We shall see.