manual moves

edited May 2016 in Tips & Tricks

what do you think about assign g-code macros to buttons without writing ui_action?

as i know we can use the  executeFString(...);  and it´s possible to assign that to a if(READ(pin)...

the only thing i found is that if it´s not a single instruction it should be executed in slowAction because of watchdog.

backgound for idea is for example  1 button for move to +x , some more buttons to scale step (*0,1 * 10* 100 for example)
checking multiple buttons with the result to a mask would enable us to use key combinations for commands.

generating uiaction for each combination is a lot of typing and i think we have a lot of users knowing about gcodes
but not about changing firmware.

would easy and universal  to be used for macros and uiactions like

#define UI_KEYS_MACRO_BUTTON_LOW......// in ui.h

#define macro1 "G92 X0"// anywhere, i think for a seperate file"macros.h"

#define Bit_0 1  // defining bit values
#define Bit_1 2
#define Bit_2 4

void......(uint16_t &action) // check keys and write keymask
  uint8_t MacroKeymask=0;
     // UI_KEYS_MACRO_BUTTON_LOW(68,Bit_6,MacroKeymask);
     // UI_KEYS_MACRO_BUTTON_LOW(69,Bit_7,MacroKeymask);

  case Bit_0 : GCode::executeFString(PSTR("G28"));  // use normal format
  case Bit_1 :
               GCode::executeFString(PSTR(macro1));  //use macro
  case Bit_2 : action=UI_ACTION...;         // return ui_action
  case (Bit_2+Bit_3) : GCode::executeFString(PSTR("G91\n g1 X2 Y2 f400\n G90"));  // example for multi key use

what do you think about that?


  • We have something similar, see end of configuration.h

    #define USER_KEY1_PIN UI_DISPLAY_D5_PIN // D5 to display (not used for graphics controller), change to other pin if you use character LCD !
    #define USER_KEY2_PIN UI_DISPLAY_D6_PIN // D6 to display (not used for graphics controller)...
    #define USER_KEY3_PIN UI_DISPLAY_D7_PIN // D7 to display (not used for graphics controller)...
    #define USER_KEY4_PIN -1

    Having something similar for gcodes would be great I think. At least for the few users having many keys. Such a implementation for 4-10 keys would help for most cases.
  • well,we could also implement a i2c version for the users which want buttons but have no pins free .
    i know we already have possibility in ui but i think macros should be independent from ui.
    so it depends on user if using ui_action or g-code macro. both would be possible even mixed.

    i think about "feature_macro" and "feature_i2c_macro".,
    i can also make a little schematic/ pcb layout for the i2c stuff just to implement a 23017 and place that on github.
    i´d prefer 23017 because of speed up to 400kHz.

  • Sounds like we need a bit of macro magic here.

    Lets say we have 4 input parameter
    1. Number 0-15
    2. gcode to run
    3. Switch type
    - No key connected (to ignore this case
    - Normally Open
    - Normally Closed
    - I2C Normally Open
    - I2C Normally Closed
    4. Pin

    From this the key initalization/polling can be done and executed. All you need is some clever macro magic that takes the 4 parameter and creates the correct C++ code. Trick is 3. must be a string like NOT_USED and you expand straing names with 
    #define INIT_NOT_USED
    #define MIX(a) INIT_ ## a

    Best is to check fastio.h how this is exactly done. There they use it to have macros for each pin.
  • ok, will think it over , my actual priority is still the laser stuff , so i won´t start immediate ;-)
    anyway , have a simple solution running for myself to avoid writing lots of ui-actions during my
    tests but momentarily it´s just ugly breadboard style combined with some weird thought´s about
    possible features.

Sign In or Register to comment.