I've just about got my first I/O module working. I've ported a Modbus program that I wrote many moons ago to work with OpenDAX. It's not any more complete than the DAX core is at this point but my goal at the moment is to get some specific Modbus devices working and that's really all the code that I have been working on.
The reason for this rambling is to discuss the next stage of the program. Before OpenDAX will be useful to anyone, it'll need some kind of logic module. For my purposes I'll just write a small C program to act as a module just to get my project going. Others will want to program in Ladder, SFC, Structured Text (ST), Instruction List (IL) and Fuction Block Diagram. Other projects of this type are using programs that take one or all of these five IEC programming languages and compile them into C or C++. I have never really liked this approach. It's great if you plan to load the code into a specific machine and let it run forever without modification. I am looking more toward the process control industry where we'll need to be able to do online editing and online debugging. It seems to me that it'd be more difficult to make online changes while the process is running if our logic is compiled into our module. I guess debugging could be done if we used a mechanism to read the tags.
My intention is to create a single interpreter (Probably IEC 61131 Instruction List) that all the other languages could be 'compiled' into. Only having one language in the interpreter makes the interpreter much simpler and if I'm not mistaken this is how the IEC suggests that it be done. A simple interpreter also means fewer bugs. It'll also make the module easier to integrate into any redundancy scheme that we dream up.
To make online changes a second text file that included the changes could be loaded and parsed. Then the module could switch between each program at the top of the scan. Once the changes were deemed okay then the old memory area could be freed and the newer parsed version would be executed, and a cached copy written to disk for the next startup. This is the simplest way to handle online changes, but there's no reason that more elaborate methods of inserting and deleting logic, while online, couldn't be written. All this is much easier in an interpreter.
I don't know if any of this makes online debugging easier. That would mostly be an issue to be handled by the individual editors. There may be a mechanism added to the IL interpreter to allow for breakpoints and this would add a feature that i have wished for, for many years in my job.
All in all I think that building an interpreter for the main logic module will be the way to go. This would not limit anyone from creating a logic module from a compiled language. In fact one of my goals is to create a library of Ruby bindings so that modules could be written in Ruby. I'm sure that if the project takes off then others would create Python and Perl bindings too. At least I hope they would. I don't want to limit anyone that wants to build modules but I'd like to make it easy on the end user too, and I think that an interpreted logic module does that. The end user wouldn't even have to have gcc installed, let alone flex or bison.