This page is deprecated
Action Widgets
GladeVcp includes a collection of "canned actions" called EMC Action Widgets for the glade user interface editor. Other than HAL widgets, which interact with HAL pins, EMC Actions interact with EMC and the G-code interpreter.
EMC Action Widgets are derived from the Gtk.Action widget. The Action widget in a nutshell:
- it is an object available in glade
- it has no visual appearance by itself
- it's purpose: associate a visible, sensitive UI component like menu, toolbutton, button with a command. See these widget's 'General->Related Action' property.
- the "canned action" will be executed when the associated UI component is triggered (button press, menu click..)
- it provides an easy way to execute commands without resorting to Python programming.
The appearance of EMC Actions in glade is roughly as follows:
Tooltip hovers provide a description.
Action widget types
EMC Action widgets
These are one-shot type widgets. They implement a single action and are for use in
simple buttons, menu entries or radio/check groups.
EMC ToggleAction widgets
These are bi-modal widgets. They implement two actions or use a second (usually pressed)
state to indicate that currently an action is running. Toggle actions are aimed for use in ToggleButtons
?,
ToggleToolButtons
? or toggling menu items. A simplex example is the ESTOP toggle button.
Currently the following widgets are available:
- The ESTOP toggle sends ESTOP or ESTOP_RESET commands to emc depending on it's state.
- The ON/OFF toggle sends STATE_ON and STATE_OFF commands.
- Pause/Resume? sends AUTO_PAUSE or AUTO_RESUME commands.
The following toggle actions have only one assoicated command and use the 'pressed' state to indicate that the requested
operation is running:
- The Run toggle sends an AUTO_RUN command and waits in the pressed state until the interpreter is idle again.
- The Stop toggle is inactive until the interpreter enters the active state (is running G-code) and then allows user to send AUTO_ABORT command.
- The MDI toggle sends given MDI command and waits for its completion in 'pressed' inactive state.
The Action_MDI Toggle and Action_MDI widgets
These widgets provide a means to execute arbitrary MDI commands.
A simple example: Execute MDI command on button press
Here's a glade UI file which conveys the basics: upload:whoareyou.ui
Open it in glade and study how it's done. Start Axis, and then start this from a terminal window with gladevcp whoareyou.ui . See the hal_action_mdi1 Action and it's MDI command property - this just executes (MSG, "Hi, I'm an EMC_Action_MDI") so there should be a message popup in Axis like so:
You'll notice that the button associated with the Action_MDI action is greyed out if the machine is off, in E-Stop or the program is running. It will automatically become active when the machine is turned on and out of E-Stop, and the program is idle.
Parameter processing in the Action_MDI and ToggleAction_MDI widgets
Optionally, 'MDI command' strings may have parameters substituted before they are passed to the interpreter.
Parameters currently may be names of HAL pins in the gladevcp component (in a later release, this will be
extended to cover HAL pins of other components as well). This is how it works:
- assume you have a HAL SpinBox? named speed, and you want to pass it's current value as a parameter in an MDI command.
- The HAL SpinBox? will have a float-type HAL pin named speed-f (see HalWidgets description).
- To substitute this value in the MDI command, insert the HAL pin name enclosed like so: ${pin-name}
- for the above HAL SpinBox?, we could use (MSG, "The speed is: ${speed-f}") just to show what's happening.
Here's the example UI file for gladevcp: upload:speed.ui , and here's what you get:
An advanced example: Feeding parameters to an O-word subroutine
It's perfectly OK to call an O-word subroutine in an MDI command, and pass HAL pin values as actual parameters.
Here's an example UI file
upload:owordsub.ui and O-word sub:
upload:oword.ngc
Place oword.ngc so Axis can find it, and run gladevcp owordsub.ui from a terminal window. This looks like so:
Preparing for an MDI Action, and cleaning up afterwards
The EMC G-Code interpreter has a single global set of variables, like feed, spindle speed, relative/absolute mode and others. If you use G code commands or O-word subs, some of these variables might get changed by the command or subroutine - for example, a probing subroutine will very likely set the feed value quite low. With no further precautions, your previous feed setting will be overwritten by the probing subroutine's value.
To deal with this surprising and undesirable side effect of a given O-word subroutine or G-code statement executed with an EMC ToggleAction_MDI, you might associate pre-MDI and post-MDI handlers with a given EMC ToggleAction_MDI. These handlers are optional and provide a way to save any state before executing the MDI Action, and to restore it to previous values. The signal names are mdi-command-start and mdi-command-stop; the handler names can be set in glade like any other handler.
Here's an example how a feed value might be saved and restored by such handlers (note that EMC command and status channels are available as self.emc and self.stat through the _EMC_ActionBase? class:
def on_mdi_command_start(self, action, userdata=None):
action.stat.poll()
self.start_feed = action.stat.settings[1]
def on_mdi_command_stop(self, action, userdata=None):
action.emc.mdi('F%.1f' % (self.start_feed))
while action.emc.wait_complete() == -1:
pass
Only the Action_MDI Toggle widget supports these signals.
Using the EMC Stat object to deal with status changes
Many actions depend on EMC status - is it in manual, MDI or auto mode? is a program running, paused or idle? You cannot start an MDI command while a G-code program is running, so this needs to be taken care of. Many EMC actions take care of this themselves, and related buttons and menu entries are deactivated when the operation is currently impossible.
When using Python event handlers - which are at a lower level than Actions - one needs to take care of dealing with status dependencies oneself. For this purpose, there's the EMC Stat widget: to associate EMC status changes with event handlers.
EMC Stat has no visible component - you just add it to your UI with glade. Once added, you can associate handlers with its following signals:
- state-related: "state-estop", "state-estop-reset", "state-on", "state-off" - emitted when E-Stop condtion occurs, is reset, machine is turned on, or is turned off
- mode-related: "mode-manual", "mode-mdi", "mode-auto" - emitted when EMC enters that particular mode
- interpreter-related: "interp-run", "interp-idle","interp-paused","interp-reading","interp-waiting" - emitted when the G-code interpreter changes into that mode
Status
This page will be current when the year 2010 is over. Authors Michael Haberler and Pavel Shramov.
Todo:
- for each widget, document signals which are acted upon
- this is a tutorial-type intro. Do the reference manual part.