Module Startup Order

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. Then the user can start a bunch of modules all at once that don't depend on each other and those modules can initialize themselves and then once they have started up the next group can start. I named these groups, "Startup Tiers."

The idea is this. You give each module that you want to start a "startup" number in opendax.conf. When it comes time to start all of the modules a loop starts at tier zero and works it's way up to the highest number given in the configuration. When it finds a module with that tier number it starts it. It continues to do this until there are no more modules of that tier. Once it has started all those modules it waits until each one reports that it is "Running." Once they are all running it moves on to the next tier.

Most of the startup work would be creating compound data types and tags. Once this is done the module signals the server that it is "Running."

It is important to note that there can't be any circular dependencies in this system. If module 'A' depends on module 'B' and module 'B' depends on module 'A' then the user will have to resolve those dependencies himself. This should not be much of an issue. Most I/O modules won't need any tags from other modules. Logic modules will create most of the rest of the tags in the system and interface modules shouldn't create any tags that would be needed by anything other than the interfaces themselves.