A big thanks to Ron Gerrits who has taken my original bed-leveling application and expanded on it. He's modified the Marlin Gen6 firmware to respond to the M117 code used during the bed leveling process. He's also made the process faster and automatically scaled the resulting plot.
The whole Marlin pack can be downloaded from here and selecting the Marlin.rar download.
Saturday, October 29, 2011
Wednesday, October 5, 2011
Skin Plug-in is Released
I've been busy with work and home renovations for the last few months, so I haven't had much time to play with my printer lately. However, I'm pleased to see that the Skin plug-in for Skeinforge has now been released.
I hope people have fun playing with it.
I hope people have fun playing with it.
Wednesday, June 8, 2011
Bed Mapper Application and STL Files
I've finally got round to publishing the Bed Calibration Application that I discussed in this post.
The calibration application is now available, along with the STL for the bracket here.
This series of scripts requires the Python libraries: PySerial, Matplotlib and NumPy
Note: This script banks on the Mendel firmware supporting the M117 GCode. Without it, it won't work!
RepRapComms.py: Comms library for communicating with a Mendel.
ZCal.py: Main calibration routines.
PlotBed.py: Bed plotting routines.
gui.py: A GUI to make calibration easier.
To use the GUI:
The calibration application is now available, along with the STL for the bracket here.
This series of scripts requires the Python libraries: PySerial, Matplotlib and NumPy
Note: This script banks on the Mendel firmware supporting the M117 GCode. Without it, it won't work!
RepRapComms.py: Comms library for communicating with a Mendel.
ZCal.py: Main calibration routines.
PlotBed.py: Bed plotting routines.
gui.py: A GUI to make calibration easier.
To use the GUI:
- Use the Printer Menu tab to configure the various settings to match your printer.
- Calibrate Button, will perform a series of measurements across the whole bed at the specified X & Y step size.
- Quick Cal Button, will perform a quick test at four specified points across the bed.
- Variance Button, will perform a repeated measurement at a specified point to see what the variance is for the microswitch.
Wednesday, May 18, 2011
More Skinning Tests
I ran some more skinning tests this evening, its definitely got promise. This picture shows a 0.4mm carved cube skinned at 0.2mm in the middle. On the right is 0.25mm carved cube and on the left a 0.4mm carved cube for comparison. The outer shell feels very smooth to the touch. It would be good to transfer this to all top surfaces too. It would look better and may make closing PLA structures easier, mine always seem to have problems closing fully.
Tomorrow I think I'll try some of the more tricky prints, like the drive gear from the extruder.
 |
| L: 0.4mm carve : M: 0.4mm carve w/ 0.2mm skin : R: 0.25mm carve |
Tomorrow I think I'll try some of the more tricky prints, like the drive gear from the extruder.
Monday, May 16, 2011
Skinning
The best looking prints always have the thinnest layers, however, they take forever to print. It would be really good to have a print that has thin layers on the outside, but the inside is printed with much thicker traces. Now that Skeinforge can easily change layer thickness without lots of tweaking, it should be possible to do this on the fly during a print, rather than just selecting it during the carving process.
This is a concept I'm going to refer to as 'Skinning'. Printing the outer layers at a very thin height, while printing the inner layers at a thicker height. For example, one could print an object where the perimeter is printed with 0.25mm layers, but the inside is printed with 0.5mm layers.
This would require printing at least two perimeter layers (probably first) for every inner layer, but that shouldn't be a problem.
I've been developing some simple test scripts that take the GCode for a simple sliced object and 'skin' it with an external layer half the carve height. The script is rather basic, but the initial results look very promising.
The 0.25mm default cube took 21m 30s to print, a 0.5mm default cube took 10m 0s to print, where as the hybrid 'skinned' cube took 16m 0s to print. The quality is not quite as good as the Skeinforge carved 0.25mm cube (the translucent PLA makes it hard to see), but my script just scaled the extrusion parameters from the 0.5mm carved cube as a quick and dirty test, it also doesn't take into account that the new perimeter paths are slightly longer (or shorter for the internal ones) than the 0.5mm carve.
Now that I know the concept works I'll work on refining the script to correctly adjust the extrusion rate for the skin height.
It's something that I'd like to turn into a Skeinforge plug-in and make part of the tool chain, it would probably much easier to handle the data within Skeinforge than trying to post-process it.
Eventually every print will look like it was printed with the finest nozzle, but take significantly less time!
This is a concept I'm going to refer to as 'Skinning'. Printing the outer layers at a very thin height, while printing the inner layers at a thicker height. For example, one could print an object where the perimeter is printed with 0.25mm layers, but the inside is printed with 0.5mm layers.
 |
| Cross-section of a 'Skinned' print - note fine threads on front and thicker threads inside. |
This would require printing at least two perimeter layers (probably first) for every inner layer, but that shouldn't be a problem.
I've been developing some simple test scripts that take the GCode for a simple sliced object and 'skin' it with an external layer half the carve height. The script is rather basic, but the initial results look very promising.
 |
