keyme / grbl Goto Github PK

Without the changes in #106, grbl will occasionally and without a reproduce-able reason not report the last line number in a sequence. Sending a movement request like a HOME command or an arbitrary small move will however produce that line number on the next go around. We should figure out what exactly is getting lost in the shuffle.

We need to make sure that adding a setting to the eeprom doesn't break everything upstream.

Breaks can include:

• Motion breaking due to unknown settings
• Overwriting of null terminators causing garbage in fields
• "EEPROM_ERROR" states due to improperly read settings

required for https://github.com/keyme/kiosk/issues/4300

uint8_t report_realtime_status()
{
  // **Under construction** Bare-bones status report. Provides real-time machine position relative to 
  // the system power on location (0,0,0) and work coordinate position (G54 and G92 applied). Eventually
  // to be added are distance to go on block, processed block id, and feed rate. Also a settings bitmask
  // for a user to select the desired real-time data.

In stepper.c:

  // Used to move to carousel magazine
  probe_carousel_monitor();

  // Check if probe is reached, if probing
  if (probe.isprobing)
    probe_check();

in probe.c:

bool probe_loop()
{
  // Start stepper
  st_prep_buffer();
  st_wake_up();

  SYS_EXEC |= EXEC_CYCLE_START;

  // Stay in this loop until alarm or until
  // the probe is found. probe_check() is called
  // from the stepper ISR to check if the active
  // probe is found.
  while (probe.isprobing) {
    // Check for user reset and allow
    // protocol_execute_runtime to run in this loop 

also in probe.c:

  if (!probe_loop())
    return;

  uint8_t probe_fail;
  if (sensor == MAG_SENSOR) {
    probe_fail = (probe.carousel_probe_state == PROBE_ACTIVE);
    if (probe_fail)
      memcpy(sys.probe_position, sys.position, sizeof(float) * N_AXIS);
  }
...

  if (sensor == MAG_SENSOR)
    report_probe_parameters(probe_fail);
...

It appears what can happen is (due to inertia presumably), we can check the carousel mag sensor (results in false), then very shortly after check the 'probe' sensor (results to true). The probe sensor returning true causes probe_loop() to exit, which in-turn causes probe_fail to evaluate to true, causing a false-positive error to be sent up to motion and then cutter.

We need a command to turn motor braking on and off at-will. This can probably be a system command and could potentially leverage the new systick functionality to enforce a timeout to turn things off again once we're idle for a certain period of time.

Add falling edge probing to Grbl, i.e. when we start with a sensor triggered, we probe in a specified direction until the sensor is no longer triggered. We will need to add this to kiosk, but Grbl should support it first.

Context:
When we measure keys, falling edge probing will allow us to follow the bitting path without moving the key away from the sensor first to make sure the sensor is no longer triggered. The benefits will be that measuring keys will not take up so much space on the y-axis (this is important if we want to add the brush tower back next to the measuring tower) and it will hopefully be more accurate.

Grbl kept homing after stop request and probably shouldn't

This shouldn't break anything, and will allow us to more tightly scope our variables (and use on-the-spot iterators...)

For the sake of simplicity, it would be nice if we made a few changes to how we store step parameters:

• Steps/mm can be stored in terms of full steps, and the 'active' steps/mm can be derived from full_steps_mm * microstepping multiplier
• Microstepping config can be stored as a whole multiplier (1, 2, 4, 16...etc) per axis rather than a mask The mask will become irrelevant with the SPI drivers and it would be nice if we had a unified way of describing this config (also, the new drivers support far more microstepping options that can't be encoded in 2 bits/axis)

See https://github.com/keyme/kiosk/pull/9651

Currently, grbl only updates the microstepping configuration on POR. We should change this to be reconfigured on every start (during the planning->execution state transition)

Changes were made in Grbl and Motion to support GCODE G38.2 (probing). Update command_line_stepper to reflect these changes.

Needs additional confirmation, but I have a strong inkling that tool dwell (G4) is broken due to the way grbl interprets gcode.

Dwell is performed inside the gcode parser as the command is parsed (as opposed to the planner). What this means is that in a 3 line gcode program, move->dwell->move, the dwell will be performed even if you haven't started execution yet, leading to an outwardly observed behavior of simply performing the two moves back to back.

Not a huge deal right now, but problematic overall.

Currently, cutter gets stuck in this situation. We should change that. Related to https://github.com/keyme/kiosk/issues/6188 and https://github.com/keyme/kiosk/issues/5882#issuecomment-178141155

Example:

Sending the following gcode will automatically execute without receiving a start:

$HY
G4 P0.1
G0 G90 Y+50X+5
G0 G90 y1x1
G90