search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.28k stars 19.24k forks source link

doubleclick for babystepping #13129

Closed ruggb closed 5 years ago

ruggb commented 5 years ago

I have tried V2 bugfix 870757a and a number of previous builds I have tried V1 bugfix 3a216bb and a number of previous builds. I have set the timeout to 2250 there is about a 750ms dead time b4 I can even click the 2nd time. Unfortunately, I do not have a V1 that works as I cleaned them all off my system, BUT it did work at one time.

Description

Doubleclick to access Babystepping does not function I have a coreXY printer, but I don't think that matters

Steps to Reproduce

  1. [First Step] boot machine
  2. [Second Step] Doubleclick display button at status screen
  3. Babystepping and Doubleclick are both enabled.

Expected behavior: [What you expect to happen] Babystep setting line should appear and be adjustable

Actual behavior: [What actually happens] display enters main menu, the goes back to status screen on 2nd click The only time I can get to babystepping is via the Tune menu while the unit is actually printing.

Additional Information

I don't think it is ever getting to the routine in menu.cpp == 195 * General function to go directly to a screen but then maybe it isn't suppose to. New folder.zip

forkoz commented 5 years ago

For me its more like I hold the button down.

ruggb commented 5 years ago

that does not work for me. What ver/build are you using? What type printer?

forkoz commented 5 years ago

Just a normal cartesian with a build from this month. Also, it has to be printing to do babystepping. I have it configured to do z move when its not.

Roxy-3D commented 5 years ago

Just a normal cartesian with a build from this month. Also, it has to be printing to do babystepping. I have it configured to do z move when its not.

I thought we decided we wanted Z Babystepping to work even when not printing? I will have to check the history, but I thought I patched that in both v2.0.0 and bugfix v1.1.x ?

InsanityAutomation commented 5 years ago

@Roxy-3D that got dropped back out a few months ago. Id still prefer the condition on it to be steppers active, and on stepper timeout reset ui to status to kick people out of the screen to avoid confusion.

forkoz commented 5 years ago

It would just be a shortcut to z offset if you're not printing. Then you have to hunt down move Z if say you just rebooted and need to lift the head off a bad print. Would be cool to have it switch to Z offset when you started a print but bed/he are still pre heating.

ruggb commented 5 years ago

Just a normal cartesian with a build from this month. Also, it has to be printing to do babystepping. I have it configured to do z move when its not.

I thought we decided we wanted Z Babystepping to work even when not printing? I will have to check the history, but I thought I patched that in both v2.0.0 and bugfix v1.1.x ?

Roxy - you did. This all worked at one time. Double click any time and it would do babystepping, printing or not.

ruggb commented 5 years ago

@Roxy-3D that got dropped back out a few months ago. Id still prefer the condition on it to be steppers active, and on stepper timeout reset ui to status to kick people out of the screen to avoid confusion.

why did you break something that was working just the way a lot of people wanted it?

ruggb commented 5 years ago

Just a normal cartesian with a build from this month. Also, it has to be printing to do babystepping. I have it configured to do z move when its not.

OK, can someone explain Z MOVE? Maybe that will be all I need if it works while not printing. I do not have that enable as I have no clue what it does.

InsanityAutomation commented 5 years ago

@ruggb I didn't and I agree with it being active at more times. I'm just aware of when it changed roughly. I could go back and look at the blame tab on the file and see who did though and see if I can get an answer as to why. If the reason isn't really relevant anymore I can make a PR to change it back when I get to work on it.

InsanityAutomation commented 5 years ago

And z move is just a quick method to jog z, no relationship to the Z offset.

ruggb commented 5 years ago

And z move is just a quick method to jog z, no relationship to the Z offset.

does it work like babystepping for Z, or is it different?

ruggb commented 5 years ago

@ruggb I didn't and I agree with it being active at more times. I'm just aware of when it changed roughly. I could go back and look at the blame tab on the file and see who did though and see if I can get an answer as to why. If the reason isn't really relevant anymore I can make a PR to change it back when I get to work on it.

OK, DC does work when printing, so is there a simple mod to bypass the "is it printing" test until this can be resolved or not?