| Left: 'Skinned' Cube 0.25mm external 0.5mm internal - Right: 0.25mm external & internal. |
The 0.25mm default cube took 21m 30s to print, a 0.5mm default cube took 10m 0s to print, where as the hybrid 'skinned' cube took 16m 0s to print. The quality is not quite as good as the Skeinforge carved 0.25mm cube (the translucent PLA makes it hard to see), but my script just scaled the extrusion parameters from the 0.5mm carved cube as a quick and dirty test, it also doesn't take into account that the new perimeter paths are slightly longer (or shorter for the internal ones) than the 0.5mm carve.
Now that I know the concept works I'll work on refining the script to correctly adjust the extrusion rate for the skin height.
It's something that I'd like to turn into a Skeinforge plug-in and make part of the tool chain, it would probably much easier to handle the data within Skeinforge than trying to post-process it.
Eventually every print will look like it was printed with the finest nozzle, but take significantly less time!
Saturday, May 7, 2011
Adding M117 Support to Gen6 Firmware
This article details how I added support for the M117 GCode that I used for the Auto Bed Leveling approach. The standard Gen6 firmware doesn't support this GCode.
This is more for my own recollection in case I need to add it to future builds.
process_g_code.pde: Line 680 (in the switch statement after case 116)
Handle the M117 GCode and return the data in the appropriate format.
case 117:
Serial.print("C: X");
Serial.print(zeroHit.x);
Serial.print(" Y");
Serial.print(zeroHit.y);
Serial.print(" Z");
Serial.print(zeroHit.z);
Serial.print(" E");
Serial.println(zeroHit.e);
break;
This is more for my own recollection in case I need to add it to future builds.
process_g_code.pde: Line 680 (in the switch statement after case 116)
Handle the M117 GCode and return the data in the appropriate format.
case 117:
Serial.print("C: X");
Serial.print(zeroHit.x);
Serial.print(" Y");
Serial.print(zeroHit.y);
Serial.print(" Z");
Serial.print(zeroHit.z);
Serial.print(" E");
Serial.println(zeroHit.e);
break;
cartesian_dda.pde: Line 391 (in the if (read_switch(min_pin, inv) ) statement)
When an end-stop is hit, store the current step count.
if (min_pin == X_MIN_PIN)
zeroHit.x = current;
if (min_pin == Y_MIN_PIN)
zeroHit.y = current;
if (min_pin == Z_MIN_PIN)
zeroHit.z = current;
configuration.h: Line 329 (just before #endif)
Increase the variables scope.
extern LongPoint zeroHit;
FiveD-GCode_Interpreter.pde: Line 121 (after FloatPoint where_i_am;)
Variable declaration.
LongPoint zeroHit;
That's all there is to it, a quick recompile and upload later and the Gen6 hardware should now support M117.
Thursday, April 28, 2011
A More Advanced Way to Level the Bed
Ever since I first built my Mendel I've felt there has to be a more advanced way to level the bed than rolling a bit of dowel under the extruder nozzle. The Mendel is a very advanced CNC machine, but relies on a bit of wood to level the bed. Leveling the bed is important because even a deviation of 0.1mm can make the difference between the first layer sticking or not. A spirit-level is not accurate enough and measures the plane between the bed and the bench, not the plane between the extruder and the bed.
I wanted to find a way to use the Mendel itself to calibrate the level between the bed and the extruder. After thinking through various different approaches over the last few months, I settled on the following solution.
It would be based on a micro-switch that could be suspended beneath the extruder. The micro-switch would be connected in place of the normal Z-axis end-stop. The micro-switch would then be used to 'probe' the bed at various spots, each time the end-stop registered it should be possible to determine how many steps ahead or behind of where the end-stop was expected to be the extruder head had moved. The GCode M117 is already specified to provide this kind of information, mainly for determining if an axis is skipping steps, but it works here too.
The Micro-Switch Holder
I needed a way to hold the micro-switch that wouldn't require the extruder to be removed. I also wanted an approach that would allow the micro-switch to be added and removed easily. The easiest way to achieve this was to use magnets to attach the holder to the nuts on the bottom of the X-carriage. I designed a bracket that could be easily printed. The bracket was U-shaped, so that the magnets could contact the nuts but it would clear the extruder head. There was a foot on the bottom of the bracket to hold the micro-switch, which was offset so the switch lever was under the extruder nozzle.
Developing the Test Code
I had to create a simple application that controlled the Mendel to perform the calibration and collate and graph the results. I wrote it in my favorite language, Python. The program essentially takes a reference reading on the bed, then probes the bed at a number of points across its surface, recording the number of steps above or below the expected stop point. Since the Z-axis is screw-drive, it has incredibly high accuracy. My Mendel requires about 2700 steps per mm in the Z-axis. There does appear to be some variation in the micro-switch activation. Making repeated measurements in the same spot shows that it doesn't always return to zero, but the variation is relatively small, +/- 12 steps. Compared to a layer of blue-tape at ~230 steps, I'll live with the variance.
The firmware that is running on my Gen6 Mendel does not actually support the M117 command, so I had to port the appropriate code across from the current firmware into my version. The changes were relatively straightforward, but due to some interim changes in the firmware builds, not just a cut-and-paste job.
The First Test Results
The first set of results for my bed, which I considered to be relatively level, where quite surprising to say the least. The plot showed that the bed was bowed, clearly being pulled down in the corners by the screws and forcing the middle up. The total variation across the bed was 0.18mm, which explains why I was having some first layer adhesion problems on large prints. I could clearly do better.
Tuning the Bed
My first task was to remove the bed and look at it more closely. Holding a straight edge across it clearly showed that there was some initial level-ness issues. The aluminium bed is too thick to bend by hand, and the deviations were rather small (0.1mm), so I decided to grind the bed flat.
Using some 220-grit sandpaper taped to a sheet of 1/2" plywood, I ground down the bed until the visible gaps under the straight-edge were gone. I then reattached the bed very loosely and repeated the auto-calibration. It clearly wasn't level.
Using a spirit level was a bad idea, it measured the level-ness of the bench!
Using the old-dowel method was pretty good, but still not perfect.
Tweaking the bed screws and repeating the calibration it was clear that the force of the bed springs was distorting the bed. To get one side level, it skewed the opposite corner.
To try to correct this I decided to switch out the printed springs with wire springs. The same problem occurred. The upward force of the springs caused problems when leveling the bed.
In the end I opted to do away with the springs completely and use bolts fixed to the bed as pillars, resting on nuts on the Y-carriage for easy adjustment. It was much easier to adjust the bed to be completely level with this approach. I think I'll change the regular nuts out to locking nuts though, it will prevent them moving through vibration.
The downside with this approach is there is no give in the bed if the extruder plows into it. To overcome this, I think I'm going to put some small compression springs on top of the extruder connection screws. This should allow the extruder to move up slightly if anything goes wrong.
Level At Last
After six-days of tweaks and experiments, the bed is finally level and I'm happy. It is now level to within 0.08mm. I'm ignoring the last set of measurements at the back of the bed. They were made at the very back edge of the bed where I can't print anyway and no amount of screw adjustment can fix it.
Next Steps
Now I have a calibration method that allows me to either perform very detailed mapping of the bed flatness without removing the extruder or breaking out the dowel. If I do have to make adjustments, I won't spend ages adjusting bolts to find that they have changed something on the other side of the bed.
I also have the ability to perform very quick verifications of bed flatness. A four point test at the four screw locations takes under 2-minutes and is very good indicator of how flat the bed is now. I can also save the resulting graphs for future reference to see if things have changed over time.
Also, because I now know the deviation of the bed in millimeters, it takes the guess work out of how much to adjust the bed by. Each revolution of a M4 screw moves the nut by 0.7mm. Since the nuts are 6-sided, by moving the nut by one face I can get 0.116mm of adjustment very easily.
This work has some other potential uses that I am going to investigate. It could be possible to take the surface map of the bed and use it to dynamically adjust the first layer of GCode to overcome any minor surface variation by changing the Z-height while printing. I might try developing a Skeinforge plug-in that does this. Another use might be to use it to make point-clouds of objects placed on the bed - allowing me to create crude 3-D scans. I think that I'll need something more pointy than a micro-switch lever for the probing, but the calibration utility I have written will definitely work.
I'm just tidying up the calibration application and will post it shortly, along with the bracket STL file, if anyone is interested. I should also document the changes I made to the Gen6 FW to add the M117 command, because I'm sure I'll forget before the next release comes out!
8-Jun-11 - Update:
The calibration application is now available, along with the STL for the bracket here.
This series of scripts requires the Python libraries: PySerial, Matplotlib and NumPy
Note: This script banks on the Mendel firmware supporting the M117 GCode. Without it, it won't work!
RepRapComms.py: Comms library for communicating with a Mendel.
ZCal.py: Main calibration routines.
PlotBed.py: Bed plotting routines.
gui.py: A GUI to make calibration easier.
To use the GUI:
I wanted to find a way to use the Mendel itself to calibrate the level between the bed and the extruder. After thinking through various different approaches over the last few months, I settled on the following solution.
It would be based on a micro-switch that could be suspended beneath the extruder. The micro-switch would be connected in place of the normal Z-axis end-stop. The micro-switch would then be used to 'probe' the bed at various spots, each time the end-stop registered it should be possible to determine how many steps ahead or behind of where the end-stop was expected to be the extruder head had moved. The GCode M117 is already specified to provide this kind of information, mainly for determining if an axis is skipping steps, but it works here too.
The Micro-Switch Holder
 |
| Micro-Switch Bracket |
Developing the Test Code
I had to create a simple application that controlled the Mendel to perform the calibration and collate and graph the results. I wrote it in my favorite language, Python. The program essentially takes a reference reading on the bed, then probes the bed at a number of points across its surface, recording the number of steps above or below the expected stop point. Since the Z-axis is screw-drive, it has incredibly high accuracy. My Mendel requires about 2700 steps per mm in the Z-axis. There does appear to be some variation in the micro-switch activation. Making repeated measurements in the same spot shows that it doesn't always return to zero, but the variation is relatively small, +/- 12 steps. Compared to a layer of blue-tape at ~230 steps, I'll live with the variance.
The firmware that is running on my Gen6 Mendel does not actually support the M117 command, so I had to port the appropriate code across from the current firmware into my version. The changes were relatively straightforward, but due to some interim changes in the firmware builds, not just a cut-and-paste job.
The First Test Results
The first set of results for my bed, which I considered to be relatively level, where quite surprising to say the least. The plot showed that the bed was bowed, clearly being pulled down in the corners by the screws and forcing the middle up. The total variation across the bed was 0.18mm, which explains why I was having some first layer adhesion problems on large prints. I could clearly do better.
 |
| Bowed Bed |
My first task was to remove the bed and look at it more closely. Holding a straight edge across it clearly showed that there was some initial level-ness issues. The aluminium bed is too thick to bend by hand, and the deviations were rather small (0.1mm), so I decided to grind the bed flat.
Using some 220-grit sandpaper taped to a sheet of 1/2" plywood, I ground down the bed until the visible gaps under the straight-edge were gone. I then reattached the bed very loosely and repeated the auto-calibration. It clearly wasn't level.
 |
| Unfortunately, not level straight out of the gate. |
Using a spirit level was a bad idea, it measured the level-ness of the bench!
 |
| The bubble was between the lines! |
 |
| The trusty old dowel wasn't actually that bad. |
Tweaking the bed screws and repeating the calibration it was clear that the force of the bed springs was distorting the bed. To get one side level, it skewed the opposite corner.
 |
| Adjusting one corner pulled the others out of whack. |
To try to correct this I decided to switch out the printed springs with wire springs. The same problem occurred. The upward force of the springs caused problems when leveling the bed.
 |
| No springs, just screw pillars |
The downside with this approach is there is no give in the bed if the extruder plows into it. To overcome this, I think I'm going to put some small compression springs on top of the extruder connection screws. This should allow the extruder to move up slightly if anything goes wrong.
Level At Last
After six-days of tweaks and experiments, the bed is finally level and I'm happy. It is now level to within 0.08mm. I'm ignoring the last set of measurements at the back of the bed. They were made at the very back edge of the bed where I can't print anyway and no amount of screw adjustment can fix it.
 |
| Looks bad, but look at the scale! |
Now I have a calibration method that allows me to either perform very detailed mapping of the bed flatness without removing the extruder or breaking out the dowel. If I do have to make adjustments, I won't spend ages adjusting bolts to find that they have changed something on the other side of the bed.
I also have the ability to perform very quick verifications of bed flatness. A four point test at the four screw locations takes under 2-minutes and is very good indicator of how flat the bed is now. I can also save the resulting graphs for future reference to see if things have changed over time.
Also, because I now know the deviation of the bed in millimeters, it takes the guess work out of how much to adjust the bed by. Each revolution of a M4 screw moves the nut by 0.7mm. Since the nuts are 6-sided, by moving the nut by one face I can get 0.116mm of adjustment very easily.
This work has some other potential uses that I am going to investigate. It could be possible to take the surface map of the bed and use it to dynamically adjust the first layer of GCode to overcome any minor surface variation by changing the Z-height while printing. I might try developing a Skeinforge plug-in that does this. Another use might be to use it to make point-clouds of objects placed on the bed - allowing me to create crude 3-D scans. I think that I'll need something more pointy than a micro-switch lever for the probing, but the calibration utility I have written will definitely work.
I'm just tidying up the calibration application and will post it shortly, along with the bracket STL file, if anyone is interested. I should also document the changes I made to the Gen6 FW to add the M117 command, because I'm sure I'll forget before the next release comes out!
8-Jun-11 - Update:
The calibration application is now available, along with the STL for the bracket here.
This series of scripts requires the Python libraries: PySerial, Matplotlib and NumPy
Note: This script banks on the Mendel firmware supporting the M117 GCode. Without it, it won't work!
RepRapComms.py: Comms library for communicating with a Mendel.
ZCal.py: Main calibration routines.
PlotBed.py: Bed plotting routines.
gui.py: A GUI to make calibration easier.
To use the GUI:
- Use the Printer Menu tab to configure the various settings to match your printer.
- Calibrate Button, will perform a series of measurements across the whole bed at the specified X & Y step size.
- Quick Cal Button, will perform a quick test at four specified points across the bed.
- Variance Button, will perform a repeated measurement at a specified point to see what the variance is for the microswitch.
Thursday, April 21, 2011
SkeinArchiver
One of the problems I have regularly with Skeinforge is that after tweaking some settings and getting everything just how I want it, I go and modify something for another print and forget to go and save the contents of the '.skeinforge' directory as a back-up. Then I can't remember what settings I had before.
I decided to write a simple program that makes it easy to quickly archive the settings once you have them dialed-in. Allowing you to keep them safe and then restore them at a later date.
The result is SkeinArchiver, it's very simple to use and I've already found it to be beneficial. I have several profiles archived and my first task during each printing session is to restore the most appropriate saved archive before I start making any tweaks. That way I always start from a known point and don't accidentally have an old setting lingering around from one of my experiments (multiply is a favorite or printing at the wrong layer height).
SkeinArchiver
Save - Prompts the user to name the new archive. It suggests a name based around the days date. Then it saves the Skeinforge settings files in a Zip file in the local script directory.
Restore - Prompts the user to pick an archive to restore. This will overwrite the existing Skeinforge settings, so if you have something useful configured, save it first.
Dir to Arch - This allows the user to select the Skeinforge settings directory to archive. By default the program assumes the directory is under '~/.skeinforge', which is where Skeinforge prefers to put it. If you haven't moved it, you don't need to worry about this button.
About - Provides useful information about this version of the tool.
Quit - Pretty self explanatory.
If anyone else fancies using this tool, they can find it here: SkeinArchiver
Hopefully others will find it useful too.
I decided to write a simple program that makes it easy to quickly archive the settings once you have them dialed-in. Allowing you to keep them safe and then restore them at a later date.
The result is SkeinArchiver, it's very simple to use and I've already found it to be beneficial. I have several profiles archived and my first task during each printing session is to restore the most appropriate saved archive before I start making any tweaks. That way I always start from a known point and don't accidentally have an old setting lingering around from one of my experiments (multiply is a favorite or printing at the wrong layer height).
SkeinArchiver
 |
| SkeinArchive |
Restore - Prompts the user to pick an archive to restore. This will overwrite the existing Skeinforge settings, so if you have something useful configured, save it first.
Dir to Arch - This allows the user to select the Skeinforge settings directory to archive. By default the program assumes the directory is under '~/.skeinforge', which is where Skeinforge prefers to put it. If you haven't moved it, you don't need to worry about this button.
About - Provides useful information about this version of the tool.
Quit - Pretty self explanatory.
If anyone else fancies using this tool, they can find it here: SkeinArchiver
Hopefully others will find it useful too.
Wednesday, April 20, 2011
I Can Finally Have That Drink
Six-months after starting my Mendel journey I can finally have that drink!
The very first thing I printed was the mini-shot glass that is recommended to toast your success. However, as a shot-glass is was a definite fail, it may have functioned as a very small strainer but holding any alcohol was out of the question.
The McMaster pulleys that I used had increased X, Y & Z dimensions by 25% making the gaps between layers and threads very large. I also hadn't got to grips with the tools which left me scratching my head for some time.
After a few failed attempts at the shot-glass I focussed on dialing in Repsnapper, then I switched to Skeinforge and spent time on that, completely forgetting about the shot-glass and focusing on cubes (which my wife refers to 'companion cubes' as I seem to spend lots of time with them in the workshop!).
Now that I've got Skeinforge in hand and my Mendel is printing well I thought perhaps it was time to break out the shot-glass again. I am pleased to say it looks a damn sight better and it holds liquid.
Unfortunately, it doesn't really hold very much, so it was a swift toast with the shot-glass, then on to a much larger receptacle to celebrate further.
The very first thing I printed was the mini-shot glass that is recommended to toast your success. However, as a shot-glass is was a definite fail, it may have functioned as a very small strainer but holding any alcohol was out of the question.
 |
| My Very First Print! |
The McMaster pulleys that I used had increased X, Y & Z dimensions by 25% making the gaps between layers and threads very large. I also hadn't got to grips with the tools which left me scratching my head for some time.
After a few failed attempts at the shot-glass I focussed on dialing in Repsnapper, then I switched to Skeinforge and spent time on that, completely forgetting about the shot-glass and focusing on cubes (which my wife refers to 'companion cubes' as I seem to spend lots of time with them in the workshop!).
Now that I've got Skeinforge in hand and my Mendel is printing well I thought perhaps it was time to break out the shot-glass again. I am pleased to say it looks a damn sight better and it holds liquid.
 |
| A Drink-worthy Version |
Unfortunately, it doesn't really hold very much, so it was a swift toast with the shot-glass, then on to a much larger receptacle to celebrate further.
 |
| One Shot Glass, One Strainer |
 |
| Spot the Difference! |
Flow Rate Redux
After spending the weekend trying to understand the Flow Rate settings in Skeinforge by going back to basics and looking at the physics of extrusion, I then found this newsgroup post that talks about the changes to Skeinforge 40. In this new version of the tool the Skeinforge calculates the volume of filament entering the extruder and hence the volume coming out.
This requires some changes to the firmware. In the original firmware the E_STEPS_PER_MM variable specified the number of 'steps' the extruder needed to make to extrude 1mm of filament. With Skeinforge 40 it now specifies the number of 'steps' needed to push 1mm of filament into the extruder. This combined with the new setting in Skeinforge that specifies the filament diameter allows the tool to figure out how much filament it needs to extrude for a given speed - no more calibrations required.
I followed the technique described in the newsgroup post to calculate my new E_STEPS_PER_MM value.
Initially it started off at 20.1, but after setting Repsnapper to output 100mm (Length on the Print tab) and measuring the amount of filament entering the extruder, I came up with the following value:
I used 80% of this value (536) as the value in the Gen6 FW, recompiled, up-loaded and retested. Now 65mm of filament was pushed into the extruder. Repeating the calculations gave the following value:
Recompile, up-load and repeat testing gave about 75mm filament pushed into the extruder. This clearly was incorrect, so I watched the extruder carefully. It was slipping so I had to tighten the idler bolts, then I retested it again. Now 104mm of filament was fed into the extruder.
You guessed what comes next. Now it was 97mm of filament, so....
Finally I had 100mm of filament entering the extruder.
I tested the settings with my favorite test prints - Feed Rate and Flow Rate set to the same value, and right of the bat they were amongst the best I've had. I could even change the layer height from 0.4mm to 0.3mm without any other tweaks and still get a perfect print.
So how does this compare with the physical analysis in my previous post?
With the new settings the E/L in the GCode file was around 0.04355mm/mm. This should scale by the ratio of the new E_STEPS_PER_MM over the old one and come out around the 1.617 value I calculated previously.
Fairly close, but not exact. However, going forward I'll be using the new version of Skeinforge to calculate the settings - it's a lot more straight forward.
This requires some changes to the firmware. In the original firmware the E_STEPS_PER_MM variable specified the number of 'steps' the extruder needed to make to extrude 1mm of filament. With Skeinforge 40 it now specifies the number of 'steps' needed to push 1mm of filament into the extruder. This combined with the new setting in Skeinforge that specifies the filament diameter allows the tool to figure out how much filament it needs to extrude for a given speed - no more calibrations required.
I followed the technique described in the newsgroup post to calculate my new E_STEPS_PER_MM value.
Initially it started off at 20.1, but after setting Repsnapper to output 100mm (Length on the Print tab) and measuring the amount of filament entering the extruder, I came up with the following value:
100*20.1/3mm = 670
I used 80% of this value (536) as the value in the Gen6 FW, recompiled, up-loaded and retested. Now 65mm of filament was pushed into the extruder. Repeating the calculations gave the following value:
100*536/65mm = 824.62
Recompile, up-load and repeat testing gave about 75mm filament pushed into the extruder. This clearly was incorrect, so I watched the extruder carefully. It was slipping so I had to tighten the idler bolts, then I retested it again. Now 104mm of filament was fed into the extruder.
100*824.62/104mm = 792.90
You guessed what comes next. Now it was 97mm of filament, so....
100*792.90/97mm = 817.42
Finally I had 100mm of filament entering the extruder.
I tested the settings with my favorite test prints - Feed Rate and Flow Rate set to the same value, and right of the bat they were amongst the best I've had. I could even change the layer height from 0.4mm to 0.3mm without any other tweaks and still get a perfect print.
So how does this compare with the physical analysis in my previous post?
With the new settings the E/L in the GCode file was around 0.04355mm/mm. This should scale by the ratio of the new E_STEPS_PER_MM over the old one and come out around the 1.617 value I calculated previously.
0.04355 * 817.42/20.1 = 1.77
Fairly close, but not exact. However, going forward I'll be using the new version of Skeinforge to calculate the settings - it's a lot more straight forward.
Saturday, April 16, 2011
Calculating the Flow Rate value
The Flow Rate setting under the Speed menu in Skeinforge appears to be the first key to getting high quality prints. However, it’s still a bit of a mystery to me. From what I have read, the aim appears to be to vary the Flow Rate until the layer height is equal to the Layer Thickness setting in the Carve menu while at the same time creating a layer width equal to Layer Thickness multiplied by Perimeter Width over Thickness ratio (both in the Carve menu).
The settings for these values I have selected are Layer Thickness = 0.4mm, Perimeter Width over Thickness ratio = 1.8. This means that the perimeter filament width should be 0.4mm x 1.8 = 0.72mm wide.
So the aim of adjusting the flow rate setting is find the value of flow rate that creates both a layer height of 0.4mm and a layer width of 0.72mm. This can be a tedious task of printing multiple test structures and accurately measuring the width and height of the resulting object – there has to be a way to calculate the values without all the trial an error.
Working through the Physics:
Let’s consider a situation where the extruder is stopped over the bed and the nozzle is 0.4mm above the bed. The nozzle extrudes filament at 0.5mm:
Minimum Filament Extrusion to Fill the Space Under the Nozzle:
 |
| Figure 1: Nozzle Extruding Minimum Amount of Filament to Fill Space under Nozzle |
The minimum volume of filament deposited in this situation is :
= 0.07854mm3
= 0.07854mm3Creating the Required Extrusion Profile:
To get the required filament width we need to extrude more filament than the minimum so that it is forced to spread out under the nozzle and create a wider trace. The Layer Thickness should always be 0.4mm as the filament will be trapped by the nozzle head and it is unlikely to end up thicker than this height – so we don’t need to worry about the Layer Thickness. It could conceivably get thinner if the flow rate is too low, as it will get stretched as the extruder head moves.
 |
| Figure 2: Nozzle 'over-stuffing' to Create Wider Trace under Nozzle |
The volume of this squashed filament can be calculated by approximating the cross sectional area and multiplying by the length. The cross-sectional area looks roughly like this:
This area can be calculated as:
Where:
H = 0.4mm and W = 0.72mm
Therefore, A = 0.253664mm2
The volume is therefore A x L = 0.37933 x 0.5 = 0.12683mm3
So, to extrude sufficient filament to create the oval cross section, for every millimeter the extruder travels, the extruder needs to extrude 0.12683/0.07854 = 1.6148mm (Something I will refer to as the Volume Ratio)
Setting up the Flow Rate:
Now we need to find a flow rate setting that creates a GCode file that attempts to extrude 1.6148mm of filament for every 1mm of extruder travel.
The easiest way to do this is to set an arbitrary Flow Rate value and create a GCode file. Then look at pairs of G1 codes to calculate the length the extruder head moves and compare it to the extruder E-values. To calculate the distance the extruder head moves:
GCode Fragment:
G1 X91.08 Y89.73 E34.7135
G1 X89.73 Y91.08 E37.801
Calculating Extruder Travel:
L = [(89.73 – 91.08)2 + (91.08 – 89.73)2]0.5
L = [-1.352 + 1.352]0.5
L = [1.8225 + 1.8225]0.5
L = 3.6450.5
L = 1.9092mm
The Extruder head is moving 1.9092mm from (91.08, 89.73) to (89.73, 91.08), at the same time the extruder is being told to extrude:
E = 37.801 – 34.7135 = 3.0875mm of filament
So the extruder is outputting E/L mm of filament per mm traveled.
E/L =3.0875/1.9092 = 1.617
In this example, the Flow Rate setting that was used to generate this GCode file is set perfectly. But, if E/L is too high, decrease Flow Rate and re-run the GCode generation and calculation. If E/L is too low, increase the Flow Rate and re-run the GCode generation and calculation until you get the right value.
I have written a Python script that performs the calculations on the whole GCode file to make things simpler when trying to find E/L.
I’ve also found that multiplying the Volume Ratio by 547 yields the correct Flow Rate value.
Test Print:
With my parameters, the Flow Rate value works out to be 880. When I create a GCode file of a test object with this value and print it on my Mendel I get very high quality print results as shown below. The width of the filament varies between 0.71mm and 0.78mm based on a dozen measurements around the perimeter, with the average value being 0.74mm – just marginally bigger than my required 0.72mm.
 |
| Figure 3: Side View of Test Print Hollow Cube |
The bottom layer fill is very full without being over-filled. The inner-layer fill still needs a bit of work, it appears that the overlap settings aren’t quite right as the inner fill disrupts the outer layers on solid objects. I think that I’ll reduce the Infill Perimeter Overlap, I’m also going to add an extra shell on all layers to give an extra thick shell on the outer layers to try and keep it as neat as this test print.
 |
| Figure 4: Bottom Layer of Test Print Hollow Cube - A little over-filled in one corner. |
Monday, April 11, 2011
Building a Spool
After the other night's test print it has become clear that a spool is really required to stop the filament getting tangled and keep an even draw on the extruder. This weekend I used up some of the odd's and end's I had kicking around the workshop to build one.
I used some 1/4" plywood, 3/4" dowel rod, some old bearings, some steel rod and scrap 4x2.
In hindsight the bearings may have been a bad idea, its so friction free that it will freely spin for several minutes after I give it a good heave. I've had to force the stand up close to the bearings to introduce some friction into the system.
Unraveling the coil of filament I had and winding it on to the new spool is not a task I'd wish on anyone. There was at least two and half hours of manually untangling the various 'knots' that had formed - it was like the worlds worst telephone cord! Then there was at least 90-minutes of winding it on to the spool. Throw in two failed attempts, multiple curse words and you had a whole Sunday evening of fun. Still the results should give better prints at the end of the day!
I used some 1/4" plywood, 3/4" dowel rod, some old bearings, some steel rod and scrap 4x2.
 |
| The New Spool |
In hindsight the bearings may have been a bad idea, its so friction free that it will freely spin for several minutes after I give it a good heave. I've had to force the stand up close to the bearings to introduce some friction into the system.
 |
| Compulsory Action Shot |
Thursday, April 7, 2011
Updating Gen6 Electronics Firmware
This post focuses on how to update the firmware on the Gen6 Mendel electronics.
Install Arduino Tool-Chain:
First you'll need the correct tool chain to be able to compile, link and download the firmware to the Gen6 board. Download and install the Arduino tools from here: Arduino Tools
You'll also need to install the Sanguino add-on from here: Sanguino Tools
Get the Latest Gen6 Firmware:
The latest firmware currently resides here: Gen6 FW
The firmware includes all the source code, so you can make any changes or modifications required. My specific changes are listed below.
Compile the FW Project in the Arduino Tool-Chain:
Run the Arduino tools and 'Open' the project by navigating to the latest firmware directory and opening the file 'FiveD_GCode_Interpreter.pde'.
Once you've made any changes you need, press CTRL+R to compile and verify the code. If you get any compilation errors, fix them now.
Upload the Build to the Hardware:
Once you get a clean build you can upload the code to the board. Power up the Gen6 board and connect the USB. I would also suggest that you open RepSnapper and connect to the printer and just jog the bed before attempting an upgrade, otherwise you'll get a communication failure error from the Arduino tools.
Verify that under the 'Tools->Board' menu you have 'Sanguino' selected. Also under the 'Tools->Serial Port' make sure that you have the correct COM port selected.
Now you can press the 'Upload' button (Right pointing arrow on the tool bar), this will compile the code and then attempt to upload the code to the Gen6 board.
If you get the following error from the Arduino tools:
Try opening RepSnapper and jogging the bed again before shutting the RepSnapper tools (don't turn the printer off), then try the upload again.
Once the upload completes you can close the tools and power cycle the hardware.
My Specific Changes:
As I mentioned previously, I have different drive pulleys on my stepper motors. This required that I recalibrate my steps/mm calculation in the firmware.
In 'configuration.h' under the section #ifdef Mendel (around line 163 in FW from Jan-2011) at the end of the pulley descriptions I added this section:
#ifdef MCMASTER_10XL_PULLEYS
// define XYZ parameter of McMaster 10-tooth XL-series pulleys
// Added by JMB - 29-Oct-2010
#define X_STEPS_PER_MM 31.484 //31.641
#define X_STEPS_PER_INCH (X_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_X_DIR 1
#define Y_STEPS_PER_MM 31.599 //31.394
#define Y_STEPS_PER_INCH (Y_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_Y_DIR 1
#define Z_STEPS_PER_MM 2689.682
#define Z_STEPS_PER_INCH (Z_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_Z_DIR 0
#endif
Install Arduino Tool-Chain:
First you'll need the correct tool chain to be able to compile, link and download the firmware to the Gen6 board. Download and install the Arduino tools from here: Arduino Tools
You'll also need to install the Sanguino add-on from here: Sanguino Tools
Get the Latest Gen6 Firmware:
The latest firmware currently resides here: Gen6 FW
The firmware includes all the source code, so you can make any changes or modifications required. My specific changes are listed below.
Compile the FW Project in the Arduino Tool-Chain:
Run the Arduino tools and 'Open' the project by navigating to the latest firmware directory and opening the file 'FiveD_GCode_Interpreter.pde'.
Once you've made any changes you need, press CTRL+R to compile and verify the code. If you get any compilation errors, fix them now.
Upload the Build to the Hardware:
Once you get a clean build you can upload the code to the board. Power up the Gen6 board and connect the USB. I would also suggest that you open RepSnapper and connect to the printer and just jog the bed before attempting an upgrade, otherwise you'll get a communication failure error from the Arduino tools.
Verify that under the 'Tools->Board' menu you have 'Sanguino' selected. Also under the 'Tools->Serial Port' make sure that you have the correct COM port selected.
Now you can press the 'Upload' button (Right pointing arrow on the tool bar), this will compile the code and then attempt to upload the code to the Gen6 board.
If you get the following error from the Arduino tools:
Problem uploading to board. See http...
Binary sketch size: 23982 bytes (of a 63488 bytes maximum)
avrdude: stk500_getsync(): not in syinc: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51Try opening RepSnapper and jogging the bed again before shutting the RepSnapper tools (don't turn the printer off), then try the upload again.
Once the upload completes you can close the tools and power cycle the hardware.
My Specific Changes:
As I mentioned previously, I have different drive pulleys on my stepper motors. This required that I recalibrate my steps/mm calculation in the firmware.
In 'configuration.h' under the section #ifdef Mendel (around line 163 in FW from Jan-2011) at the end of the pulley descriptions I added this section:
#ifdef MCMASTER_10XL_PULLEYS
// define XYZ parameter of McMaster 10-tooth XL-series pulleys
// Added by JMB - 29-Oct-2010
#define X_STEPS_PER_MM 31.484 //31.641
#define X_STEPS_PER_INCH (X_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_X_DIR 1
#define Y_STEPS_PER_MM 31.599 //31.394
#define Y_STEPS_PER_INCH (Y_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_Y_DIR 1
#define Z_STEPS_PER_MM 2689.682
#define Z_STEPS_PER_INCH (Z_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define INVERT_Z_DIR 0
#endif
I also added the following line (around line 82) where the configuration is determining which pulleys are being used:
#define MCMASTER_10XL_PULLEYS
The board should now be configured and programmed with the latest version of firmware, Happy Printing!
Wednesday, April 6, 2011
Leveling the X-axis and the Bed
Tonight's main focus was on leveling the X-axis and the bed to try to correct this continual Z-offset that keeps occurring. Last nights attempt to adjust the Z-flag had helped but it was still occurring.
I started by verifying that the Y-rods were level, which they were. Then I used those as a reference to measure the distance between the X-rods. There was a delta between the two ends of a few tenths of mm. Given that 0.1mm variation in extruder height can make a difference between good first layer adhesion and not, this needed to be corrected.
I loosened the tensioning pulley on the Z-belt and manually adjusted each Z-screw until the reading on the calipers was the same for each Y-rod to front X-rod distance. Then I tightened everything back up making sure that nothing moved. When it was all back together I reverified the measurements to make sure nothing had moved.
I then used a similar technique to set the height of the bed from the Y-rods. This was a loooong process as each adjustment changed the other spring heights slightly. Once they were all the same I could proceed to verify the bed against the extruder nozzle. It was fairly level now, but did require some minor adjustments to bring the separation between the nozzle and bed even in all corners.
I also discovered something interesting with the printed 'W' bed springs. They don't apply even force to the bed. I had them running parallel with the bed, but I found that on the top of the spring was not always flat and applied more pressure either before the bolt or after (depending on how the top was distorted), changing the bed height very slightly. I decided to rotate the springs 90-degrees to be perpendicular to the bed, so their top surface has less contact along the length of the bed. This appears to help these slight bed distortions.
I then was able to get on to some more test prints. I dialed down the flow rate to 1200 (from 1300), the print quality was very good. Possibly one of the best to date. The first layer still had too much flow, so I may need to play with the first layer settings. As the print went on, the higher layers got more ropey, I put that down to how I have my spool of filament. It doesn't turn very easily and after some time printing the force required to pull filament off the spool is too much for the extruder - unless I manually turn the spool a bit. Must get a better spool!
The print continued to pause nearly every layer - just like last night, so I did roll-up my sleeves and dive into the G-Code. Skeinforge appears to be generating the deprecated M108 code (old code to control the extruder). A quick search and replace removed them all and the GCode printed without issues. I need to add M108 to my replace file.
I also updated my Gen6 Firmware to the latest version that came out earlier this year. Tomorrow I'll write a detailed article on how to upgrade the firmware and some of the changes I made (these for my own benefit so I can figure out how to do it again when the next release comes out!)
I started by verifying that the Y-rods were level, which they were. Then I used those as a reference to measure the distance between the X-rods. There was a delta between the two ends of a few tenths of mm. Given that 0.1mm variation in extruder height can make a difference between good first layer adhesion and not, this needed to be corrected.
I loosened the tensioning pulley on the Z-belt and manually adjusted each Z-screw until the reading on the calipers was the same for each Y-rod to front X-rod distance. Then I tightened everything back up making sure that nothing moved. When it was all back together I reverified the measurements to make sure nothing had moved.
I then used a similar technique to set the height of the bed from the Y-rods. This was a loooong process as each adjustment changed the other spring heights slightly. Once they were all the same I could proceed to verify the bed against the extruder nozzle. It was fairly level now, but did require some minor adjustments to bring the separation between the nozzle and bed even in all corners.
I also discovered something interesting with the printed 'W' bed springs. They don't apply even force to the bed. I had them running parallel with the bed, but I found that on the top of the spring was not always flat and applied more pressure either before the bolt or after (depending on how the top was distorted), changing the bed height very slightly. I decided to rotate the springs 90-degrees to be perpendicular to the bed, so their top surface has less contact along the length of the bed. This appears to help these slight bed distortions.
I then was able to get on to some more test prints. I dialed down the flow rate to 1200 (from 1300), the print quality was very good. Possibly one of the best to date. The first layer still had too much flow, so I may need to play with the first layer settings. As the print went on, the higher layers got more ropey, I put that down to how I have my spool of filament. It doesn't turn very easily and after some time printing the force required to pull filament off the spool is too much for the extruder - unless I manually turn the spool a bit. Must get a better spool!
The print continued to pause nearly every layer - just like last night, so I did roll-up my sleeves and dive into the G-Code. Skeinforge appears to be generating the deprecated M108 code (old code to control the extruder). A quick search and replace removed them all and the GCode printed without issues. I need to add M108 to my replace file.
I also updated my Gen6 Firmware to the latest version that came out earlier this year. Tomorrow I'll write a detailed article on how to upgrade the firmware and some of the changes I made (these for my own benefit so I can figure out how to do it again when the next release comes out!)
Subscribe to:
Posts (Atom)