[FR] Ability to disable Live Movement when using Creality DWIN UI.

[TheAndr0id]

Is your feature request related to a problem? Please describe.

I understand why this change was done, it's cool to twist the control nob and see the print head move.

But in practical use, it's a nuisance. Here's my experience:

I'm running behind schedule and I need to get a print started because I've promised someone something, something, whatever.

I turn on the printer, start the preheat for the nozzle and bed, clean the bed surface and go get the job sliced and on the SD card. I come back and find there's some smutz on the nozzle, and it's too close to the bed to get at it.

I try to move the nozzle up with the current live movement and twist the control and it moves like 2mm, So I spin the nob and it jumps up to 100+mm. Too much, I turn it back down to 50mm or so. Now on the X or Y axis, this isn't really an issue as movement is quick, but on the Z it takes FOREVER 😄 to move up to 100mm and then back to 50mm. I wipe down the nozzle and start the print.

Loading filament using the move extruder function is another exercise in "damn it, damn it, damn it".

I use DWIN (because that's why - shutup 😄) and this may or may not be an issue for other UIs. I know ProUI has a "live move" toggle, which is great, but this may require research to see the greater impact.

One thing that might be a bug is that while the head is moving, the control is stuck on that selection until the move is complete. Even clicking will not release the selector - which leads to more frustration because the action is click-twist-swear as the value is changed and the head is moving again....

Pre version 2.08 the movement system was a capture and execute, you entered the value, clicked the control nob and then the movement happened. You could issue a move, select another axis and give it a move command as well. (It's been a while, but I believe these were executed in sequence, not at the same time)

I feel (and I won't believe I'm alone here) that the "old" way was better.

I'm not looking to abandon the live move system, just to offer an option to configure at build time which one to use. (See below)

Are you looking for hardware support?

Nope.

Describe the feature you want

The ability to select live movement vs capture and execute movement of days gone by.

This doesn't need to be a toggle system (like ProUI) or anything, just a compiler directive at build time.

Additional context

I've already implemented this in my current build. Here's what I did:

First in configure.h, just after defining DWIN_CREALITY_LCD I added in a new define DWIN_DISABLE_LIVEMOVE.

Then I made a change to HMI_Move_X(), HMI_Move_Y(), HMI_Move_Z(), and HMI_Move_E() to use that define. Here's HMI_Move_X():

void HMI_Move_X() {
  EncoderState encoder_diffState = Encoder_ReceiveAnalyze();
  if (encoder_diffState == ENCODER_DIFF_NO) return;
  if (Apply_Encoder(encoder_diffState, HMI_ValueStruct.Move_X_scaled)) {
    Draw_Edit_Float3(1, HMI_ValueStruct.Move_X_scaled);
    #ifdef DWIN_DISABLE_LIVEMOVE
      HMI_Plan_Move(homing_feedrate(X_AXIS));
    #endif
    return HMI_Move_Done(X_AXIS);
  }
  LIMIT(HMI_ValueStruct.Move_X_scaled, (X_MIN_POS) * MINUNITMULT, (X_MAX_POS) * MINUNITMULT);
  current_position.x = HMI_ValueStruct.Move_X_scaled / MINUNITMULT;
  Draw_Edit_Float3(1, HMI_ValueStruct.Move_X_scaled, true);
  DWIN_UpdateLCD();
  #ifndef DWIN_DISABLE_LIVEMOVE
   HMI_Plan_Move(homing_feedrate(X_AXIS));
  #endif
}

Basically it changes when HMI_Plan_Move() is called - either when the control is clicked or during the control movement.

[TheAndr0id]

Small update, just using the HMI_Plan_Move when the control knob is clicked doesn't work as intended. Its commands need to be rolled out (could be rolled into a new function) and simplified. This seems to work similar to the pre 2.08 version:

void HMI_Move_X() {
  EncoderState encoder_diffState = Encoder_ReceiveAnalyze();
  if (encoder_diffState == ENCODER_DIFF_NO) return;
  if (Apply_Encoder(encoder_diffState, HMI_ValueStruct.Move_X_scaled)) {
    Draw_Edit_Float3(1, HMI_ValueStruct.Move_X_scaled);
    #ifdef DWIN_DISABLE_LIVEMOVE
      checkkey = AxisMove;
      EncoderRate.enabled = false;
      if (!planner.is_full()) {
        planner.synchronize();
        planner.buffer_line(current_position, homing_feedrate(X_AXIS));
      }
      DWIN_UpdateLCD();
      return;
    #endif
    return HMI_Move_Done(X_AXIS);
  }
  LIMIT(HMI_ValueStruct.Move_X_scaled, (X_MIN_POS) * MINUNITMULT, (X_MAX_POS) * MINUNITMULT);
  current_position.x = HMI_ValueStruct.Move_X_scaled / MINUNITMULT;
  Draw_Edit_Float3(1, HMI_ValueStruct.Move_X_scaled, true);
  DWIN_UpdateLCD();
  #ifndef DWIN_DISABLE_LIVEMOVE
   HMI_Plan_Move(homing_feedrate(X_AXIS));
  #endif
}

I believe the extra planner.synchronize() call in HMI_Plan_Move() is the issue.

[thinkyhead]

The Creality DWIN code could use a caretaker if it is still considered viable. You would just have to periodically submit PRs for the improvements you are making in your fork. It is better to do it that way rather than post suggestions like this and hope someone else does the legwork.