OpenDAX

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.

Well I think I finally have the program back to where it was before I ripped it apart to add compound data types. I'm going to start trying to use the program for something at home again, so I should find a few bugs along the way. It seems to work okay at the moment.

Go get a copy at http://www.opendax.org/downloads.

I think that I finally have the compound data types working in the server and the library. At least all the test cases that I have been able to dream up are working.

I've just finished implementing some pretty massive changes in the custom data type code in the server and library. I've also decided to start calling them Compound Data Types as well.

The changes that I made involved how the CDT's were created. Previously there were several messages that were sent to the server. The first created a data type by name, then members were added one by one and then the data type was finalized. This was simple to implement but it caused complexity in the supporting code. It allowed for recursion in the data types that had to be checked for and eliminated. There was also the problem of other modules trying to use the data type before the creating module was finished with it, so I had code in there to solve these problems.

I have spent some time this weekend trying to figure out how to build the API for the tag database access functions in the library. The existing functions fall apart a little bit when we start talking about custom data types. I think that I have come up with a nice interface and I wanted to throw it out into the wild and get comments.

I have been wanting to add custom data types to the system since the day I started working on it. I never worked on it because I wanted to get it functioning first. I have a friend that may start working on the HMI module and before he gets started on that monster, I wanted to make sure that most of the low level stuff was working. At least defined. The earlier these things are done the less stuff we'll have to change to add them later.

Right now I have a few functions inside the server that allow adding the datatype and adding members to the datatype. The members are allowed to be any of the base datatypes that are included in opendax as well as other custom data types. There aren't any messages yet and I haven't started on the library code.

It has been a while since I've worked on OpenDAX. I guess about 6 months. I was playing around with some other things in that time. I'm still playing with them but I need to keep my head in this a little bit. I had to stare at the code for a while before I remembered what it all did. I'm glad that I have taken the time to write these blog entries too, since they remind of how I implemented some of this stuff and why.

The last commit to the repository added an extra socket connection. The second socket is used for asynchronous events that are generated by the server. It was very difficult for me to figure out how to share the other socket and not clobber response messages with event messages from the server. In some respects the message queue would have been much simpler in this regard. I still think that sockets are the better way to go, however.

I have the basic foundations for the library based configuration programmed into the library now. I've tested it pretty well but not 100%. I'll yet dig up some bugs, but I wanted to start plugging in the new configuration into the existing modules so that I can be sure that I like the API. Right now it's pretty simple.