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 are the latest addition to the system. They 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 but I am hesitant to create too many modules until I am happy with the API.
I'm presently working on adding event handling capability to tag database. At first it'll simply be tag change events, but eventually I will probably add > and < events for types that can handle it. There may also be some system level events like alarm clocks, module failures, etc.
Modules are still not started in the proper 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.
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 run on an periodic schedule at the moment but I hope to add the ability to run them based on asynchronous events at some point.
There are functions for adding, reading and writing tags to the server. As well as adding new compound data types.
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.
Modbus Module
The Modbus module is pretty solid at the moment but only 'RTU Master' is implemented. I have every intention of adding full modbus functionality to the module but right now it just does what I need.
I just converted the configuration over to Lua so it's much easier to configure now. The module can communicate over a serial port or it can be connected to a network socket (UDP or TCP). This is to allow it to talk directly to device servers (i.e. a LanTronix) directly without any external help.
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.
Only a few of the function codes are implemented at present.
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 of reading commands from a file is not yet implemented.
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.
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.