Wednesday, August 09, 2006
Serious tests...
I went ahead and ramped up the analysis speed of the routine another two magnitudes so that I could try to slice and trace perimeters for some serious STL files in reasonable, not geological, time frames. I used the involute profile gear script for AoI to generate a 13-toothed gear with a pitch diameter of about 20 mm. The STL file contained 30,486 triangles. I set the grid at 0.1 mm and let it rip. The perimeter is about 0.4 mm across. I probably should make it a bit bigger, but you get the idea.
Not bad, huh? :-D It looks a little rough till you realise that this is really quite a small gear, only about 48 mm in diameter... just under two inches.
Next I'm going to do top down slicing and calculate the support structures. Using Adrian's approach it should be a snap. :-)
Then I'll be revisiting the infill question. :-s
Not bad, huh? :-D It looks a little rough till you realise that this is really quite a small gear, only about 48 mm in diameter... just under two inches.
Next I'm going to do top down slicing and calculate the support structures. Using Adrian's approach it should be a snap. :-)
Then I'll be revisiting the infill question. :-s
Comments:
<< Home
//try to slice and trace perimeters for some serious STL files in reasonable, not geological, time frames//
How long does it take? It really only has to calculate each layer in less time than it takes to deposit the previous one.
How long does it take? It really only has to calculate each layer in less time than it takes to deposit the previous one.
***How long does it take? ***
The 13-toothed gear slices are taking about 90 seconds to process right now. Most of that time is spent reducing the 30,486 triangles in the STL file to a perimeter polygon comprised of a minumum number line segments.
Setting up the grid and deciding what's inside that perimeter takes maybe 1-2 seconds, most of that from painting the image on the screen pixel by pixel, and working out where the perimeter track goes maybe another 2-3 seconds.
There are some fairly well-known methods of cracking the development of the minimum line segment polygon for the slice in a lot less time than I'm using right now. I expect that I can reduce that another 1.5-2.5 magnitudes.
***It really only has to calculate each layer in less time than it takes to deposit the previous one.***
Right now I'm against the idea of trying to calculate the slices on the fly. I'd prefer to slice and develop all the slices and then use some heuristics to go over them with the proverbial fine-toothed comb to see if there are parts of the object being built that aren't being built properly. You need to know about such things before you start extruding plastic, not while you're in the middle of doing it.
I suspect that it will be a long time before we have software that can do STL to CAM instructions conversions with no worry about mistakes. I'd rather see the mistakes on my screen ahead of time instead of seeing them in the object that I've spent hours fabricating afterwards. Screen time is cheap. Polymer and fabrication time isn't.
The 13-toothed gear slices are taking about 90 seconds to process right now. Most of that time is spent reducing the 30,486 triangles in the STL file to a perimeter polygon comprised of a minumum number line segments.
Setting up the grid and deciding what's inside that perimeter takes maybe 1-2 seconds, most of that from painting the image on the screen pixel by pixel, and working out where the perimeter track goes maybe another 2-3 seconds.
There are some fairly well-known methods of cracking the development of the minimum line segment polygon for the slice in a lot less time than I'm using right now. I expect that I can reduce that another 1.5-2.5 magnitudes.
***It really only has to calculate each layer in less time than it takes to deposit the previous one.***
Right now I'm against the idea of trying to calculate the slices on the fly. I'd prefer to slice and develop all the slices and then use some heuristics to go over them with the proverbial fine-toothed comb to see if there are parts of the object being built that aren't being built properly. You need to know about such things before you start extruding plastic, not while you're in the middle of doing it.
I suspect that it will be a long time before we have software that can do STL to CAM instructions conversions with no worry about mistakes. I'd rather see the mistakes on my screen ahead of time instead of seeing them in the object that I've spent hours fabricating afterwards. Screen time is cheap. Polymer and fabrication time isn't.
//You need to know about such things before you start extruding plastic, not while you're in the middle of doing it.//
You have a point. I remember taking a tour of the university engineering labs my freshman year (a few decades ago now). They had a "hall of shame" which included, among other things, a metal block part way through the process of being milled into a fairly complex part, by the looks of it. The block had a sheared-off milling bit sticking out of it. The CNC program, apparently, had flaw due to a misplaced punch card (told you is was a while ago). Part way through the milling process, the bit took a detour through the piece.
You have a point. I remember taking a tour of the university engineering labs my freshman year (a few decades ago now). They had a "hall of shame" which included, among other things, a metal block part way through the process of being milled into a fairly complex part, by the looks of it. The block had a sheared-off milling bit sticking out of it. The CNC program, apparently, had flaw due to a misplaced punch card (told you is was a while ago). Part way through the milling process, the bit took a detour through the piece.
Yeah, the Aussies at UWA near Perth had a little disaster like that just before I visited their project in 1986.
http://www.mech.uwa.edu.au/jpt/shearmagic/images/oracle-homp.jpg
Being Aussies they designed quite a nice sheep shearing robot. They had a momentary power interruption one day not long before my and discovered that the clippers reset position was just about exactly in the middle of the poor sheep's stomach. They were pretty revolted with the whole affair.
They designed another robot shearing machine pretty quickly after that.
http://www.mech.uwa.edu.au/jpt/shearmagic/images/oracle-homp.jpg
Being Aussies they designed quite a nice sheep shearing robot. They had a momentary power interruption one day not long before my and discovered that the clippers reset position was just about exactly in the middle of the poor sheep's stomach. They were pretty revolted with the whole affair.
They designed another robot shearing machine pretty quickly after that.
***You must have missed it.***
Nope, I didn't miss it. I just haven't any experience with OpenGL that would let me do what you described in any meaningful time frame. I've no doubt that you're absolutely right. I just can't make instant use of what you suggest.
I'm acutely aware of the fact that there are undoubtedly some blazingly fast ways of doing what I am currently trying to do. The way I'm approaching things, however, is that I'm not quite sure what it is that I'm wanting to be doing vis a vis getting an object translated into instructions that a RepRap will understand.
For example, you've given a way of doing what I'm currently doing much faster using OpenGL. Somebody else talked about how to do the work quickly by exploiting my PC's graphics card processing capabilities. You'll recall that last week I wasn't using a grid. Next week I may not be using a grid again if my explorations don't pay off.
I'm an explorer and generalist. Once I've got something working that's vaguely useful I'm looking forward to boffins like yourself taking the general idea and giving it really blazing performance... or indeed, just taking over that part of the development task and making something everybody can use. :-D
The way I'm going at things right now, however, is to depend on the skills that I have and those I can acquire relatively quickly and inexpensively to make things work in my systems. That's the reason that I'm developing my own boards, software and such not. If I get an idea that I'd like to test I don't have to bug other people to make the little, or big, changes that are necessary to try it out. I used to depend on other team members for things like that earlier this year and was driving them crazy with my requests. I got out of the habit. It wasn't fair to them. :-)
Nope, I didn't miss it. I just haven't any experience with OpenGL that would let me do what you described in any meaningful time frame. I've no doubt that you're absolutely right. I just can't make instant use of what you suggest.
I'm acutely aware of the fact that there are undoubtedly some blazingly fast ways of doing what I am currently trying to do. The way I'm approaching things, however, is that I'm not quite sure what it is that I'm wanting to be doing vis a vis getting an object translated into instructions that a RepRap will understand.
For example, you've given a way of doing what I'm currently doing much faster using OpenGL. Somebody else talked about how to do the work quickly by exploiting my PC's graphics card processing capabilities. You'll recall that last week I wasn't using a grid. Next week I may not be using a grid again if my explorations don't pay off.
I'm an explorer and generalist. Once I've got something working that's vaguely useful I'm looking forward to boffins like yourself taking the general idea and giving it really blazing performance... or indeed, just taking over that part of the development task and making something everybody can use. :-D
The way I'm going at things right now, however, is to depend on the skills that I have and those I can acquire relatively quickly and inexpensively to make things work in my systems. That's the reason that I'm developing my own boards, software and such not. If I get an idea that I'd like to test I don't have to bug other people to make the little, or big, changes that are necessary to try it out. I used to depend on other team members for things like that earlier this year and was driving them crazy with my requests. I got out of the habit. It wasn't fair to them. :-)
***Surely I'm not the only one to notice that 48mm is just under two inches, rather than "an inch"?***
That was a typo that you've noticed that I've only half-corrected. The gear is about 48 mm or just under 2 inches.
I've fixed it now. Thanks for the heads up!
***The 13-toothed gear slices are taking about 90 seconds to process right now. ***
I've got that down to about 3 seconds now. :-)
BTW,
Post a Comment
That was a typo that you've noticed that I've only half-corrected. The gear is about 48 mm or just under 2 inches.
I've fixed it now. Thanks for the heads up!
***The 13-toothed gear slices are taking about 90 seconds to process right now. ***
I've got that down to about 3 seconds now. :-)
BTW,
<< Home
