It would be nice if the Z offset in the Motion settings could be adjusted realtime while manually moving the Z axis.
The idea is to go to the menu where we can manually adjust the axis positions and manually lock in the Z offset when we lower the probe to a height instead of manually calculating and adding/subtracting the adjusted distance value to the existing offset.
@Roxy-3D has made something like this with the UBL System.
So, why hasn't it been ported here?
Still being worked on. You can checkout the ubl branch and give it a shot.
So, why hasn't it been ported here?
For US$500 I will port it here right now, without delay! 馃槅
I'd be willing to contribute $20 to that happening.
I'd be willing to contribute $20 to that happening.
@timeshell Appreciated! But to be fair, this is Roxy's baby, and she's working hard on it. Best thing for now is to just test with devel-ubl and give her some feedback. That work won't be included in 1.1.0 but will follow shortly in 1.1.1.
I hear ya. I'll see what I can do.
so, Im also want to have this option.
It would be nice if the Z offset in the Motion settings could be adjusted realtime while manually moving the Z axis.
so, Im also want to have this option.
This isn't exactly what is being discussed, but check out the Z-Axis BabyStepping. When your print starts and it is drawing the skirt around it, you can do the Z Babystepping to get the height just where you want it. And if you load the UBL branch you will see in the Roxy Configuration.h file a #define for QUICK_ACCESS_TO_Z_BABYSTEPPING I wired up a separate switch so when I press it, I can just twist the Encoder Wheel to adjust the height. If you don't want to wire up a separate switch, there are instructions in the Configuration.h file to over ride the Kill switch (typically located right next to the Encoder Wheel) to do this.
But all that complexity aside.... You should investigate the Z-BabyStepping and see if that does what you want. (I didn't like having to drill down 3 or 4 menu levels. I wanted instant access to it because I only have so much time to get things adjusted before the skirt is done being printed.)
Hey Roxy - Just started using UBL and i'm absolutely loving it, any chance the Z-axis babystepping could be extended so that it can be done anytime during the 1st layer and not just the skirt? The Prusa Mk2 firmware has something similar with their Live Adjust Z and it is really helpful to get a perfect 1st layer.
Hey Roxy - Just started using UBL and i'm absolutely loving it, any chance the Z-axis babystepping could be extended so that it can be done anytime during the 1st layer and not just the skirt? The Prusa Mk2 firmware has something similar with their Live Adjust Z and it is really helpful to get a perfect 1st layer.
To be honest, I didn't realize it could only be done while printing the skirt. For me, that is the only time that it made sense to do it. Are you sure it doesn't work all the time? It would seem like it should.
But "Yes!", assuming it only works while the skirt is being printed, I certainly can change that. Can you verify that it needs to be changed. (I can't right now... It will be tomorrow before I can print anything.)
The other question I have is did you enable the QUICK_ACCESS_TO_Z_BABYSTEPPING option?
Hm i changed the QUICK_ACCESS_TO_Z_BABYSTEPPING to correspond to what was my kill switch pin and commented it out (41) and now pressing the pin doesn't seem to do anything. I noticed in the "Tune" section that i can change the Bed Z value during the 1st layer and that seems to be doing what i was looking for!
I think i need to play around a little more with the pin assignments to rule out using the wrong one for the quick access functionality, but otherwise nevermind - thanks for everything you've done.
Hm i changed the QUICK_ACCESS_TO_Z_BABYSTEPPING to correspond to what was my kill switch pin and commented it out (41) and now pressing the pin doesn't seem to do anything.
You probably already removed ANY AND ALL definitions for KILL_PIN. (I'm doing the development on a RAMPS board. There are 4 or 5 different definitions for the KILL_PIN depending upon what LCD Display you have.)
You also have to go into Configuration_adv.h to enable the
#define BABYSTEPPING
Yep i had to do that in Confiuration_adv, but now it works during skirt and the rest of the 1st layer as well so no changes necessary!
Very cool! Nice work @Roxy-3D - I can't wait to try it out on my Makerfarm Prusa i3v! Since the first layer is the key to a successful print, I second the idea to migrate to RCBUGFIX or RC. Such an awesome feature! Let me know if you need any help with that.
Very cool! Nice work @Roxy-3D - I can't wait to try it out on my Makerfarm Prusa i3v! Since the first layer is the key to a successful print, I second the idea to migrate to RCBUGFIX or RC. Such an awesome feature! Let me know if you need any help with that.
I'm working on this issue (or feature) right now. I think I'm going to eliminate the z_offset and instead just push or pull the entire mesh up or down (in real time). I'm also thinking I'll remember and display how much the Mesh has been shifted. But that number won't actually be used for anything other than to help the user know how much they have shifted things.
The one question I have about doing things this way is this: If it is done later in a print, especially when the print is past the 'Fade Height' it won't have any affect. Does anybody ever adjust the nozzle during the middle of a print?
I think if you have it active on the first layer by default that would be huge help already. Later, you can add a configuration option for this to be active for xx number of layers. I like the idea of pulling/pushing the entire mesh.
This will be a game changer because currently if you see a problem with the first layer being too "deep" or too "shallow" you have to stop the print and reset the z-offset in your slicer software.
I think if you have it active on the first layer by default that would be huge help already. Later, you can add a configuration option for this to be active for xx number of layers. I like the idea of pulling/pushing the entire mesh.
I'm a little hesitant to make the Z-BabyStepping active by default on the first layers. The reason is there is other important information the user wants to see during the first layers. They want to know the temperature of the bed and nozzles is correct and holding steady. They also may be using the Z: display to verify the slicing and layer height.
Instead... I'm making it super easy to get into the Z-BabyStepping menu. I already have an option that will replace the 'Kill' function of the LCD Button. You just press that button and you are Z-BabyStepping. But for sure there will be people that say "What are you thinking? It is dangerous to remove the Kill button." So I'm now (today & tomorrow) working on making it so a 'Press and Hold' of the Encoder Wheel will put you in Z-BabyStepping. And once you see the LCD Mode change, your hand is already on the Encoder Wheel. You can spin it one way or the other.
Normally when you spin the encoder wheel the percentage of flow speed is changed can't you make it so that on the first layer if you spin the encoder wheel it just changes the Z-BabyStepping
@Roxy-3D Can you confirm if baby stepping is supposed to work with Bilinear Bed Leveling in RC8? My client tried baby stepping on the z-axis tonight, and could not get it to move the head up or down during a print.
@Roxy-3D Can you confirm if baby stepping works with Bilinear Bed Leveling in RC8?
I suspect it does work. I'm going to start porting UBL to RC-8 in the next day or two. I'll be bringing up a Vanilla version of RC-8 on my gMax printer to start that effort. I'll try to remember to check the Z-BabyStepping as soon as that is limping along.
But... For sure... Z-BabyStepping is going to work on the RC-8 version of UBL.
So, that means it's not working in the main branch yet then...
So, that means it's not working in the main branch yet then...
No. That is not what I said. I said:
I suspect it does work.
And then I went on to say I need to bring up a vanilla version of RC-8 on my gMax so I can use that as the foundation to make an RC-8 version of UBL. I will check this out for you in the next couple of days.
Sorry, that's my mistake. I misunderstood the context.
And very soon... ThinkyHead will be back to look over all these issues and questions. My guess is it does work with Bi-Linear. But if by some chance it has issues, ThinkyHead did the Bi-Linear code. It will get fixed ASAP.
Give me a few days and I'll report what I find.
Can you confirm if baby stepping is supposed to work with Bilinear Bed Leveling in RC8?
AFAIK there should be no conflict. Babystepping is handled by the temperature ISR and is transparent to the high-level logic.
Thanks for all the work. Z babystepping really helps. My issue is I can't find any way to adjust Z offset from LCD. For example I change for a single print the E3D v6 for a Volcano so I don't want to move my capacitive sensor and I want to: home, then move the encoder on any LCD option to adjust offset and then store it to EEPROM yo easy hotend change. As I can't find any help out there, could you give me any clue about it? As others said Z baby stepping store option should be nice but I mean without printing already. Thanks for all and sorry about my poor English or misplaced comment.
I mean moving the encoder also moves Z to de new offset then you could m500 from the LCD menu. More or less like Ultimaker bed leveling but without touching the bed leveling screws.
Hi Roxy. Were you able to confirm whether there are any known issue preventing babystepping from working in either RC8 or the current RCBugFix?
@timeshell It is my belief Z-BabyStepping is fully functional in RC-8's RCBugFix. I don't have first hand experience with X & Y BabyStepping (I don't use it). But the Z-BabyStepping works correctly. And as you know... I've just added code to make a Double Click of the Encoder Wheel (from Status Screen) jump straight into Z-BabyStepping.
Why don't you load up the current RCBugFix and see if it works how you want it to. (You need to turn on the Double Click option at the end of Configuration_adv.h to use it.)
Actually, I'm asking on behalf of a client who has been having trouble with the Z babystepping. I don't have a Marlin board set up at the moment as I'm testing a Smoothieboard so I haven't been able to verify it for him.
Question: is there a way to control the pulse width signal in Marlin when baby stepping? We found the issue. His stepper drives require a minimum pulse width of 3.5us, the pulse width coming from marlin is 1.36us. Therefore, the drives never move, and baby stepping never works.
Most helpful comment
I'd be willing to contribute $20 to that happening.