Roxy-3D commented 5 years ago

that got dropped back out a few months ago. Id still prefer the condition on it to be steppers active, and on stepper timeout reset ui to status to kick people out of the screen to avoid confusion.

Well... How about if the stepper motors have timed out... We re-enable them and then do the specified Z-BabyStepping? After all... If the user is trying to move the Z-Axis, that is a valid reason to re-enable the stepper motors. I'm more in the camp that if the user is trying to Z-BabyStep... you do it. You don't try to second guess if it should be allowed. You do what ever it takes to accomplish what the user wants.

And it is only a couple lines of code to do that.

ruggb commented 5 years ago

the problem with re-enabling the steppers is the position of Z will likely change - at least it will on my unit when the steppers are disabled. Then the ref point is invalid. So it may be best to kick it out when the steppers are disabled. However, using babystepping should reset the timeout. more thinking - therein lies the problem. WHEN can you use babystepping? IMHO, it is only valid when one knows where Z is. So it should not be available before a home all is performed or after the steppers have timed out. To use it when not printing you must start with a home all. It isn't very useful if you don't know where Z is anyway. I guess Z_MOVE can be used for that since it does not go negative and does big steps.

InsanityAutomation commented 5 years ago

@ruggb that's kindve the lines we've been discussing on discord :)

ruggb commented 5 years ago

OH, I was reacting to this statement "We re-enable them and then do the specified Z-BabyStepping? After all..." - OK sound like you got it under control......

Roxy-3D commented 5 years ago

Actually.... Suppose my nozzle is off to the side of the bed, and below the bed? Doesn't it make sense to allow me to use Z-BabyStepping to get my nozzle to a place where I can home the machine?

My opinion of Z-BabyStepping is that it is outside of normal Marlin activity. It is a back door to let the user tweak things for what ever reason independent of what Marlin thinks the nozzle position is.

And in fact, the original Pull Request of the BabyStepping that got merged kind of fulfilled that idea.

gloomyandy commented 5 years ago

@Roxy-3D Is there a good reason to use babystepping in your off the bed case rather rather than just moving Z?

Roxy-3D commented 5 years ago

I'm not sure about the answer... But as a user... I don't want artificial constraints put on me. I'm kind of used to Double Clicking and being able to move the nozzle. Do I want to be forced into a different mode of operation? Probably not.

This stuff is difficult enough without the firmware putting extra constraints on the user.

gloomyandy commented 5 years ago

@Roxy-3D A good answer I can see that (though personally I've never used babystepping so it is not something I'd ever think about doing). Having said that I assume that there is a difference between babystepping and moving the Z, so perhaps there is good reason for being sure that the user actually understands that the two operations are not the same. So for instance using babystepping to move the nozzle (when off to the side of the bed and after homing) below the bed could I think create a very bad situation as that would mean that the Z zero position is now below the bed, whereas if you use a normal Z move the Z zero position is not changed.

ruggb commented 5 years ago

I use babystepping to fine tune the first layer distance when printing and to adjust the first layer distance and Z endstop when not printing. I do not use the XY BS as I find no use for it AND I don't think it works for CoreXY. However, since I upgraded to a Piezo nozzle probe/endstop, I have not used it. But I did have a need for it the other day to recalibrate my probe which is why this came up. Z_MOVE does not appear useful to me as it only moves + and is defined for big steps, thought the steps can be made as small as BS steps. Going below the bed could be a problem for uninformed users, but without it, it doesn't work for me. If Z0 happens to be Z0.2 for some reason, I wouldn't be able to adjust/test it closer to Z0.00

forkoz commented 5 years ago

I mean there should be a way to make everyone happy with configs. I get using baby stepping to get Z offset and I definitely use it to fine tune the offset when printing. To obtain the original Z I'm not usually baby stepping but using the lowest increment of moving Z after a home. With a shim I get a "good enough" Z and then babystep while printing if something is off. If I like the new values I M500.

Sometimes I want to adjust Z just before the heaters have finished heating because I know this print needs to be .05 or .1 more squished or something. I can't do that and have to babysit the printer while it warms up. So this is a downside I deal with.

