LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Run Levels

Basic concept

Run levels are a way to think about ESTOP, machine on, faults, and such sequencing. A machine using this approach would have a (configurable) number of levels. At the bottom would be a completely dead machine (estops tripped), and at the top would be a running machine. The machine builder could specify intermediate levels as needed, depending on the complexity of the machine. The architecture would allow the builder to specify the conditions (such as interlocks) needed to move up a level, the conditions (such as faults) that would force it down a level, and the resulting outputs (such as pumps on, servos enabled) and internal EMC state associated with each level.

This page is a place to brainstorm the concept and see if it can evolve into something that we can build into EMC2 in place of the current ESTOP/ESTOP_RESET/MACHINE_OFF/MACHINE_ON system.

Misc Ramblings

From the GUI side, there should be NML messages to request a move up or down the runlevel stack. I don't know whether the format should be "move up one level", with multiple messages needed to get all the way up, or "move to level X" which would allow it to move thru multiple levels. There would also need to be either a "get current level" message, or current level would need to be part of the STAT messages.

Even if we allow a "move multiple levels" command, it should be implemented to move one level at a time. Starting at the current level, it would check the (builder specified) conditions for moving to the next level, and if OK, it would go to that level, and do whatever actions that entails. Then repeat, until either the request has been satisified, or the conditions prevent moving higher.

Requests to move down the stack would be honored unconditionally, but would still move one level at a time performing actions at each level. (The assumption here is that lower levels are "safer" than higher levels, so downward movement is movement to a safer state.

Requests to move up the stack probably should come only from the GUI or other operator interface, this needs discussed. (The idea is that human action is needed to move the machine to a more dangerous state.)

Requests to move down the stack must be able to come from anywhere. For example, a HAL bit from an estop switch might move nearly all the way down, a loss of hydraulic pressure might move to an "idle" level part way down, a following error might move to a faulted state one notch below the top, etc.

The number of levels, their names, the conditions needed that must be true to move up (and which force a move down if they become false) and the actions at each level should all be configurable. The actual runlevel code should probably run in realtime, so it can respond immediately to hardware requests such as estops. Software requests (by way of NML messages) would be passed to the RT code, and the current runlevel would be available as status to all parts of EMC.

Others are invited to add their thoughts....

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited October 20, 2005 12:14 pm by Jmkasunich (diff)
Published under a Creative Commons License