Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] G35 - Specifiable End Position #20281

Closed
qwewer0 opened this issue Nov 26, 2020 · 5 comments · Fixed by #20298
Closed

[FR] G35 - Specifiable End Position #20281

qwewer0 opened this issue Nov 26, 2020 · 5 comments · Fixed by #20298
Assignees
Labels
T: Feature Request Features requested by users.

Comments

@qwewer0
Copy link
Contributor

qwewer0 commented Nov 26, 2020

Description

At the moment ASSISTED_TRAMMING_WAIT_POSITION is only used in ASSISTED_TRAMMING_WIZARD, but it would be useful to add the ASSISTED_TRAMMING_WAIT_POSITION or similarly specifiable position with G35 too, for easier screw adjustment.
The homing at the end is unnecessary (and a waste of time) if at the end the nozzle moves to a wait/safe position.

Feature Workflow

  1. Start G35
  2. G35 probes the bed
  3. No homing happens (to not waste time)
  4. Nozzle moves to ASSISTED_TRAMMING_WAIT_POSITION or similarly specifiable position (for easier screw adjustment)
  5. End of G35

Additional Information

  • Provide pictures or links that demonstrate a similar feature or concept.
  • See How Can I Contribute for additional guidelines.
@qwewer0 qwewer0 added the T: Feature Request Features requested by users. label Nov 26, 2020
@shitcreek
Copy link
Contributor

Looking at menu_tramming.cpp, we have this bit:

  #ifdef ASSISTED_TRAMMING_WAIT_POSITION
    // Move XY to safe position
    if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("Moving away");
    const xyz_pos_t wait_pos = ASSISTED_TRAMMING_WAIT_POSITION;
    do_blocking_move_to(wait_pos, XY_PROBE_FEEDRATE_MM_S);
  #endif

It shouldn't be too hard to insert that into G35.cpp. I'm guessing it should be plugged into the LOOP_L_N function like so:

  // Probe all positions
  LOOP_L_N(i, G35_PROBE_COUNT) {

    // In BLTOUCH HS mode, the probe travels in a deployed state.
    // Users of G35 might have a badly misaligned bed, so raise Z by the
    // length of the deployed pin (BLTOUCH stroke < 7mm)
    do_blocking_move_to_z((Z_CLEARANCE_BETWEEN_PROBES) + TERN0(BLTOUCH_HS_MODE, 7));
    const float z_probed_height = probe.probe_at_point(screws_tilt_adjust_pos[i], PROBE_PT_RAISE, 0, true);

    #ifdef ASSISTED_TRAMMING_WAIT_POSITION
      // Move XY to safe position
        if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("Moving away");
        const xyz_pos_t wait_pos = ASSISTED_TRAMMING_WAIT_POSITION;
        do_blocking_move_to(wait_pos, XY_PROBE_FEEDRATE_MM_S);
    #endif

@shitcreek
Copy link
Contributor

shitcreek commented Nov 27, 2020

Perhaps we should also have a parameter to utilize the position or not:

if(parser.seen('P')) do_blocking_move_to(wait_pos, XY_PROBE_FEEDRATE_MM_S);

@qwewer0
Copy link
Contributor Author

qwewer0 commented Nov 27, 2020

@shitcreek Thanks for the feedback.

If it is added to LOOP_L_N, wouldn't it move to wait_pos after each point is measured? (without a "last point" check)

Perhaps we should also have a parameter to utilize the position or not:

if(parser.seen('P')) do_blocking_move_to(wait_pos, XY_PROBE_FEEDRATE_MM_S);

If there would be already and option to move away, why wouldn't someone want to use it? So I think it should move away without any extra parameter.

@qwewer0
Copy link
Contributor Author

qwewer0 commented Nov 27, 2020

Tested #20298 and it works, but I'm not sure if it needs some more work.

@sjasonsmith sjasonsmith self-assigned this Dec 27, 2020
@sjasonsmith sjasonsmith linked a pull request Dec 27, 2020 that will close this issue
@qwewer0 qwewer0 closed this as completed Jan 5, 2021
@github-actions
Copy link

github-actions bot commented Mar 6, 2021

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.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T: Feature Request Features requested by users.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants