Baby stepping not working



  • Hi,

    Baby stepping has not worked in my last attempts to print at 0.1mm layers. The attached photo shows three rounds of skirt outlines. The left is at babystep 0 and the right is at 2.9mm babystepping. I just kept clicking on the stepping on the paneldue.

    I have fw 2.02RC1

    0_1540663089462_IMG_20181026_183846_1.jpg

    The logs from console.
    0_1540663103612_IMG_20181026_183918.jpg


  • administrators

    You are asking to put the head at almost -3mm, but you probably have Z0 in your M208 S1 command; so the firmware won't let you go below zero.



  • You are correct.
    M208 X-35.95 Y-5.75 Z0 S1 in config.g

    The odd thing is I used babystepping before.

    the 3mm is only me stepping a lot to see if anything is happening.



  • @dc42 Does the printer reset the baby steps per print? When I print, I sometimes need -0.2mm baby steps, but if I finish the print and start the next, it will need -0.4mm instead?


  • administrators

    When baby stepping was first introduced in RepRapFirmware, it was reset to zero when you homed Z. In later firmware versions, it isn't reset by homing. It is always reset to zero when you start the Duet.



  • @dc42 said in Baby stepping not working:

    You are asking to put the head at almost -3mm, but you probably have Z0 in your M208 S1 command; so the firmware won't let you go below zero.

    That would explain why I never had the impression that baby-stepping does have any effect (always wanted to go lower) on my machine and finally gave up on using it.

    Am I right that if I set e.g. M208 ... Z-1 that I will also need to use G92 Z0 at the end of homez.g and homeall.g? AFAIR, homing will set the position to the lowest axis value (in case it is a min endstop), doesn't it?

    But, personally, I think that baby-stepping should overrule the axis minima/maxima because usually this is used sparingly and therefore should not pose any risks (but as being a developer myself I know that one should expect at least one user finding a way to break something in an unexpected manor 😂 ).



  • I'd like to chime in here, that I'm seeing the same problem. I'm using the DWC, and not the PanelDUE. I see the same result trying to babystep upwards and downwards, that is that it makes no difference at all to the actual print head position.

    Of course the firmware is entirely different, but I did see something similar with Marlin on my MBot printer. It would move the Z axis just fine for homing, or making larger movements, but if I set the layer height to less than 0.3mm, it would simply not move the Z axis at all, until I bumped up the Z acceleration from the defaulted values. The firmware would report that the Z axis was rising by 0.2mm at a time, but the print head would stay at the same height above the print bed until I raised the acceleration value.

    Babystepping worked fine on the 1.21 firmware, but I changed the Z screws at the same time that I changed the firmware, so unfortunately, I can't absolutely nail down what change broke it. The old screws were 5mm 0.8mm lead, and the new ones are T8*8, so it changed from 4000 steps/mm to 400. I don't know if the lower step count is responsible. I'm tempted to try using some standard M8 threaded rod (1.25mm lead, 2560 steps/mm) to see if that makes a difference.



  • @supraguy said in Baby stepping not working:

    The old screws were 5mm 0.8mm lead, and the new ones are T8*8, so it changed from 4000 steps/mm to 400. I don't know if the lower step count is responsible.

    I don't think that this is responsible as with 400 steps/mm there still is a full-step distance of 0.04mm. Additionally using x16 micro-stepping you get down to 0.0025mm per step and I guess no one is even using baby-steps smaller than 0.01mm increments - which still are 4 microsteps.



  • @wilriker said in Baby stepping not working:

    I don't think that this is responsible as with 400 steps/mm there still is a full-step distance of 0.04mm. Additionally using x16 micro-stepping you get down to 0.0025mm per step and I guess no one is even using baby-steps smaller than 0.01mm increments - which still are 4 microsteps.

    Most likely not, however, as a matter of completeness, I feel that it really should be mentioned, since ignoring changes that "don't matter" is how you miss solving problems where the solution does not come obviously to hand.

    I plan on making one more change, I'm going to change the Z motion dialog boxes to 0.025mm for the smallest step (To match what I had set up as a babystep increment) and see if that moves the Z axis. I'll give that a try tonight to see if that has an effect on the issue.



  • @supraguy said in Baby stepping not working:

    Most likely not, however, as a matter of completeness, I feel that it really should be mentioned, since ignoring changes that "don't matter" is how you miss solving problems where the solution does not come obviously to hand.

    That is definitely the right way to do. 👍

    But to the problem itself: might it be the same issue that I assume to have, i.e. your minimum Z is set to 0 and after homing Z will sit in 0 as well? As I understood @dc42 in this case baby-stepping will not allow you to go lower.

    I plan on making one more change, I'm going to change the Z motion dialog boxes to 0.025mm for the smallest step (To match what I had set up as a babystep increment) and see if that moves the Z axis. I'll give that a try tonight to see if that has an effect on the issue.

    One side-note here: it usually is recommended to move Z axis only in full-step increments. So in your case that would be 0.04mm steps. I had the same type of lead screw and now ordered T8*2 so my increments go down to 0.01mm and I don't have to remember any specific steps (because I won't do any moves shorter than 0.01mm anyway).


  • administrators

    @wilriker said in Baby stepping not working:

    One side-note here: it usually is recommended to move Z axis only in full-step increments

    The usual recommendation is that the layer height should be a multiple of full steps. That doesn't preclude using smaller amounts of movement for bed compensation or baby stepping.



  • @dc42 said in Baby stepping not working:

    The usual recommendation is that the layer height should be a multiple of full steps. That doesn't preclude using smaller amounts of movement for bed compensation or baby stepping.

    Thinking about it, that makes sense. Thanks for correcting me! 👍



  • Okay, something new.

    0.1mm babystepping appears to work. 0.05mm babystepping does not. I ran a print last night, and stepped babystepping from -0.2mm to 3.5mm in 0.05mm increments, and it didn't make the slightest amount of difference.

    I increased babystepping to 0.1mm, rebooted the Duet, and tried again. It will not go below 0mm, but it will go TO 0mm. Since the first layer was supposed to be 0.2mm thick, it did go lower, and it also would go higher, well off of the bed, then back down to correct height.

    My config.g is as follows:

    ; Configuration file for Duet WiFi (firmware version 1.20 or newer)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool on Tue Jun 26 2018 20:51:43 GMT-0600 (Mountain Daylight Time)
    ; Modified by DMG 08/30/2018
    
    ; General preferences
    G90                              ; Send absolute coordinates...
    M83                              ; ...but relative extruder moves
    
    ; Custom configuration
    M584 X0 Y1 Z2:4 E3               ; Set Z motors on drives 2 and 4 DMG 08/30/2018
    M671 X-43.0:309.0 Y137.5:137.5 S4  ; Set the Z motor relative locations DMG 08/30/2018
    
    ; Network
    M550 PLEADSCREW3D                ; Set machine name
    M552 S1                          ; Enable network
    M586 P0 S1                       ; Enable HTTP
    M586 P1 S1                       ; Enable FTP
    M586 P2 S0                       ; Disable Telnet
    
    ; Drives
    M569 P0 S1                       ; Drive 0 goes forwards
    M569 P1 S1                       ; Drive 1 goes forwards
    M569 P2 S1                       ; Drive 2 goes forwards
    M569 P3 S1                       ; Drive 3 goes forwards
    ; DMG 08/30/2018 I think the following line need to be configured
    M569 P4 S1                       ; Drive 4 goes forwards
    M350 X16 Y16 Z16 E16 I1          ; Configure microstepping with interpolation
    M92 X400 Y400 Z400 E101.8        ; Set steps per mm
    M566 X450 Y225 Z120 E120         ; Set maximum instantaneous speed changes (mm/min)
    M203 X7200 Y7200 Z780 E2400      ; Set maximum speeds (mm/min)
    M201 X950 Y450 Z50 E450          ; Set accelerations (mm/s^2)
    M906 X800 Y800 Z800 E1200 I35    ; Set motor currents (mA) and motor idle factor in per cent
    M84 S30                          ; Set idle timeout
    
    ; Axis Limits
    M208 X0 Y0 Z0 S1                 ; Set axis minima
    M208 X242 Y277 Z180 S0           ; Set axis maxima
    
    ; Endstops
    M574 X2 Y2 S0                    ; Set active low endstops
    
    ; Z-Probe
    M574 Z1 S2                       ; Set endstops controlled by probe
    M558 P8 H8 F780 I1 T9000 R0.8 Z1 ; Set Z probe type to unmodulated and the dive height + speeds
    ;M558 P0 ; for now, since it's not working...
    G31 X0 Y0 Z-0.5 P100             ; Set Z probe trigger value, offset and trigger height
    M557 X30:190 Y37.5:237.5 S40     ; Define mesh grid
    
    ; Heaters
    M305 P0 T100000 B4138 C0 R4700   ; Set thermistor + ADC parameters for heater 0
    M143 H0 S110                     ; Set temperature limit for heater 0 to 110C
    M305 P1 T100000 B4138 C0 R4700   ; Set thermistor + ADC parameters for heater 1
    M143 H1 S280                     ; Set temperature limit for heater 1 to 280C
    
    ; Fans
    M106 P0 S0.3 I0 F500 H-1         ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P1 S1 I0 F500 H1 T45        ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P2 S1 I0 F500 H1 T45        ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on
    
    ; Tools
    M563 P0 D0 H1                    ; Define tool 0
    G10 P0 X0 Y0 Z0                  ; Set tool 0 axis offsets
    G10 P0 R0 S0                     ; Set initial tool 0 active and standby temperatures to 0C
    
    ; Automatic saving after power loss is not enabled
    
    ; Custom settings
    M574 E0 E1 S1                    ; Set E0 E1 endstops for active low
    ;M581 E0 S0 T2 C0                 ; Run trigger2.g on falling edge for baby stepping button
    ;M581 E1 S0 T3 C0                 ; Run trigger3.g on falling edge for baby stepping button
    

    That last bit was in place because I was going to add a couple of on-printer buttons for babystepping, however that has not actually been implemented.

    Firmware Name:	        RepRapFirmware for Duet 2 WiFi/Ethernet
    Firmware Electronics:	Duet WiFi 1.02 or later
    Firmware Version:	2.02RC3(RTOS) (2018-10-17b2)
    WiFi Server Version:	1.21
    Web Interface Version:	1.22.3
    

  • administrators

    How are you sending the 0.05mm babystepping commands, and which firmware and DWC versions are you using? I've just tested 0.05mm babystepping using DWC 1.22.4 and the RRF 2.02RC4 release that I am preparing, and it works for me.



  • The versions are as reported above. I'm using the DWC to send the babystepping commands. 0.1mm steps work as expected, 0.05mm steps do not.

    I have noticed one more detail, not sure if it's relevant. I can get to the printer DWC, but I can't actually see the physical machine right now. I was looking through the config, and I remember that I did run the file to level the Z screws inbetween testing the 0.05mm non-working babystepping, and the 0.1mm working babystepping.

    bed.g:

    ; bed.g
    ; called to perform automatic bed compensation via G32
    ;
    ; generated by RepRapFirmware Configuration Tool on Tue Jun 26 2018 20:51:43 GMT-0600 (Mountain Daylight Time)
    M561 ; clear any bed transform
    ;M558 P0 ; unset Z probe for now...
    ; Probe the bed at 3 points (Right on top of the piezo sensors for now, will change later)
    M561 ; clear any bed transform
    M201 X950 Y600 Z5 E450
    G30 P0 X15.0 Y137.5 H0 Z-99999
    G30 P1 X205.0 Y137.5 H0 Z-99999 S2
    M201 X950 Y600 Z75 E450
    

    This has a couple fo M201 commands in it, (Please ignore comments, they're all out of whack. The M561 was in, then out, now seems to be back in twice...

    I'm sure that I pulled the original M201 command at the end from my config.g, but now it seems to have a different Z acceleration value. I am not sure at what point I changed that in my config.g, but I a certain that with the values as they originally were, babystepping worked as expected. In my config.g file, Z accel is set to 50mm/s^2, but the end of bed.g resets it to 75mm/s^2.

    I will run some more tests on this tonight when I get home. (I'm at GMT-6 timezone, so that'll be pretty late for you on that side of the Atlantic.)



  • Okay, I no longer have a clue what's going on.

    I can consistently power up the Duet, home all axes, and start printing, and baby stepping will not work. Nothing, up or down. I tried increments of 0.01mm, 0.04mm (1 full step), 0.05mm, 0.08mm, 0.1mm, 0.5mm and 1mm. I tried them all by stepping upwards first, stepping downwards first. The Z axis does not move. I set Z acceleration anywhere from 5mm/s^2 to 100mm/s^2 by increments of 5. I tested with a 20mm test cube print with a skirt having 25 loops of skirt 10mm from object.. 🙂

    If I run the automatic bed compensation, then it works.

    Entering the M561 into the GCode console does not do it. Not even entering it twice, which seems to be what I have in my bed.g file for some reason. Must be something left over from when I was mucking about with it. Re-entering the M201 doesn't seem to do it. That's also how I was trying different accelerations. Once babystepping works, it seems to keep working, so I've left it at 0.04mm

    For the time being, I have a workaround, though I don't understand why it works.


  • administrators

    @SupraGuy, which firmware version are you using?



  • 2.02RC3

    @supraguy said in Baby stepping not working:

    Firmware Name:	        RepRapFirmware for Duet 2 WiFi/Ethernet
    Firmware Electronics:	Duet WiFi 1.02 or later
    Firmware Version:	2.02RC3(RTOS) (2018-10-17b2)
    WiFi Server Version:	1.21
    Web Interface Version:	1.22.3
    

  • administrators

    Thanks!

    • Can you confirm that the bed compensation you are running is G29 mesh bed compensation?
    • Does baby stepping work if you just load a height map (G28 S1), or do you actually need to probe using G29?
    • If you send G29 S2 to cancel using the height map, does baby stepping stop working again?

    PS - if you are using bed.g to do the bed compensation, please post the contents of that file.



  • I do compensation in 2 ways. There is a mesh compensation (heightmap.csv) file. It does occur to me that I probably never reload it. (It's currently full of 0.000 values anyway)
    heightmap.csv

    RepRapFirmware height map file v2 generated at 2018-09-20 12:25, mean error 0.000, deviation 0.000
    xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
    35.00,185.00,25.00,250.00,-1.00,75.00,75.00,3,4
      0.000,  0.000,  0.000
      0.000,  0.000,  0.000
      0.000,  0.000,  0.000
      0.000,  0.000,  0.000
    

    So I do (Or plan to) use G29 for mesh leveling. I'm debugging issues with my underbed piezo sensors, now, too, so they're only currently being used for homing, and it's just now at the point where I can use those for the G32 compensation, calling the bed.g file which is used to set a base level on the 2 Z screws, which seem to like to drift a little when the machine is powered off. I do not send a G29 S2 to unload it under any circumstances that I know of.

    I will try re-loading it and see if that affects babystepping. Will again have to wait until I am home. (There's that timezone thing again.)


Log in to reply