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.
Showing posts with label Skeinforge. Show all posts
Showing posts with label Skeinforge. Show all posts
Wednesday, October 5, 2011
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!
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
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.
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!)
Tuesday, April 5, 2011
Tweaking Skeinforge Begins Again
Tonight was the first night since the move (and replacing the extruder!) that playing with Skeinforge's settings began again in earnest.
First things first, I wanted to correct this continual negative Z-offset that keeps occurring after a few prints. My current theory is that this is caused by the Z-flag not having a parallel edge causing it to cut the IR beam in minutely different places each time. First task for the evening was to remove the flag and verify if the end was square - it wasn't. A few seconds with a file sorted that out.
Over the course of the evening the negative Z-offset still occurs, but it is definitely not as significant as it was previously. I think tomorrow I'll work on verifying that the X-rods are still level. They may have got knocked out of kilter during the move.
As I mentioned previously I'll be using the Skeinforge settings from mendel-parts.com as the starting point for my tweaking.
I copied the defaults into the '.skeinforge' directory in the users folder. Just using these settings as is doesn't appear to work very well on my Mendel. The feed rate of 50mm/s and flow rate of 1400mm/s does not appear provide sufficient flow, resulting in lots of missing threads on the test pieces and the infill gets very thin in places.
Notching the filament as it travels into the extruder shows that it is moving sporadically during periods when it should be flowing quickly and freely - e.g. around the perimeter of the object. I don't think my sprung pinch-wheel is the problem as it appears to flow freely when I run the extruder from RepSnapper. I think that the flow rate is too high for my melt zone.
I think that the filament is being fed in too quickly for the hot end to melt it fast enough to keep a constant flow. My first tweak is then to slow down the feed rate from 50mm/s through 40mm/s to 30mm/s. This appears to give fairly consistent filament feed now. However, the extruded filament is clearly two thick in places. So I'll need to play with the flow rate and bring that down to get everything back in balance.
A quick test with the flow rate at 1300 (from 1400) gives reasonable results, but I've had better, so more tweaking needed there. Also, it appears to generate GCode that causes RepSnapper to hang once per layer and need to be kicked. Not sure why that one change should cause that, but if it keeps doing it I'll roll up my sleeves and start digging in the GCode.
First things first, I wanted to correct this continual negative Z-offset that keeps occurring after a few prints. My current theory is that this is caused by the Z-flag not having a parallel edge causing it to cut the IR beam in minutely different places each time. First task for the evening was to remove the flag and verify if the end was square - it wasn't. A few seconds with a file sorted that out.
Over the course of the evening the negative Z-offset still occurs, but it is definitely not as significant as it was previously. I think tomorrow I'll work on verifying that the X-rods are still level. They may have got knocked out of kilter during the move.
As I mentioned previously I'll be using the Skeinforge settings from mendel-parts.com as the starting point for my tweaking.
I copied the defaults into the '.skeinforge' directory in the users folder. Just using these settings as is doesn't appear to work very well on my Mendel. The feed rate of 50mm/s and flow rate of 1400mm/s does not appear provide sufficient flow, resulting in lots of missing threads on the test pieces and the infill gets very thin in places.
Notching the filament as it travels into the extruder shows that it is moving sporadically during periods when it should be flowing quickly and freely - e.g. around the perimeter of the object. I don't think my sprung pinch-wheel is the problem as it appears to flow freely when I run the extruder from RepSnapper. I think that the flow rate is too high for my melt zone.
I think that the filament is being fed in too quickly for the hot end to melt it fast enough to keep a constant flow. My first tweak is then to slow down the feed rate from 50mm/s through 40mm/s to 30mm/s. This appears to give fairly consistent filament feed now. However, the extruded filament is clearly two thick in places. So I'll need to play with the flow rate and bring that down to get everything back in balance.
A quick test with the flow rate at 1300 (from 1400) gives reasonable results, but I've had better, so more tweaking needed there. Also, it appears to generate GCode that causes RepSnapper to hang once per layer and need to be kicked. Not sure why that one change should cause that, but if it keeps doing it I'll roll up my sleeves and start digging in the GCode.
Subscribe to:
Posts (Atom)