But move Z is very important if your printer has a reset or if you want to move the head away from the bed while heating to say 110c. Heat from the bed affects that initial sensor reading. If I just home and let the sensor get up to 80-90c I'd definitely be baby stepping the hell out of that first layer because of how off it is.

The way it is now, you get big moves for moving the head and little moves for adjusting the Z when printing. I certainly don't want my Z moves saved as the offset and it would take forever to go anywhere at .01. Definitely use them both.

So really, I think this is just a clash of workflows and not a "wrong" or "right" way.

Roxy-3D commented 5 years ago

Having said that I assume that there is a difference between babystepping and moving the Z,

BabySteps are injected into the stepper drivers at a very low level. Marlin's positioning and tracking logic doesn't even know the extra steps were done. It is a 'back door' to all of the real logic.

ruggb commented 5 years ago

I use Repetier and configure a script to do a home all. The last step is to move the bed away from the nozzle 20mm. I am also configure to drop the bed 4mm b4 it does a home. I guess without a computer connected it gets a little more challenging. If BS were not "back door" one would not be able to go negative as Z move does not. I think that is the whole point of BS.

Roxy-3D commented 5 years ago

If BS were not "back door" one would not be able to go negative as Z move does not. I think that is the whole point of BS.

Yes...

I think there are a lot of 'use cases' for BabyStepping. Different people use it for different things. In my case... I'm always messing with things and I don't care to 'recalibrate' my printer's Z-Axis all the time. It is easier to just get it 'close', and any time I print, I double click and get the nozzle to exactly the right height while the skirt is being printed.

And in fact... That is why the Double Click feature was added. I wanted a super simple way to activate the Z-Axis BabyStepping at the start of a print...

ruggb commented 5 years ago

YES, A long time ago I modified the menu on all my builds so that the BS function was on the top of the main menu page. That resulted in a 2 click access to it. I suggested that and you had a better idea. Well, the same but different - still 2 clicks. I loved it - thanks - now I didn't have to make all those mods.

InsanityAutomation commented 5 years ago

I just posted a few changes. Should allow most to get the functionality desired with these options. Let me know if I missed anything or someone needs something different. See PR #13191

InsanityAutomation commented 5 years ago

Although Scott disagrees and stripped most of it out, the initial version of what I had is still here - https://github.com/MarlinFirmware/Marlin/pull/13191/commits/609ffa3ffb02f994f5766e92512ae8ca3513a98a

If anyone wants to put it in their own branches or continue discussion on it here.

ruggb commented 5 years ago

If I am interpreting you correctly, It seems like there are a number of people who want this based on this thread and other issues started because of its absence. Maybe Scott needs to tell us why he does not want it. It is not a mandatory function. It is selectable if one prefers. Why is Scott mandating that no one can have it?

thinkyhead commented 5 years ago

Other firmware also follows the maxim of only making babystepping available after starting a job, and Marlin's early maintainers felt it was important too, so it's not just my own fancy.

I really don't think babystepping is appropriate to use when XY steppers are not moving, and I do think that babystepping is a hack best avoided. I appreciate its availability during my first layer, but if I found myself using babystepping in other scenarios I would stop, slap myself, and go improve the code or fix the real issue.

I will add the feature if it means a lot to y'all, but my intent is to focus on making better UI for the things we currently use babystepping for instead of encouraging more use of babystepping. I don't see that it helps to make babystepping available when the motors happen to be humming, which is an easy cue to miss. If you want to be thoroughgoing, you'll want to force the motors to turn on if they happen to be off.

InsanityAutomation commented 5 years ago

@thinkyhead With probes from the nozzle becoming more common, this has become a critical point of the initial setup and calibration phase. If you can go to a fixed point and babystep to a particular gap and set the z offset, you can prevent a destroyed build surface from the nozzle scraping against it. Its not quite as easy to set a probe height with the nozzle off the build surface as it is an endstop.

Perhaps ill take a video of my normal commissioning routing this weekend for a good use case sample of where this becomes incredibly useful. As a side note, one of the most prevalent recurring support requests Chris see's is people asking how to get babystepping working as it is in the commissioning guides for most bed leveling sensors nowadays. Many times they miss getting into the menu before movement stops, or just try to print without setting the initial height and crash the nozzle into a brand new print surface.

