OpenDAX

I just posted a blog entry about removing the module handling features from the server.

I haven't had any time to work on OpenDAX in quite a while. Things have been really busy at home and at work. It doesn't look like that will change any time soon but I hope to spend some time on it at some point. I have been learning a little bit more about how traditional *nix type programs communicate with one another and I have been doing some programming in other areas (embedded stuff and some GUI stuff) and I am finding new and better ways to think about things.

When the server starts modules, it starts them all pretty much at the same time. This can cause some problems if one module relies on another to have started. For instance, if you have a daxlua module script that is triggered off of changes in tags that are created by the Modbus module, then it's important to have the Modbus module start first. I didn't like the idea of modules being started in some order, one at a time. Many of the modules will be talking to serial ports and configuring remote hardware as they start. There may be a lot of sleeping going on while I/O modules are starting up. This is why I wanted to group the modules into startup groups.

I've spent a good bit of time fiddling around with the Autotools setup. I never liked the way that I was discovering the Lua directories but the more I read and the more I study, the more I think that I have it right. I did change it so that ./configure will die with an error if it can't find the Lua libraries and header files. I also changed the name of configure.in to the newer configure.ac, and I changed the bootstrap.sh file to autogen.sh to make them look like they were written in this decade.

I had a need at home for some quick and dirty I/O. I needed to send some discrete points through a couple of Xbees to control the gate that leads to our property. I don't have the whole thing working yet but it prompted me to come up with a way to use the Arduino as a simple I/O module.

The idea is to control all of the pins of the Arduino with a serial protocol. This has been done before but I couldn't find any that would allow multiple Arduinos to be on the same serial network. Mine allows individual addressing of the Arduinos so that with an RS-485 type network more than one Arduino can be controlled with a single serial port on the host.

Today, while I was watching somebody fiddle with a DCS it occurred to me that OpenDAX is missing a pretty handy feature. There is no way to force values. These forces would override whatever the other modules would be writing to those tags. I doubt that I get started on it in the very near future but I wanted to spend some time here putting down my thoughts before I forget.

It'd be easy to write some code that would check a bit mask for forces and then ignore writes to that tag after the forced value has been written there. Then when the force is removed the tag value would remain the forced value until some module overwrote it. I don't really like this idea.

Today I released the latest version of OpenDAX. Version 0.5 includes the last major feature that I am going to add to the Server/Library for a while. This is Event Notification. Event Notification allows for event driven programming to be incorporated into modules. Some of the types of events that can be attached to Tags are Write, Change, Set, Deadband etc.

I realized that I was starting to duplicate a lot of code when it came to the Lua interfaces in a couple of modules. There were really two places thus far that were duplicated. I had Lua functions defined to add/read/write tags, create compound data types, etc in both the testing module and the DaxLua module. I am sure that these will be needed in other modules in the future as well. I decided to create a separate library for all of the Lua to OpenDAX interfaces. This would serve two purposes. First, it would eliminate all this duplication and second (if done correctly) it would allow for modules to be written in native Lua, using the new library as a Lua module/package.

I needed to start working on the Tag Event Notification feature in OpenDAX. This is a pretty important feature that would allow a module to sit and wait for things to happen in the server instead of having to poll the server for information like it does now.

I decided that writing slave functionality into the modbus module would be a good way to test this. Then I decided that would be too easy so I decided to add Modbus TCP Server (Slave) functionality. It's eventually going to have to be done. The slave/server functionality in the module would simply wait for updates to happen in the tags that represent the data tables before sending the data to the library data areas that represent the different modbus registers.

OpenDAX has been self hosted on a server of mine since it's inception. I think it's time that OpenDAX get some more attention and I think that moving it to SourceForge will help do that.

I tried to move it to LaunchPad but I never quite figured out how to move the repository. Besides I'm not really enthusiastic about having to learn bzr since I'm already comfortable with subversion. LaunchPad has a bunch of good features involving bug tracking and feature enhancements that I think might be nice but OpenDAX may not be a big enough project to justify any of that. We'll see how this works and go from there. I doubt that I get this right the first time.