Wondering if anyone else has problems with estlcam efficiency for carving? What I mean is, if I have a sign with lots of text to carve the gcode that estlcam generates is often very inefficient, meaning LOTS of travel moves from one end of the sign to the other for a very small detail then all the way back to the other end for another small detail. It seems as though a lot of carve time could be saved if there weren’t so many travel moves clear across the sign. Am I missing a setting or is this just a “feature”?
You can determine the machining order as you’re setting up the file. It seems a bit more time consuming at first but now having seen the way ESTLcam does it I think you’ll find it a big time saver in the end.
I go in 10’s or 100’s with my numbering. That way if I need to go back in (I save all my ESTLCam files) I can insert cuts in between. Like I’ll do part one from 10 upwards. Part two from 50 upwards etc. I tend to do mostly gang cuts of flat parts.
Agreed. Pick you cuts in the order you want them cut, then go and mess with machining order in the drop down. V carves do still move around a lot but Estlcam seems to do a really amazing job in the end.
Thanks for your responses guys! I think I have the machining order sorted out, but what I am referring to is the carve tool paths that estlcam creates (see attached photo). It seems as though the tool paths go from one side of the piece to the other for very small details. On a large piece like the one in the photo all those moves add up significantly. I agree that end the end the results are fantastic, but if there is any way to save a guy some time I’d like to figure it out. Thanks for your advice.[attachment file=76755]
You have not used machining order to its full potential. It looks as if you selected all of that at once. You should be able to see each letter numbered individually and it will not do what you are showing.
So I decided to try separating the letters instead of merging them and when the letters aren’t merged it machines the end of the letter “inside” where it joins with the next one. Plus, the gcode file still jumps around like crazy even with the separated letter technique.[attachment file=76764]
I am also attaching a pic of my machining order for the first file (shown in my previous post). I guess I still don’t know why it jumps around so much. I am open to any suggestions. Thanks![attachment file=76763]
I am carving a sign right now. The estimate was 15 minutes, real-time is nearly 3 hours.
There seems to be a lot of delays in between carving out parts of a letter, does a bit and stops, has a long think and then does a bit more. The end results are perfect, but it takes too long.
There must be some way of speeding it up, but I am not sure how.
Betaish, works well enough. Christian himself is using it solely now, I do too. You can still install both parallel, so does not hurt to install it as well.
I found that if the carve bit had a shallow step depth less than the desired full depth everything would cut multiple times. For example, the 60 degree v is 11 mm wide and if cutting to a depth of 6 mm, the step depth of anything less than 6 will double the number of cuts.
Why it is programmed to move over and do a single plunge and then later go back over and cut that spot completely out so it really never needed to do that to begin with? No idea.
When attempting to manually order the cuts to keep local cuts together I found the pocket operation was no longer separated to the beginning of the file, but dispersed throughout the cut and so it required several bit swaps. My solution was to turn the cut speed up to ludicrous speed rather than deal with multiple but swaps. Foam carving doesn’t prevent that though.
I just did a carve last night and it too was victim to the travelling salesman traversing issue. I typically generate the carve in estlecam with the sequencing left in auto mode then the pocket operation is first with one bit swap and then the v bit carve is next. I typically split the files manually and run them separately.
Christian himself is using it solely now, I do too. You can still install both parallel, so does not hurt to install it as well. 