Delta frustration - ready to give up.



  • Update 27/07/16:
    Not giving up thanks to this thread 🙂 Please note that during all this the Duet WiFi has performed absolutely flawlessly and has proved rock solid and stable. Thanks to Tony and David.

    I'm hoping with the experience here that I might get some help with this issue.

    Something that seems directly related to the DuetWiFi first.
    After getting the Delta rebuilt I got it printing first with the 0.8.5 board and 6 factor auto calibration, printed the new Duet case and it printed well despite the issue further down.
    Swapped the boards over yesterday and came back today and did a full calibration run, manual and then 6 factor and then tried to print. filament wouldn't stick to the bed…. a couple measurements showed that the reported z height of 0.3mm was actually at 0.6mm off the bed. Rerun and checked multiple times and every single time z height ended up 0.3mm +- 0.05 to far away from the bed.
    went back and very carefully measure all the tower to bed angles and found the bed wasn't quite square so trued that up and rerun all the calibrations again.... no change.
    If i start a print without running G32 then all is good with the height set in config.sys.... If I run G32 six or 4 factor the height gets set @0.3mm shortly leaving the first layer to far off the bed.
    Firmware 115b3 though I doubt it's related.
    Oh the only different thing was I moved all the probe points closer to the bed edge... might retry with the original points tomorrow.

    Next.
    The lean of 3 degrees in the +x +y direction for a small cylinder or 30mm cube is still happening, this is the frustration......

    Everything had been fine for about 6 rolls of filament then this started happening... i initially thought the entire frame had warped but a full pull down and rebuild with everything squared up sees the same thing still happening.

    All XYZ dimensions are spot on it just seems that the xy 0,0 location moves in the +xy direction as each layer goes up.
    The bed is 90 degrees to each tower so should be in the same plane as the effector.
    The effector measured over 200mm of vertical movement as best as i can measure on the three corners moves straight up and if anything moves opposite to the lean by the slightest of visible margins.
    Belts are new and tight.
    stepper pulleys don't show any slippage and I would expect this to show up and misaligned layers/corners but each layer is aligned.

    I printed the new duet case with the 0.8.5 board that still had the same lean on a 30mm cube but the Duet case is vertical and shows no indication of a lean which is really weird, haven't tried a larger print today due to the height issue discussed first

    Assuming all towers are truly square to each other and to the bed and all axis are moving the correct distances as indicated by dimensional accuracy what else is there to check/measure or scream about

    at near wits end on this
    Thanks
    Phil


  • administrators

    If the Z=0 height isn't right after auto calibration, that suggests that you don't have the Z probe trigger height set correctly in the G31 command in config.g.

    I can think of the following possible causes of a 3 degree lean of the print:

    1. Towers leaning by 3 degrees.

    2. Orthogonal axis compensation enabled. Make sure there is no M556 command in config.g.

    3. Firmware failing to generate the right number of steps. Run M122 after a print and check that the number of step errors reported is zero.

    4. Something happening on layer change that is causing the motors to skip the same number of steps each time. Possibly excessive jerk speed, travel speed or acceleration, or insufficient motor current.



  • I think geneb on the seemecnc forums had a similar problem (lean), and it was simply that he was not supplying enough current to his motion steppers. This was with a 0.8.5.



  • @dc42:

    If the Z=0 height isn't right after auto calibration, that suggests that you don't have the Z probe trigger height set correctly in the G31 command in config.g.

    I can think of the following possible causes of a 3 degree lean of the print:

    1. Towers leaning by 3 degrees.

    2. Orthogonal axis compensation enabled. Make sure there is no M556 command in config.g.

    3. Firmware failing to generate the right number of steps. Run M122 after a print and check that the number of step errors reported is zero.

    4. Something happening on layer change that is causing the motors to skip the same number of steps each time. Possibly excessive jerk speed, travel speed or acceleration, or insufficient motor current.

    re Z height
    G31 X0 Y0 Z1.85 P500 ; Set the zprobe height and threshold (put your own values here)
    The 1.85 is fully repeatable at 0,0 for nozzle within 0.05mm of the build plate for exactly z=0

    1. digital protractors and plumb bobs tell me no there is no lean on the towers.

    2. well blow me down there was a M556 line however with everything at 0 i would assume no impact…. also suspect it has been there since day 1 when all was good... now removed.
    ;*** If you are using axis compensation, put the figures in the following command
    M556 S78 X0 Y0 Z0 ; Axis compensation here

    3. Step errors has always shown zero from memory will recheck on next test.

    4. I've wound everything back in config.sys, will re-slice with some very conservative values and see what happens.


    Config.sys
    ; Communication and general
    M111 S0 ; Debug off
    M550 PMegaHexDelta ; Machine name and Netbios name (can be anything you like)
    M551 Preprap ; Machine password (used for FTP)
    ;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits
    M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xEA ; MAC Address
    ;*** Wifi Networking
    M552 S1 ; Enable WiFi

    M555 P2 ; Set output to look like Marlin
    M575 P1 B57600 S1 ; Comms parameters for PanelDue

    G21 ; Work in millimetres
    G90 ; Send absolute coordinates...
    M83 ; ...but relative extruder moves

    ; Axis and motor configuration including current
    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
    M569 P4 S1 ; Drive 4 goes forwards
    M574 X2 Y2 Z2 S1 ; set endstop configuration (all endstops at high end, active high)
    M906 X1600 Y1600 Z1600 E1200 I40 ; Set motor currents (mA) and increase idle current to 40%

    ;*** Delta Config and endstops
    M665 R306.92 L675.50 B300 H622 X0.47 Y0.34 Z0 ; set delta radius, diagonal rod length, printable radius, homed height and tower positions
    M666 X-1.23 Y1.82 Z-0.59 ; put your endstop adjustments here, or let auto calibration find them

    ;Microstepping, steps/mm and Accelerations
    M350 X16 Y16 E16 I1 ; Set 16x microstepping with interpolation
    M92 X160 Y160 Z160 ; Set axis steps/mm
    M201 X3000 Y3000 Z3000 E800 ; Accelerations (mm/s^2)
    M203 X20000 Y20000 Z20000 E4000 ; Maximum speeds (mm/min)
    M566 X1200 Y1200 Z1200 E1200 ; Maximum instant speed changes mm/minute

    ; Thermistors
    M305 P0 T100000 B3950 R4700 H22 L0 ; Put your own H and/or L values here to set the bed thermistor ADC correction
    M305 P1 T100000 B3974 R4700 H0 L0 ; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
    M305 P2 T100000 B3974 R4700 H30 L0 ; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
    M301 H1 P22.0 I0.2 D180 T0.2 S1 W180 B30
    M570 S150 ; Hot end may be a little slow to heat up so allow it 150 seconds

    ;CPU temperature calibration
    M912 P0 S-5

    ; Tool definitions
    M563 P0 D0 H1 ; Define tool 0
    G10 P0 S0 R0 X0 Y0 ; Set tool 0 operating and standby temperatures

    M92 E402 ; Set extruder steps per mm, 402 is correct for PLA

    ; Z probe and compensation definition
    M558 P1 X0 Y0 Z0 ; Z probe is an IR probe and is not used for homing any axes
    G31 X0 Y0 Z1.85 P500 ; Set the zprobe height and threshold (put your own values here)

    ;M208 S1 Z-0.2 ; set minimum Z commented out
    ;
    T0 ; select first hot end



  • Maybe I have found a subtle bug or at least weird behaviour….. nothing i've done has solved the "lean" issue so started measuring movement and it has got weirder.

    Setup:
    150gm plumb hanging from one edge of the effector tied off to the ball joint for the arm
    The ruler is set in the X direction with photos taken from front of machine. So +X to the right.

    Photo 1.
    This is with the effector around 300mm from the bed immediately after homing the printer and just doing z moves.

    Photo 2.
    Now I've moved the effector to the +X and +Y extents of 290mm and then brought it back to the indicated 0,0 position as shown on the panelDue.
    as you can see we seem to have shifted 2mm in the +X and maybe 1.5 in the +Y….. This is with no change in Z height.

    Couple things.
    This offset does not seem to be there for a move 100mm and back, even 200mm and back will take a lot of moves to show a drift but a single move to the extent and back shifts it immediately.
    Next: repeated moves to the extents bring the head back to EXACTLY the same spot…. this rules out missed steps, binding, steppers and in my mind most things mechanical.

    After the printer homes I can see the head jump a little sideways to it's calculated 0,0 position and visually it seems to be the amount we then see shift in the photos.



  • Oh the setup with the plumb bob was accurate enough to show up a slight bed levelling issue of .3mm front to back
    🙂


  • administrators

    Phil, are you using absolute or relative movement commands to move the head to the edge of the bed and back? If you are using relative moves then the normal movement limits will have that effect if x290 y290 is slightly outside the printable bed radius. But if you send G1 X0 Y0 then it should return to the centre.



  • This is similar to some issues I reported once on the delta google groups, but way more pronounced. To be quite honest, for me it might be/have been a mechanical issue, and for you I would think the same. Look for a ball joint that has an unwanted range of motion. It might not be obvious, but some/one of your joints might be shifting positions every so often.

    What is your setup like, physically?



  • @dc42:

    Phil, are you using absolute or relative movement commands to move the head to the edge of the bed and back? If you are using relative moves then the normal movement limits will have that effect if x290 y290 is slightly outside the printable bed radius. But if you send G1 X0 Y0 then it should return to the centre.

    Using the PanelDue to do all moves, they are relative.

    290mm is the configured radius (ie 580mm in m665), paneldue and dwc both report it is at 290.

    G1 X0 Y0 left the effector in exactly the same place so the firmware already thinks it's at 0,0

    Now more measurements and findings.

    1. Moves in the -X direction only and back to 0,0 do not exhibit any offset even sending it to x-290 and back to x0

    2. Moves in the positive +X direction of 200mm and back DO have an offest.

    3. Multiple moves do not increase the error so it doesn't accumulate

    4. Repeated 100mm moves accumulate the error.

    5. The first move in the +X direction is within 1mm at 270mm, likely a arm length number.

    6. The move back from +x270 however creates an offset. send G1 X0 Y0 doesn't change anything the real world location is X+1.8 Y+1.5, checked by moving effector back to the real world zero

    In doing the measurements this morning I did find and correct a slight miss-alignment in the rods on the left tower which was showing as a twist/tilt on the effector at the +X limits. Repeated all the measurements again after that and the photo above is after this.

    This really does feel more and more like a subtle bug



  • @bot:

    This is similar to some issues I reported once on the delta google groups, but way more pronounced. To be quite honest, for me it might be/have been a mechanical issue, and for you I would think the same. Look for a ball joint that has an unwanted range of motion. It might not be obvious, but some/one of your joints might be shifting positions every so often.

    What is your setup like, physically?

    Overall photo.
    The overall lean is just the angle i shot the photo, sorry.

    There are no traditional ball joints or magnetic joints. Both ends of the 10mm carbon fibre rods use these printed cups and string/spring retention, this has worked well from day one.

    Whilst i don't discount a pure mechanical issue, the more i measure the more all the mechanics look ok



  • @DC42.

    David just went back and looked really closely at the 30mm hollow cubes i had printed last with 0.85 board and it shows the first couple layers shift the worst then by Z=9mm we start going straight up. Nearly like whatever calc error stops accumulating.



  • Just a few ideas if you haven't already thought of these…

    If you are doing a bed calibration at the beginning and using calibration points out near the extents of the printable area:

    • is there something out near those outer extents that binds up in the slides/carriages/effector (leading to missed steps or even skipping of a belt tooth??)

    • or are one or more of the belts damaged out at the extreme positions (this could lead to some hysteresis of position)

    • or is your suspended extruder cold end/Bowden tube somehow pulling on the effector when you calibrate out at the extremes

    • or is there a "booger" or burr in your ball ends out near the furthest extent of calibration or movement that could cause an error in position (less likely, but had to include it in the list)

    • or is the current supplied by the steppers just not quite enough to pull the carriages out of those extreme positions (missed steps)

    • Last but not least… is the plumb bob heavy enough to cause missed steps or even "sag" of the carriages between movement commands (you had the idle current set to 40%, which might not be enough to hold things in place??)

    So to test out the motor current being the issue…
    Instead of this line in your config.g:

    [[language]]
    M906 X1600 Y1600 Z1600 E1200 I40        ; Set motor currents (mA) and increase idle current to 40%
    
    ```try this instead:
    

    [[language]]
    M906 X2000 Y2000 Z2000 E1200 I60 ; Increase motor currents (mA) and increase idle current to 60%

    
    I know when I was first trying to get my bed calibration parameters dialed in, I had a few hard crashes into the bed with the nozzle. Nothing seems to be damaged, but it sure didn't sound good. I haven't taken things apart to inspect but I'm hoping I didn't damage the belts.
    
    I just can't imagine it being a software bug that is only affecting your setup this way. Granted, you probably have one of the bigger delta machines out there so you are in uncharted territory with this board. My bet is that it's either something mechanical or some settings of parameters in the config.g or somehow bed.g file.


  • Hi Todd,

    Good thoughts but only the motor current is not yet tested.

    The bed.g file used for actual calibration is currently set to a 250mm radius, well inside my reach of over 300mm.

    The carriages move freely and have no apparent binding and i here no strange noises.

    The belts are all literally brand new as part of the rebuild.

    No evidence that the flying setup pulls the effector out of spot.

    The ball ends are all smooth and i've rechecked 🙂

    I haven't got any spring scales handy but the pb is 150gm and it takes a lot more than that to displace the motors even at 40% idle.

    yeah I too don't believe it is truly software but I'm running out of ideas.



  • !!!!! Weirder alert !!!!!

    Started checking the Z movements of the carriages and whilst Z/Y moved 150mm when asked X was only moving 148.6 !!!

    I thought "what's to loose" i'll adjust the steps/mm, calculated the difference and set X to step at 161.52.

    Printed a 40mm hollow cube and whilst the first 9mm of height still has the tiniest bit of offset you really need to be looking for it with the first few layers the most affected at just under a 1mm…. you would maybe normally spot it. I didn't till i went looking.

    Guess i have a faulty stepper, can't think of any other reason for the step/mm being "wrong"

    Note: even with the corrected steps…. the offset happening after positive X movement was still measurable but had dropped closer to 1mm of offset.... visually sorry didn't physically measure.



  • Phil

    This might sound really silly BUT where is the Pb suspended from the effector ie centre or from one edge point?

    If from an edge is it possible that the additional mass supported out there is causing some misalignment (or Effector Tilt) when moving in one direction. (If so it would suggest some play in the system somewhere probably in the opposite side to the suspension mount)

    Can you try the same tests with the Pb suspended from the nozzle point (or as close to the centre as possible).

    Hope this makes a little bit of sense not sure I even know what I am trying to get at?

    Doug


  • administrators

    Phil, please can you explain the apparent contradiction between these two:

    @Aussiephil:

    3. Multiple moves do not increase the error so it doesn't accumulate

    4. Repeated 100mm moves accumulate the error.

    Also, please can you run M114 and report the step counts at (0,0) with the plumb line showing both the original position and the positions after the shift occurs.

    It seems unlikely to me that it is a firmware problem. OTOH you are running a larger delta than anyone else I know of, so I can't discount the possibility of an overflow error somewhere in the delta calcs. Please can you give me your M665 and M666 parameters, also your tower steps/mm, and I will plug them into the simulator.

    Also please check that when the head jumps sideways a little after homing, the 5mm that it has moved down is far enough that the sideways jump does not cause any of the carriages to hit the endstop.


  • administrators

    PS - also, please wind back the acceleration and jerk settings to these values and test again:

    M201 X1000 Y1000 Z1000 E800 ; Accelerations (mm/s^2)
    M566 X600 Y600 Z600 E1200 ; Maximum instant speed changes mm/minute



  • @dc42:

    Phil, please can you explain the apparent contradiction between these two:

    @Aussiephil:

    3. Multiple moves do not increase the error so it doesn't accumulate

    4. Repeated 100mm moves accumulate the error.

    Also, please can you run M114 and report the step counts at (0,0) with the plumb line showing both the original position and the positions after the shift occurs.

    It seems unlikely to me that it is a firmware problem. OTOH you are running a larger delta than anyone else I know of, so I can't discount the possibility of an overflow error somewhere in the delta calcs. Please can you give me your M665 and M666 parameters, also your tower steps/mm, and I will plug them into the simulator.

    Also please check that when the head jumps sideways a little after homing, the 5mm that it has moved down is far enough that the sideways jump does not cause any of the carriages to hit the endstop.

    Just checking back in, had to not go near it yesterday….

    David,
    Explanation is that the first 200mm +X move seems to return to 0,0 with an offset of say 1mm but 10 repeated moves did not show any further observable changes.
    However a single 100mm +X move didn't show any initial measureable/observable offset however repeated 10-20 moves started to show an observable offset occurring.

    As i have a mile of height i drop the head 10mm after homing so the reset to 0,0 doesn't cause an endstop to be triggered, but i'll triple check.

    M665,666 listed a few posts back but your next post shows you seen them, i'll drop the numbers later today and retest.

    Still concerned now about the stepper on the X tower needing a different steps/mm for correct travel.

    Cheers and thanks for the continuing help.

    Phil



  • @Aussiephil:

    Still concerned now about the stepper on the X tower needing a different steps/mm for correct travel.

    Cheers and thanks for the continuing help.

    Phil

    Phil

    What are you Step/mm for each stepper it is not normal for them to be different and would suggest you have a oddball toothed pulley in there.

    Looking at the Config.g you posted a while back they were all set to 160 which implies 20 tooth pulleys?

    on my first printer (an I3) I was getting very strange distances until I counted the number of teeth on the pulleys? the steps/mm was set for 16 tooth pulleys but I had been supplied with 17's so there are odballs out there and is worth checking and this may well be the cause of your issues.

    Sure David will pipe in soon

    Doug


  • administrators

    I agree, if you need different steps/mm for the motors then something is wrong. How did you arrive at your steps/mm values?


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.