Z compensation rules, when it's on, when it's off?
-
Which firmware version are you running? I recommend 2.01. Earlier versions sometimes had a problem if you homed Z using a Z probe when a height map was already loaded.
-
I'm on the latest RC2. I'd still like to know what the rules are for when the map is used and when it isn't as well as the baby steps.
There's no way for the community to properly use the printer if that's not clear.
-
At power up, no bed compensation is active.
Mesh bed compensation becomes active when you run G29 S0 (or just G29) to probe the grid, or if you run G29 S1 to load a height map file.
You can disable mesh bed compensation using G29 S2 or M562.
The M122 command includes a report of whether bad compensation is active or not.
Does that help? Most or all of this should be covered at https://duet3d.dozuki.com/Wiki/Using_mesh_bed_compensation.
-
Not really. There is confusing behavior between the baby-steps and the machine itself. For example, if you adjust the baby steps while the machine is idle, nothing happens. The next time you make a G1 movement, then the baby steps kick-in. So, the fact that the baby-steps have no effect until there's a movement is a bit of a cumbersome implementation. For example, watching a print go, lets say it's running one long line, that's a single G1 command, you're clicking baby-step, nothing, click again, nothing, again and again and again, nothing. until the next movement when the head slams into the bed.
The baby steps should be immediately effective whether or not the machine is moving.
I've run into this behavior while leveling my bed after a print because the Z offset will read some large number, though I think I'm at zero, then I realize the baby steps are still on and I reset them (through a macro), and nothing happens, then when I move the Z .05, whoosh, a big movement happens. This is really not expected or desired behavior.
-
@gnydick I would think that common usage of baby stepping would be during the first layer of the print while printing a brim or skirt to get the layer dialed in before the actual part starts. That way you can visually see how it's affecting your print.
Resetting babystepping ideally should be done through homing Z after using M290 R0 S0 to clear babystepping
-
@phaedrux That's exactly my use case. But the first layer may consist of just a few long lines before you reach critical areas of the print. If the baby-stepping doesn't move instantly, you're either going to under or over shoot your goal.
-
Also, @dc42 , the reset baby-steps g-code only resets 1mm at a time. you have to issue it multiple times.
-
And, @dc42 , my questions weren't really answered here or in the page you linked. Baby-stepping, how is it implemented? Is it a permanently applied offset that affects all of the z moves or is it just during a print.
And, it seems like applying baby-steps isn't just after the currently running command, they seem to come in bursts. I've clicked -.05 rapidly and nothing happens for quite a while, then all of a sudden, boom, they all kick in at once.
I'm not trying to be a pain, but I'm not really getting the support I need here.
-
@gnydick said in Z compensation rules, when it's on, when it's off?:
And, @dc42 , my questions weren't really answered here or in the page you linked. Baby-stepping, how is it implemented? Is it a permanently applied offset that affects all of the z moves or is it just during a print.
And, it seems like applying baby-steps isn't just after the currently running command, they seem to come in bursts. I've clicked -.05 rapidly and nothing happens for quite a while, then all of a sudden, boom, they all kick in at once.
I'm not trying to be a pain, but I'm not really getting the support I need here.
Baby steps are used as a "real time" correction, usually at the start of your print. It's intended to make temporary changes to that print only, and should get reset on the next print (although I've seen my last baby step setting get carried over to the next print. Maybe it only gets reset between comps).
For example, on my Rostock, it always has a high spot between the Z & Y pillars. So even though I've comp'ed the bed, the nozzle is going to drag across this spot. To compensate, I usually click "+" on the baby steps fives times, and once the Duet is done with the segment that it's printing, it will show "0.25mm" on the baby steps. That's the delay that you are seeing between when you click and when it actually shows up.
As to its effect on the remainder of the print, yes, every layer from that point on is adjusted up by your baby step offset.
-
I know how baby-steps work. I'm not sure why nobody is understanding my point/question...
Problem 1) The duet seems to NOT ADJUST IN REALTIME. That is the problem. RAMPS based printers move the Z axis immediately whether or not there is any motion otherwise. The fact that there is delay in the duet, makes it more difficult to use. It is very easy to overshoot or undershoot the adjustment you need because feedback is not happening in realtime.
The Live Adjust Z offset on my Prusa is the equivalent of baby-steps. It behaves in real time and I never have to change it again. It stores the setting by updating the z-offset in the eeprom. That would be a MUCH better implementation to have.
Problem 2) Background: The baby-steps DO NOT get reset between prints, which is fine with me, if I needed it once, I'll probably need it again until I update the Z-endstop.g settings file. Problem: The problem I run into, is not knowing 100% absolutely if the currently applied baby-steps affect the motion while manually moving the printer via the web console Machine Control. I'm guessing it does, but, again, if you change the baby-step back to zero, the Z-axis does not move. If I reset baby-steps, it seems to not move the Z axis, but change the Z position number. That, in and of itself, is a horrible implementation. If I baby-step it .05mm, I expect it to move immediately. By modifying internal position pointers and not providing realtime feedback, the system requires a higher level of technical skill and intuition. Make the machine dumb. Jog a value, move the machine. Simple as that.
This makes tuning the machine a bit more awkward because you don't get realtime feedback to your changes. So, if I want to zero out my Z axis and forget to reset the baby-steps, I get the wrong answer. This is all manageable via macros to make sure to reset baby-steps, turn off bed and mesh compensation, etc., but the fact of the matter is, realtime feedback is needed in order for the printer to behave intuitively. If I jog the Z .05mm through Machine Control, I expect the Z to move .05mm. Again, if I baby-step it .05mm, I expect it to move immediately. This is just poor implementation.
Problem 3) The reset baby-step g-code M290 R0 S0 does not reset it. It only subtracts 1mm from the current baby-step offset.
-
@gnydick said in Z compensation rules, when it's on, when it's off?:
Problem 1) The duet seems to NOT ADJUST IN REALTIME.
I agree, it would be better if babystepping was actioned faster. The problem is, although it's easy to do real-time babystepping that works in many cases (as Marlin does), it's much harder to do real-time babystapping that is guaranteed to work always and never results in missed steps no matter what printer architecture and stepper drivers used. Step-servo drives are a particular problem, because they get confused if they receive step pulses at irregular intervals.
One workaround is to use mesh bed compensation. Turning it on causes long moves to be split up into shorter segments whose length is about the spacing of the mesh. babystepping will normally be applied during the movement that immediately follows the current one.
I may implement an option for immediate baby stepping, but it would need to be configurable so that it can be turned off. Or perhaps the firmware should automatically segment the first layer finely so as to better support baby stepping? Would that be sufficient, or do some people use baby stepping after the first layer?
The Live Adjust Z offset on my Prusa is the equivalent of baby-steps. It behaves in real time and I never have to change it again. It stores the setting by updating the z-offset in the eeprom. That would be a MUCH better implementation to have.
Like I said, it's easy to implement a solution that works for a particular fixed printer configuration.
I'd like to know what other users think about the idea of preserving the baby stepping offset through power cycles.
Problem 2) Background: The baby-steps DO NOT get reset between prints, which is fine with me, if I needed it once, I'll probably need it again until I update the Z-endstop.g settings file. Problem: The problem I run into, is not knowing 100% absolutely if the currently applied baby-steps affect the motion while manually moving the printer via the web console Machine Control. I'm guessing it does
Yes, baby stepping applies to all motion.
Problem 3) The reset baby-step g-code M290 R0 S0 does not reset it. It only subtracts 1mm from the current baby-step offset.
That's a bug and I will fix it in the next release.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Z compensation rules, when it's on, when it's off?:
I'd like to know what other users think about the idea of preserving the baby stepping offset through power cycles.
Personally when I needed a constant baby stepping, I included it in the homing files with G92.
-
@dc42 said in Z compensation rules, when it's on, when it's off?:
I'd like to know what other users think about the idea of preserving the baby stepping offset through power cycles.
In my opinion, that would be a really bad idea. Given that baby stepping was introduced with the purpose of adjusting the first layer on a per print basis. Preserving the setting would be the same as adjusting the Z offset in config.g, which we can already do. The more places that configuration settings get set or overridden , the more chance there is of people getting confused and making incorrect adjustments.
-
I think I would like it cleared when the print completes. If you need a permanent change add or subtract the baby steps just used to homed height so the next print doesn't need to be stepped. If you print the curreent baby step offset before clearing it the user can go to the console and see the value. Thius way forces you to update your printer if you needs baby steps. What I really would like to see is the mesh correction appllied at each location diisplayed..
-
I intensionally clear baby stepping after a print as part of my end code. I always watch the skirt print and adjust as needed.
I guess if you're used to Marlin and having a permanent z offset this makes more sense. But reprap has G31 S-1 to measure an accurate trigger height and sets your z offset that way. Only time you'd want to change it is either after a mechanical change and should be remeasured anyway or to make slight per print changes which is exactly what baby stepping does now.
-
If the "remembering baby-steps permanently" implementation was to actually update the z-offset for you, then you wouldn't have to worry about editing in multiple places. But I don't know if the duet is capable of editing files on the card.
-
@gnydick said in Z compensation rules, when it's on, when it's off?:
If the "remembering baby-steps permanently" implementation was to actually update the z-offset for you, then you wouldn't have to worry about editing in multiple places. But I don't know if the duet is capable of editing files on the card.
You should only need to adjust one parameter to set the Z=0 height. If you use a Z probe to set Z=0 then it's the G31 Z parameter.
-
@gnydick the issue is that different printer configurations set the Z height in different ways. If you have a probe then its set as the probe offset. Without a probe you may set it as the Z minimum in config.g or set it with G92 in homez.g (and also homeall.g). That is why there are multiple places that it could be changed. Also bring multiple tools into the mix and it gets more complicated.
I agree baby stepping needs to take effect as quickly as possible/instantly, if that requirement can be squared with supporting the n+1 and growing number of kinematics and axis configurations that RepRapFirmware supports.
