manual moves

RAyWB

Hi,

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(62,Bit_0,MacroKeymask);
      UI_KEYS_MACRO_BUTTON_LOW(63,Bit_1,MacroKeymask);
      UI_KEYS_MACRO_BUTTON_LOW(64,Bit_2,MacroKeymask);
      UI_KEYS_MACRO_BUTTON_LOW(65,Bit_3,MacroKeymask);
      UI_KEYS_MACRO_BUTTON_LOW(66,Bit_4,MacroKeymask);
      UI_KEYS_MACRO_BUTTON_LOW(67,Bit_5,MacroKeymask);
     // UI_KEYS_MACRO_BUTTON_LOW(68,Bit_6,MacroKeymask);
     // UI_KEYS_MACRO_BUTTON_LOW(69,Bit_7,MacroKeymask);

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


what do you think about that?

Repetier

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_KEY1_ACTION UI_ACTION_FAN_SUSPEND
	#define USER_KEY2_PIN UI_DISPLAY_D6_PIN // D6 to display (not used for graphics controller)...
	#define USER_KEY2_ACTION UI_ACTION_SD_PRI_PAU_CONT
	#define USER_KEY3_PIN UI_DISPLAY_D7_PIN // D7 to display (not used for graphics controller)...
	#define USER_KEY3_ACTION UI_ACTION_LIGHTS_ONOFF
	#define USER_KEY4_PIN -1
	#define USER_KEY4_ACTION UI_ACTION_DUMMY
	*/

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.

RAyWB

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.

Repetier

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.

RAyWB

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.