Large Kossel all metal delta build log
Posted by DjDemonD
|
Re: Large Kossel all metal delta build log September 16, 2016 07:47PM |
So got the duetwifi card and paneldue controller.
Nicely made card, everything well thought out. They did miss my order but once I contacted them they couldn't apologise enough and sent one out special delivery.
Decided I'd need a back support for it, so I downloaded DC42's version from Thingiverse. I cut away the fan support as I would not quite have enough room in my electronics compartment (and I have two substantial fans).
I did run into one immediate problem once I installed the duetwifi, attached a usb cable and powered it up. It showed as the wrong device in windows, it showed as "bossa port" which means it had been erased. The duet wiki explained what to do, its a bit like flashing the firmware on an 8 bit arduino. I did this but still no joy. It was then I realised the front panel I had remixed from DC42's version was pressing the erase and reset buttons as I inserted the usb cable. So I cut away a bunch of this panel, which actually makes the LED's easier to see and the USB port easier to access and protects the erase/reset buttons from accidentally being pushed. I will modify the front panel when I upload all the custom made parts to thingiverse.
A great many hours spent wiring it all up. Wired the two 12v electronics fans in series so they work on 24v. Did the same with the two print cooling fans. The hotend fan runs off a small adjustable step down module (which is seen wrapped in some plastic just to protect it as its a bit more delicate than most of the electronics). The hot end heater runs via a 24-12v converter. This is wired as follows. On the converter the 24v input is attached to the E0 heater positive on the duetwifi. The ground wire is attached to the main power negative (so essentially the PSU negative) on the duet, then from the converter 12v output to the hot end heater, and back to the duetwifi E0 negative terminal. This means the converter is only powered when the hot end is on, and since the duet wifi applies the PWM to the ground from the hot end heater, I am not sending a PWM signal to the converter input. It works, the thermistor needs some calibration/auto tune.
The bed heats up (no mains voltage nasty surprises). Again thermistor needs tweaking.
The almost complete machine. The panel due lights up but isn't yet receiving any data, so I've not set something right here, not too worried as the web interface is really good.
Here is a video of some delta autocalibration.
The values after 3 or 4 runs converge nicely so I presume nothing is mechanically amiss. Watch at the end when it brings the head back up at 15000 mm/min travel speed I've never seen a 3d printer move that fast, so very pleased. Apologies for the background noise, my partner was packing stuff. The one slightly sticky hiwin rail seems to be causing no problems so far, and the TMC 2600 stepper drivers interpolating 1/256 microstepping mean you can barely hear the motors at normal speeds.
I need to make a spool holder and then I can see how it prints.
I was reluctant to join the 32 bit revolution but I have to say its a world apart from the old ATmega.
Edited 1 time(s). Last edit at 09/16/2016 07:50PM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Nicely made card, everything well thought out. They did miss my order but once I contacted them they couldn't apologise enough and sent one out special delivery.
Decided I'd need a back support for it, so I downloaded DC42's version from Thingiverse. I cut away the fan support as I would not quite have enough room in my electronics compartment (and I have two substantial fans).
I did run into one immediate problem once I installed the duetwifi, attached a usb cable and powered it up. It showed as the wrong device in windows, it showed as "bossa port" which means it had been erased. The duet wiki explained what to do, its a bit like flashing the firmware on an 8 bit arduino. I did this but still no joy. It was then I realised the front panel I had remixed from DC42's version was pressing the erase and reset buttons as I inserted the usb cable. So I cut away a bunch of this panel, which actually makes the LED's easier to see and the USB port easier to access and protects the erase/reset buttons from accidentally being pushed. I will modify the front panel when I upload all the custom made parts to thingiverse.
A great many hours spent wiring it all up. Wired the two 12v electronics fans in series so they work on 24v. Did the same with the two print cooling fans. The hotend fan runs off a small adjustable step down module (which is seen wrapped in some plastic just to protect it as its a bit more delicate than most of the electronics). The hot end heater runs via a 24-12v converter. This is wired as follows. On the converter the 24v input is attached to the E0 heater positive on the duetwifi. The ground wire is attached to the main power negative (so essentially the PSU negative) on the duet, then from the converter 12v output to the hot end heater, and back to the duetwifi E0 negative terminal. This means the converter is only powered when the hot end is on, and since the duet wifi applies the PWM to the ground from the hot end heater, I am not sending a PWM signal to the converter input. It works, the thermistor needs some calibration/auto tune.
The bed heats up (no mains voltage nasty surprises). Again thermistor needs tweaking.
The almost complete machine. The panel due lights up but isn't yet receiving any data, so I've not set something right here, not too worried as the web interface is really good.
Here is a video of some delta autocalibration.
The values after 3 or 4 runs converge nicely so I presume nothing is mechanically amiss. Watch at the end when it brings the head back up at 15000 mm/min travel speed I've never seen a 3d printer move that fast, so very pleased. Apologies for the background noise, my partner was packing stuff. The one slightly sticky hiwin rail seems to be causing no problems so far, and the TMC 2600 stepper drivers interpolating 1/256 microstepping mean you can barely hear the motors at normal speeds.
I need to make a spool holder and then I can see how it prints.
I was reluctant to join the 32 bit revolution but I have to say its a world apart from the old ATmega.
Edited 1 time(s). Last edit at 09/16/2016 07:50PM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
|
Re: Large Kossel all metal delta build log September 18, 2016 07:04AM |
This is the 3rd object it has printed. So well pleased.
Next to see how fast it can print this object without losing quality.
A couple of observations:
The 120w laptop supply seems quite up to the job as the bed is not powered by it.
The electronics compartment is not too hot in use, (35 deg c) but between the bed and the electronics I placed a thick double ply cardboard top (the metal panel I intended to use didn't really fit) and lined the underside of it with foil bubble wrap. You have to cut away a section under the bed heater where the wiring is connected.
The 12v step down converter does not get hot, neither does the ssr. They are both running well below their rated capacity. (3A on 12v converter, 5A rated; 2A on the ssr, 25A rated).
Will add some LEDs, probably use 2 x 12v strips in series. I find these strip LEDs get hot so mounting them on the frame helps dissipate this heat. Also I tend to put them on the front two towers facing inwards so they aren't shining in my face.
Edited 3 time(s). Last edit at 09/18/2016 11:27AM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
|
Re: Large Kossel all metal delta build log September 20, 2016 07:02PM |
Okay so plenty to write about. The tuning and tweaking continues.
The babystepping trick now works using G92 Z0.425 (down) or G92 Z0.375 (up), (assuming a 0.4mm first layer with no slicer offset). This can be sent using a macro from the paneldue controller or via the gcode console. Count the number of times the correction is sent until you have a good first layer and then you can enter that as a M206 offset in the config.g for next time. It only works for the first layer as its absolute not relative.
The bed level was wrong as the bed.g file was incorrect.
My probing points assumed the nozzle is at the coordinates to be probed, whereas what matters are the coordinates that position the probe at each necessary point, since the firmware is not doing auto bed levelling it is unimportant if the probe has an offset from the nozzle. What's important is that the probe measures the bases of the towers, the mid points between them and some other points closer towards the centre, then the centre itself (the probe over the centre). Assuming no effector tilt, and I haven't seen any evidence of it so far it can then calculate all the 7 factors properly and the deviations reported back get lower and lower, currently at 0.052 from around 0.3 when I started.
My bed.g looks like this (assuming an IR probe and a bed diameter of 330mm)
I have added G32 to my start gcode to do this auto-calibration before each print.
I also wrote a second short bed file to check the bed level at the base of each of the three towers and output the heights, so long as these are all reasonably small differences from the expected height objects should print evenly across the bed.
This presumes the printer is homed. I added this after G32 in the start gcode (use M98 Pbedcheck.g - where the file is called bedcheck.g) for a quick bed level confirmation before each print. It does this whilst pre-heating the extruder, so there is time to abort the print if these values are way off.
Now printing a name plate to put on the front of the machine at the top, in front of where I have placed an LED strip (two equal sets of 12v LEDs are connected in series to give 24v) which is connected to the P1 fan output, and therefore can be dimmed or turned on or off using gcode from the console, or even flashed at the end of a print etc... Childish but why not.
Edited 4 time(s). Last edit at 09/21/2016 02:35PM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
The babystepping trick now works using G92 Z0.425 (down) or G92 Z0.375 (up), (assuming a 0.4mm first layer with no slicer offset). This can be sent using a macro from the paneldue controller or via the gcode console. Count the number of times the correction is sent until you have a good first layer and then you can enter that as a M206 offset in the config.g for next time. It only works for the first layer as its absolute not relative.
The bed level was wrong as the bed.g file was incorrect.
My probing points assumed the nozzle is at the coordinates to be probed, whereas what matters are the coordinates that position the probe at each necessary point, since the firmware is not doing auto bed levelling it is unimportant if the probe has an offset from the nozzle. What's important is that the probe measures the bases of the towers, the mid points between them and some other points closer towards the centre, then the centre itself (the probe over the centre). Assuming no effector tilt, and I haven't seen any evidence of it so far it can then calculate all the 7 factors properly and the deviations reported back get lower and lower, currently at 0.052 from around 0.3 when I started.
My bed.g looks like this (assuming an IR probe and a bed diameter of 330mm)
; Auto calibration routine for delta printers M561 ; clear any bed transform, otherwise homing may be at the wrong height G31 X0 Y0 ; don't want any probe offset for this G28 ; home the printer G28 ;home again in case of endstop problem ; Probe the bed and do 6- or 7-factor auto calibration positions are probe positions (x-13,y34) G30 P0 X-87 Y-86 Z-99999 ; X tower G30 P1 X13 Y-140 Z-99999 ; XY point G30 P2 X104 Y-90 Z-99999 ; Y tower G30 P3 X130 Y16 Z-99999 ; YZ point G30 P4 X13 Y100 Z-99999 ; Z tower G30 P5 X-100 Y40 Z-99999 ; YZ point G30 P6 X-50 Y-60 Z-99999 ; X tower middle G30 P7 X0 Y-100 Z-99999 ; between X and Y towers middle G30 P8 X80 Y-70 Z-99999 ; Y tower middle G30 P9 X80 Y-10 Z-99999 ; between Y and Z towers middle G30 P10 X13 Y60 Z-99999 ; Z tower middle G30 P11 X-57 Y054 Z-99999 ; between Z and X towers middle G30 P12 X-27 Y-64 Z-99999 ; X tower inner G30 P13 X53 Y-64 Z-99999 ; Y tower inner G30 P14 X13 Y6 Z-99999 ; Z tower inner G30 P15 X13 Y-34 Z-99999 S7 ; centre, and auto-calibrate 7 factors G1 X0 Y0 Z150 F10000 ; get the head out of the way of the bed
I have added G32 to my start gcode to do this auto-calibration before each print.
I also wrote a second short bed file to check the bed level at the base of each of the three towers and output the heights, so long as these are all reasonably small differences from the expected height objects should print evenly across the bed.
;bed level check G30 P0 X-100 Y-60 Z-99999 ; X tower G30 P1 X100 Y-60 Z-99999 ; Y tower G30 P2 X0 Y100 Z-99999 S-1 ; Z tower G1 X0 Y0 Z100 F10000
This presumes the printer is homed. I added this after G32 in the start gcode (use M98 Pbedcheck.g - where the file is called bedcheck.g) for a quick bed level confirmation before each print. It does this whilst pre-heating the extruder, so there is time to abort the print if these values are way off.
Now printing a name plate to put on the front of the machine at the top, in front of where I have placed an LED strip (two equal sets of 12v LEDs are connected in series to give 24v) which is connected to the P1 fan output, and therefore can be dimmed or turned on or off using gcode from the console, or even flashed at the end of a print etc... Childish but why not.
Edited 4 time(s). Last edit at 09/21/2016 02:35PM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
|
Re: Large Kossel all metal delta build log September 21, 2016 02:50PM |
Cool yeah my Kossel Mini flying extruder which is on thingiverse was a much more arbitrary design. When I sat down to make one for this printer I realised I was looking at a model of the printer on the screen, so why not have a little fun.
Love to see yours and hear more about it.
Couple of prints that I did earlier attempting to replicate this very impressive 3D printed fly fishing reel, I like a challenge.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Love to see yours and hear more about it.
Couple of prints that I did earlier attempting to replicate this very impressive 3D printed fly fishing reel, I like a challenge.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
|
Re: Large Kossel all metal delta build log September 26, 2016 06:38PM |
Okay so I got 25 very strong neodymium magnets 12mm diameter 2mm thick. So strong when stacked together I pulled one off the pile and it snapped back into the rest and shattered. Luckily I needed 24.
I've added two each of these to the existing magnets at the effector and carriages, to strengthen them without having to replace the magnets and it does help. However the balls were still becoming detached. I reduced accelerations to 800. But this didn't help, it was then I noticed that it was when the effector came to a stop the balls came away from the magnets. So I looked at the jerk values which were 1000, so I presume this means the firmware is not decelerating as the speed is below the jerk value so it's coming to an abrupt halt. So I reduced these to 300mm/min (5mm/s) and the balls now remain attached - mostly. What effect this has on printing I don't know, but its at the extreme ranges that it happens, so maybe I can just add some gcode to my bed.g file to slow the machine right down for calibration then speed it back up to print which will be mainly in the middle of the bed where the arm's angle to the effector is less obtuse, this is when the balls mainly come away from the magnets.
To help further I tested having a longer bowden tube to the flying extruder and therefore having less elastic force pulling the effector towards the carriages, this seemed to make it worse, now I have a shorter bowden tube and it seems to be better.
I have made a new fan shroud V6MSX-shroudwithIRsensormount_fixed.stl & V6MSX-fanduct.stl which mounts the IR sensor very close to the nozzle to minimise effector tilt affecting the sensor trigger height from one position in xy to another. I wrapped the sensor in kapton, and the heater block has a silicone cover so the sensor should stay cool enough in use (yet to be seen).
Autocalibration now results in a deviation of 0.040mm the lowest I've seen it report. However bed level still seems off, and its inconsistent, some readings of bed level over repeated runs yield differences in bed height up to 0.1mm from one run to the next, so I am now thinking the aluminium surface is too reflective, even though the sensor analogue reading is not 1000+ as DC42 suggested it might be if the sensor was saturating. I am waiting on printbite, which is much more evenly IR reflective. So for now at a standstill again.
Edited 2 time(s). Last edit at 09/27/2016 07:08AM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
I've added two each of these to the existing magnets at the effector and carriages, to strengthen them without having to replace the magnets and it does help. However the balls were still becoming detached. I reduced accelerations to 800. But this didn't help, it was then I noticed that it was when the effector came to a stop the balls came away from the magnets. So I looked at the jerk values which were 1000, so I presume this means the firmware is not decelerating as the speed is below the jerk value so it's coming to an abrupt halt. So I reduced these to 300mm/min (5mm/s) and the balls now remain attached - mostly. What effect this has on printing I don't know, but its at the extreme ranges that it happens, so maybe I can just add some gcode to my bed.g file to slow the machine right down for calibration then speed it back up to print which will be mainly in the middle of the bed where the arm's angle to the effector is less obtuse, this is when the balls mainly come away from the magnets.
To help further I tested having a longer bowden tube to the flying extruder and therefore having less elastic force pulling the effector towards the carriages, this seemed to make it worse, now I have a shorter bowden tube and it seems to be better.
I have made a new fan shroud V6MSX-shroudwithIRsensormount_fixed.stl & V6MSX-fanduct.stl which mounts the IR sensor very close to the nozzle to minimise effector tilt affecting the sensor trigger height from one position in xy to another. I wrapped the sensor in kapton, and the heater block has a silicone cover so the sensor should stay cool enough in use (yet to be seen).
Autocalibration now results in a deviation of 0.040mm the lowest I've seen it report. However bed level still seems off, and its inconsistent, some readings of bed level over repeated runs yield differences in bed height up to 0.1mm from one run to the next, so I am now thinking the aluminium surface is too reflective, even though the sensor analogue reading is not 1000+ as DC42 suggested it might be if the sensor was saturating. I am waiting on printbite, which is much more evenly IR reflective. So for now at a standstill again.
Edited 2 time(s). Last edit at 09/27/2016 07:08AM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
|
Re: Large Kossel all metal delta build log September 27, 2016 10:36AM |
One other issue with this magnet system that might be coming into play here, does this seem logical?
The balls are not magnets, at least until they are attached to the magnets in the carriages, then they will become magnetised.
Since the machine sits at rest with the arms at around 60 degrees to the effector, the balls develop a north and south pole over time. This might be less of an issue if the machine were in continuous use, but it isnt. So when the arms are at a very obtuse angle to the effector the poles are not aligned, there is still attraction to the balls, as they are only weak magnets compared to the magnets themselves, but the attraction is weaker than at the acute angle.
Is this plausible? It seems to chime with the fact that the holding force at obtuse angles seems less now, than it did when I first brought magnet and ball into contact. Maybe the effector needs to rest unattached to the magnets when not in use.
Edited 1 time(s). Last edit at 09/27/2016 10:36AM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
The balls are not magnets, at least until they are attached to the magnets in the carriages, then they will become magnetised.
Since the machine sits at rest with the arms at around 60 degrees to the effector, the balls develop a north and south pole over time. This might be less of an issue if the machine were in continuous use, but it isnt. So when the arms are at a very obtuse angle to the effector the poles are not aligned, there is still attraction to the balls, as they are only weak magnets compared to the magnets themselves, but the attraction is weaker than at the acute angle.
Is this plausible? It seems to chime with the fact that the holding force at obtuse angles seems less now, than it did when I first brought magnet and ball into contact. Maybe the effector needs to rest unattached to the magnets when not in use.
Edited 1 time(s). Last edit at 09/27/2016 10:36AM by DjDemonD.
Simon Khoury
Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Sorry, only registered users may post in this forum.