I decided to separate the infill and perimeter routines. The main reason for doing that was that I found that with image processing of objects you tended to get a more detailed, almost fractal description of perimeters than you do with a geometric slice and dice routine like Skeinforge uses. What that means is that the apparent speed of the extruder head doing perimeters is much slower than it would be with Skeinforge simply because the perimeters are described with many more, very short (~0.2-0.3 mm) line segments.
I quickly found that that requires closer control of the extrusion rate than would be the case with Skeinforge. I made some headway on that problem on Saturday, but by no means am I finished working on the problem. It was obvious that infills, composed of line segments maybe a magnitude bigger, did not require the close attention that perimeters do. This led me to separating the two kinds of extrusion roads, a task that took most of Saturday.
Once that was done, I turned my attention to infills and created a little bit harder test exercise.
I then started doing test prints of just the infill. It quickly became obvious that my quick and dirty end-to-end approach to reducing the distance between extruded roads on the infill was not going to be enough. That simple method simply took a infill line segment and looked to the next on to see if the line could be reversed to reduce the time between extrusion. While that helped a lot there was still a lot of stringiness happening because the sweep method I used for identifying infill line segments didn't necessarily put them in proximate order.
Today, I decided to rewrite the end-to-end routine to put the infill line segments into as close a proximate order as possible. It was a very frustrating exercise that finally came right a few minutes ago.
The left infill print uses the end-to-end approach. You can see that the sweep method of identifying line segments leads to a lot of jumping back and forth between the sides of the hole in the block. My new proximate approach, seen on the right, reduces the need for long distance jumps to virtually nothing.
It really is an advantage, having a printer to test your code against.
7 comments:
Trying to convince Enrique to get a printer? :-)
Good work by the way!!
No, I'm not trying to convince Enrique of anything, merely making my own observations. Being able to test my code changes on my Rapman works very well for me. Enrique has accomplished wonderful things, all without a printer. I'd guess that he can visualize things better than I can. Personally, though, I find being able to handle and look at what I am trying to represent a great help. :-)
Roger that :)
Yes, Enrique possess really impressive visualisation skills I must say!
so you could also print the perimeter
with 16mm/s and all that infill with less accurate but massively faster 55mm/s?
I guess the layer-height must still be identical for these 2?
Marcus: yes, that is possible, of course, and makes sense if you are using an infill pattern that uses relatively long print roads like you get with cross-hatching, for instance. If you are using patterns like a hexagonal grid, though, all you are going to do is shake your printer apart.
I once had a similar problem with trying to automatically calcualte the sortest cut path on a CNC machine which was auto cuting shapepes from plywood. The solution I came up with was to create a 2D array of start and end points. The first address in the array is the start point of line segment(n). The second address in the array is the end point of line segment(m). The value at that address is the distance between those two points. I ran a sort to determine the shortest distances and then rank them and stored this information in another array.
I built a really fast routine to pic 10000 semi random paths through the points. Something like a 40% chance to choose the closest point, 25% chance to choose the second closest point and so on.
It keeps the best path (shortest).
That's pretty much the approach I took though I did an exhaustive search instead of a semi-random one.
Post a Comment