I am working on a couple of patches to PhlatscripT and while implementing circular interpolation (cutting smooth arcs, G2/3) codes I had to rework some other parts. While rewriting I made sure it would be easier to add (semi)intelligent toolpath selection when generating gcode when I got around to it.

I am not a CAD/CAM/CNC person by trade and have picked things up as I built my CNC machine. My question for the next potential patch is how should toolpath selection work? In the latest release it relies on the order in which the phlat cuts were made in Sketchup and that is superseded by grouping items in the order you want them cut. Would you rather continue grouping items manually or let the code figure out a mostly optimal path?

 

g2/3 code already works The thread I posted earlier about testing the gcode file in Mach was generated with phlatscript and my patches. Thanks to 3DMON for checking it for me. I haven't even asked Mark & Trish to start testing but that will happen as they have some free time.

 

You mention the "Perfect Tool Path"; that wouldn't be possible unless Sketchup knows the axis speeds at which our particular PP can cut with Mach3. My MK1.5 can do 300+ on X and Y, but it doesn't compare to a MKII, and a stock MKI could be set to 200+ on X and 45 on Y, so the optimal path would probably be different for those conditions also, right?
I'd like to see the toolpath become more efficient, sure, but IMHO, "perfect" ain't gonna happen for more than 1 person at a time.

 

Dorsal, you are completely correct. Look up the traveling salesman problem on wikipedia for how computationally expensive it can be. I was more just trying to get an idea of what people wanted. If everyone expected the perfect toolpath every time on every machine I probably wouldn't even bother with the feature.

Right now I'm leaning towards a quick "what's closest?" algorithm with some weighting to favor X or Y travel.

 

Even basic tool path optimization would be a great addition to phlatscript, I would use it for every layout I do for the PhlatPrinter, plus I would go back and optimize old layouts. I would wait up to few minutes for better tool path optimization, since time is cost once the machine is cutting, who cares if you have to wait two five, or heck sixty minutes, one time if you are going to be cutting the same thing over and over.

I think automatic tool path optimization could save a ton of cutting time, and if I no longer have to spend time grouping parts it frees up my time to design instead of mess around with a task that could be automated. It would be cool if the optimization could order the cuts in a way that prevents snagging of previously cut edges also, basically working from the leading edge of the foam and ending on the trailing edge.

Tool path optimization will be a must have as the faster MK1.5 and MK2 PhaltPrinters come on line because we will start to do more complicated cutting more often, like pocket milling entire surfaces, and our code will get more complex driving the demand up for tool path optimization even more.

 

Gasmasher,

I'm all for any type of automated feature for the phlatscript. If you implement it, what about an option to switch between the classic or new method?

And an unrelated questions. How hard would it be to automatically regenerate phlat lines for different size cutting bits? I am thinking you just offset and delete all the exsisting lines.

-Kwok

 

Famous last words "it wouldn't be that difficult" A lot of code was rewritten to implement arcs and should make future enhancements like that easier. I started on the basic tool path finding and should have it working by next weekend.

I don't want to get too far ahead of testing and I know Mark & Trish are very busy with the MKII right now.

 

gas, I think this would be a great addition to the Phlatscript. At present, if I have a part with a number of inside cuts then I am having to group these 'holes' in the order that I want them cut. If I don't do this, then the cutting order appears to be random regardless of the order that I apply the phlat-cuts.

It's also frustrating If i've worked up a file and then decide to edit a single part. This means that every part has to be exploded and then re-grouped in order again, otherwise the part that has been edited automatically becomes the last part to be cut.

The time taken to automatically generate the toolpaths is not really an issue for me. Even if I only intend to cut a 'one-off' i'd rather spend less time standing over the pp waiting for it to finish cutting (I still don't like leaving it cutting unattended jic) even if it means watching tv for 15mins while to the toolpaths are being calculated.

An option I had thought about would be to automatically have a number assigned to each group as it is created, and then be able to re-arrange the cutting order by simply editing a 'group list' before generating the PhlatCode.

BTW, thanks for all the work you're doing in the background on the Phaltscript, It's amazing what you programming guys can do!

Si.

 

Most often I find myself forgetting to group the parts, then realizing when I go to cut...
Any improvement to the code I support, and that's not to say the code is not top notch right now.

-But really I want auto tabbing first (with option to add tabs).

 

Give me a quick run through of how this would potentially work.

 

Well, I see it one of two ways.
Option 1: After an inside/outside cut (offset) line is applied, it would automatically place tabs on the cut line at a spacing of a fixed amount (perhaps set in the option menu). I'm uncertain on where the start of such tabs would start or how you could trigger the function, perhaps start tabbing closest to mouse position. Then I'm unsure on how to end the function, ie: how would it know when the "loop" is complete. Maybe make this a right click function so original buttons still work as is.

Option 2: Make an additional tab button, and have it function so that when you click a cut line, it will begin with a tab at the location clicked (much like the current version) followed by additional tabs in a CW or CCW direction at a set distance (perhaps set in the option menu). This function would also allow for a number to be entered before you click to change the number of tabs thus defining the end of the loop.

This concept could be improved to make it smarter so that midpoint of all vertical surfaces would be tabbed, greater then "some value" in length, as these are the most likely to catch while feeding the foam. But I can handle doing that on my own, as this may not be desirable for all users of this script.
I want to keep the current tab function, so tabs can be added the same way we currently do them.

The only other thing that would possibly be needed with these solutions would be the option to delete a single tab, if for some reason one couldn't use an auto placed tab for some unforeseen reason.

I would also add the ability to tab all lines generated by the phlatscript, not just the inside and outside cuts. -but that's another issue that can be worked around right now.

 

Hey getting back on topic, how exactly would this work?
Arcs and circles are drawn in SU by line segments.
Would this only apply to un-exploded curves?

 

TV, I sure hope there is somebody out there who understands what you're suggesting, because you are talking WAY over my head!


[

 

lols don't worry I have a loose grasp myself!

 

Actually, it's the right topic. When we have a curve or an arc, right now the tool-path makes it with small strait line. It really should be a smooth arc. It may not be easy to solve, for the Phlatcode maker, since the problem is in SU, who make arcs and circles in small strait lines.

 

Arcs are represented as multiple line segments but they have some extra data attached to them such as the radius and center. I just attach the same data to the offset line segments and then use that data when generating the gcode.

Right now I am working on setting the vertex on which a cut begins. The ability to have the start and end point specified for a cut is needed for the tool path code. It is simple to test if the point is within an arc and push the cut point to the nearest end.

 

hummm maybe I was on the wrong topic! Sorry! :mrgreen: