OpenDAX Server
Currently the OpenDAX server reads its configuration file, starts modules, and does a pretty good job of handling the tag database. Tags can be added at run time but they cannot be deleted. Reading and writing tags seems to be pretty solid but there is still much testing to be done before we trust it too much.
Compound data types allow the user to create data types that are collections of other data types. Similar to a structure in C or a User Defined Type in ControlLogix. The implementation seems to work okay and I think the API works okay.
I've recently finished working on adding event handling capability to tag database. This allows modules to be notified when tag change, are written too, bits are set, values are greater than some number, etc. It has not been thoroughly tested but it seems to work okay.
Modules are still not started in any defined order, and the STDIN / STDOUT pipes are not implemented other than being opened when configured. There is still some kind of problem with the state the 'opendax' server finds itself when a module fails to start. The module starting routines need some scrutiny and the startup order needs to be implemented.
I would also like to add some kind of ability for message logging to be centrally configured. This may require all the messages to be sent over the socket and be handled by 'opendax.' There is much cleanup and organization to be done with logging.
OpenDAX Library
The library mirrors the status of the server. This is unavoidable. The most recent changes to the library make it re-entrant and thread safe. This was done by creating a dax_state object that has to be carried around by the calling module for the duration of the connection and by adding locking around this object within the library to prevent race conditions that would cause issues in the library code.
DAXLua Module
The DAXLua module is in pretty good shape. It runs fine. There are two kinds of scripts at this point. There is the init script that is run once when the module starts and then any number of user definable scripts that will run in different threads. These threads will either run periodically based on a configured time frame or an event can get created to run the scripts.
The OpenDAX interface functions include...
Tags can also be assigned as globals for a script. Before the script is executed the tags are read from the server and stored in Lua global variables. Then once the script is over the globals are read from the Lua state and then written back out to the server. I found that a lot of my code was reading the tags into globals at the beginning of the script and then writing them back out at the end. This eliminates all of that. There is also a mechanism that allows Lua variables to be maintained between calls to the script.
All of the Lua interface functions for these scripts were removed from the daxlua module code base and put into a Library called libdaxlua. This seems to work okay but it has not been thoroughly tested.
Modbus Module
The Modbus Module is pretty well broken at the moment. I removed most of the Modbus implementation logic into it's own library and I am still working the kinks out of that. I have also started adding slave functionality as well as Modbus TCP. The Modbus TCP server functionality works pretty well at this point but the whole thing is far from complete.
It also lacks full serial port configuration. There is no capacity for hardware handshaking at the moment so using it on a serial radio might be problematic.
Not all of the function codes are implemented at present.
Finishing all this Modbus stuff is the current priority now that event notifications are added to the server.
Command Line Module
The daxc command line module works okay and many of the core features are implemented. It can list the tags, read and write tag values. It can do low level reading and writing of the tagbase too, as well as add and list compound data types. The idea is to implement the full functionality of the libdax API in this module so that debugging will be much easier.
The readline library is currently used for entering commands in interactive mode. Commands can also be entered on the command line with the -x option. The -f option can be used to read the commands from a file.
Arduino I/O Module
I've just started working on an Arduino I/O Module. It basically consists of a sketch to load into the Arduino, a library to abstract the communications and the OpenDAX Arduino module. Once configured the pins on the Arduino are controlled by tags in the server. Right now it is very immature, but since I have a personal use for this it is likely to get done pretty quickly.
Regression Testing Module
I use the daxtest module as a way to test the features of the program as I add them. The module has recently been completely overhauled. It uses Lua scripts as the central testing method. Each test is contained in a script. Each of these testing scripts is called from a main test script that gives them a name and prints the status. If the test script raises an error, the main script counts it as a failed test and prints the error message to the screen.
Parts of the tests are written in C and other parts are pure Lua. There are generic functions for adding tags and CDT's as well as reading and writing, so some functionality can be tested by just writing Lua scripts. Other tests are more complex and they have functions written in C that are called from these Lua test scripts. The reason for calling them from the test script is that we can easily disable tests if we are not currently interested in it and we use the error trapping functionality of Lua to determine pass/fail for the test. The Lua / DAX interface functions that might be commonly used with other modules were removed from the code base and put into the libdaxlua library.
There is also a "Lazy Programmer's" test script which is a place where quick tests can be generated as features are developed without having to add a complete, formal test. Once the features are implemented a formal test can be generated from the Lazy Programmer's test.
The daxtest module cannot test everything in the system but it is very good at testing the API implentation. There are other issues outside of the API that will have to have other tests built. The daxtest module does nothing to test the functionality of any given module.
Lua Interface Library
There was a lot of duplication in some of the Lua interface code. Functions to add, read and write tags were duplicated in the daxtest module as well as the daxlua module. I was also starting to kick around the idea of creating a Lua Module (not to be confused with any OpenDAX modules) that could be required() in a Lua script and allow an entire OpenDAX module to be written in Lua. Once I started working on this I couldn't stand to duplicate all that code again. I actually had some good reasons before because the code wasn't exactly duplicated (there were some thread locking differences), but now this was too much. It also convinced me that the library needed to be thread safe.
The library was made thread safe, the Lua to OpenDAX wrapper code was put in the new library and the library was structured in such a way that it could be used as a Lua module. The code duplication was removed and now OpenDAX modules can be written entirely in Lua (I know the redundant use of the word 'module' is confusing).