2 sec time gap between Printer and LCD Menu command

[didli]

Hi to you all ! I'm trying to adapt MarlinRCBugfix to my geeetech prusa i3 Pro B, with ramps 1.4 (which previously used Marlin 1.0.2). And everything's going fine except for one strange behavior I can't solve :
There's a time lag of approximately 2 sec between a command issued from the LCD Menu (REPRAP_DISCOUNT_SMART_CONTROLLER) and the printer response. It's slightly inconvenient because it can somewhat caused some unwanted manipulation errors.
I'm not entirely sure it is a bug actually, so I was wondering if I was missing something in the marlin config ?

[manianac]

Do you mean every command, or only when moving an axis?

And is this while printing, or just at idle?

[didli]

At idle, moving an axis. I didn't test while extruding though. If I put my old firmware back (based on marlin 1.0.2), everything's fine again, so I'm guessing something was updated and I can't find what changed.

[manianac]

There was a change to LCD requested moves a while back, I don't remember when exactly. But instantaneous moves were causing issues if you accidentally went too far and then adjusted back, waiting for the entire move to complete.

The delay was introduced to allow you to set what move you wanted, and then it would update after the delay. So what you're describing is normal behavior.

[Roxy-3D]

So what you're describing is normal behavior.

And if so... Almost for sure it is configurable to what ever time delay is appropriate for your printer.
But I know nothing about this topic. I'm off messing with a different part of the code base.

[didli]

OK, normal behavior, noted. So ... where can I adjust that please ?

[lrpirlet]

Well, I have no time looking for that particular change...

However, do have a look at all the release notes... https://github.com/MarlinFirmware/Marlin/tags

You will find there the changes listed since 1.0.2... (there are quite a few)... If you find a defined variable for that delay, please tell us... I have the sensation that this is HARDCODED

[didli]

hmm... OK. That's going to be some challenge. Still it's a little bit strange : having a delay like that feels more like a regression or a default than an improvement.

[manianac]

Ok now that I actually see the code the delay shouldn't be longer than a quarter of second. You should try enabling debugging with M111 and attempt some moves.

In ultralcd.cpp you can attempt removing the manual_move_start_time requirement in manage_manual_move, or you can try decreasing the maximum timeout to see if it has any effect.

  /**
   * If the most recent manual move hasn't been fed to the planner yet,
   * and the planner can accept one, send immediately
   */
  inline void manage_manual_move() {
    if (manual_move_axis != (int8_t)NO_AXIS && ELAPSED(millis(), manual_move_start_time) && !planner.is_full()) {
      planner.buffer_line_kinematic(current_position, MMM_TO_MMS(manual_feedrate_mm_m[manual_move_axis]), manual_move_e_index);
      manual_move_axis = (int8_t)NO_AXIS;
    }
  }

  /**
   * Set a flag that lcd_update() should start a move
   * to "current_position" after a short delay.
   */
  inline void manual_move_to_current(AxisEnum axis
    #if E_MANUAL > 1
      , int8_t eindex=-1
    #endif
  ) {
    #if E_MANUAL > 1
      if (axis == E_AXIS) manual_move_e_index = eindex >= 0 ? eindex : active_extruder;
    #endif
    manual_move_start_time = millis() + (move_menu_scale < 0.99 ? 0UL : 250UL); // delay for bigger moves
    manual_move_axis = (int8_t)axis;
  }

[thinkyhead]

having a delay like that feels more like a regression

These may provide some insight into the changes:

#3110
#4285

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.