As for enabling the steppers when its called, thats why I added the auto home on entry. Its for precision, especially when merged with M851. You should not be able to do fine adjustment to z offset and probe offset if position isnt precisely known. If match with M851 is disabled, then its not relevent. Its just a jog move so to speak at that point.

The PR I had opened attempted to allow every requested scenario as configured. I did still need to go look at M290 and add some of it there though. I know @marcio-ao had a PR around for ExtUI methods to tie in as well.

boelle commented 5 years ago

@ruggb still working on this?

InsanityAutomation commented 5 years ago

Will probably be a couple small tweaks left, but maybe not till after mrrf depending how time goes here...

boelle commented 5 years ago

oki doke, was just following up on my last "cleaning" frenzy :-D

ruggb commented 5 years ago

I figured out an EASY tweak to fix this. Now it works like I expect/want it to - till you change it again.

boelle commented 5 years ago

i dont change anything :-D @thinkyhead does

ruggb commented 5 years ago

it was a collective "you"

boelle commented 5 years ago

:-D

recoil6 commented 4 years ago

Hi ruggb, I know this is closed however I am having this issues with the latest nightly could you please elaborate on the "EASY tweak to fix this" thanks!

ruggb commented 4 years ago

I don't know about the latest. I don't exactly remember this tweak. It seems like they just keep trying to break this function. describe what you have and what it is doing.

GhostlyCrowd commented 4 years ago

I don't know about the latest. I don't exactly remember this tweak. It seems like they just keep trying to break this function. describe what you have and what it is doing.

You know if you had explained your "tweak" 12 months ago in March 2019, then maybe it wouldn't be broke again. If something is broken and you know how to fix it, contribute it to the open source project or don't bitch.

This firmware is the collective work of many who are willing to share and not just ride the free wave of functionality.

ruggb commented 4 years ago

@GhostlyCrowd I have bad experiences trying to get anybody to listen to my fixes so I have chosen not to bother y'all with my work. It was sort of like the attitude your comment is displaying. Go ahead and check out my previous work. I will respond and help anyone if I can and have the info. Looking at the latest config files I would say they are becoming overwhelming. There is too many special equipment functions and not enough explanation of what some of the added functions do. But then, what do you care, right? Like the total rejection of the double tap on homing because y'all had an extra command where it shouldn't have been. Probably still not fixed.

GhostlyCrowd commented 4 years ago

@GhostlyCrowd I have bad experiences trying to get anybody to listen to my fixes so I have chosen not to bother y'all with my work. It was sort of like the attitude your comment is displaying. Go ahead and check out my previous work. I will respond and help anyone if I can and have the info. Looking at the latest config files I would say they are becoming overwhelming. There is too many special equipment functions and not enough explanation of what some of the added functions do. But then, what do you care, right? Like the total rejection of the double tap on homing because y'all had an extra command where it shouldn't have been. Probably still not fixed.

Nothing changes when the only person who knows whats wrong squanders it.

Again you sound like you know what the problem is but you do not want to share it, it helps no one and doesn't move this open source project forward, which is a communal effort of many, not just one.

It's counter productive to chastise everyone for their ignorance which is what you're trying to do and yet withhold the solution, which again seems like you're doing.

So my suggestion still stands contribute to the solution or don't dump on everyone for not reading your mind on the fix.

This is a fairly simple concept, if you can fix this then do it and every one will thank you, otherwise comments from the peanut gallery about how incompetent other developers are is just fodder, due to inexperience and lack knowledge and of the grasp of concept of how hard a code base to support several dozen platforms and hundreds of thousands of users is to maintain with out the collective help of many.

thinkyhead commented 4 years ago

Please, no impertinent comments, especially on old, closed issues.

Your comments go out —possibly as email— to every person that is still subscribed to the issue, and unless it is pertinent to the issue itself, there are better avenues.

If you are re-experiencing a bug, even if it presents in the same way as some older issue, please post a new bug report, because the cause and solution may be wholly unrelated. You can link back to old related issues if needed.