The constants.rb file contains two variables that define the inside and outside cut depth factor that is applied to accommodate the waviness of FFF.

The default value is set to 140 which the percentage to apply to the cut depth defined in the parameters menu.

If you are cutting lite ply, Depron, or 1" block foam, this depth factor percentage can cause unexpected problems.

Normally, 1/4" material produces a depth of .350 on the Z axis. If you are cutting 1" block foam, the Z axis would actually try to cut 1.4" of foam and allowing the bare shaft to penetrate the foam block.

If you want to make more accurate depth cuts, you can change the following two variables from 140 to 100 and then the material thickness parameter will define the exact depth of your cuts rather than accounting for the FFF waviness. You would have to define your material depth as .350 to achieve the existing depth setup for FFF.

$cut_depth_factor_inside = 100 # changed from 140
$cut_depth_factor_outside = 100 #changed from 140

When cutting lite ply or phonelic, the material runs over the large roller in the back and leaves it at an angle as it approaches the cutting bit. So a 1/16" sheet of ply actually requires the gantry to rise more than 1/16", possibly more like 1/8". Block foam on the other hand will bend and will most likely be flat on the table at the cutting bit depending on the roller pressure of your machine, so if you want to cut a 1" block you could probably define your material thickness to be 1.1" and have it cut thru.

I find that when cutting lite ply and phonelic, it is best to place the material under the rollers and then raise the gantry (after zeroing) noteing the value in which the bit just clears the top of the material. In the past, I have edited the gcode replacing the Z depths with the value obtained by raising the gantry, but this does not allow for changing the tab depths easily.

However, by changing the two variables in the phlatscript, you can simply define the material depth to be the exact value for the upper limit of the gantry movement you wish plunged and the tab depths will also be adjusted accordingly.

 

Fantastic Flash, thanks for the post. I was planning to make a similar one since some of the guys want exact depths for gantry machines but I never got around to it. Sometimes it's really helpful knowing how something works to make the best use of it.

 

Awesome, Thank you guys, I look forward to putting this to the test

John

 

The help button should just be a click on the blue question mark in the toolbar. If that isn't working for you can you open the Ruby Console (under the window menu) and then click the help button? Paste any errors that show up in the console and I'll create a ticket for it. In the meantime you can open the file html file directly in a web browser: Google SketchUp 7ToolsPhlatboyzhtmlhelp.html

The phlatten tool is only available in the right click menu inside SU. Make a selection that includes at least one edge, right click it and look in the Phlat Edge submenu for Phlatten Selected Edges.

Let me know how it works out.

 

Hi Tim, great job again!! Is there a way to set the default for circles to 100 sides so that we can make smaller tabs!! I know you can change this manually but I often forget until the code is written and it has been a real bummer, also I dont like to explode the curves because then it is not seen as a curve!! Thank you again!!

John

 

There isn't a way that I know of to do that in SU. Someone suggested in another thread that it might be possible to set it up in a template but I'm not sure how it worked out. I'll do a little more research and get back to you in just a bit.

 

Awesome Tim, You are always so helpful!!! Thank you!!

 

Thats what I thought Shaun, I know I brought this up before but this is one of those things that would really help save a bunch of time and aggravation!! Either that or if the tab feature could incorporate this in the parameters box to be accurate to the specified sizing!!
Hope we can find a cure lol


John

 

Oh, I had to mention I love the new drag and drop tab feature!!!

 

That was all TVCasualty. He did a great job learning Ruby and implementing that feature.

 

Tim, I have a couple of queries and observations about the new script that i'm curious about.

Firstly I've got to say you've done an awsome job with the offset issue we've all been having. I think i've said it to you before, but AFAIK you're the first person to make the offset tool work like it should do. It's worthy of a SU plugin all by itself.

I've tried the new script today on a few parts that i've had problems with in the past and it's worked pretty well on most of them. I have found a couple of issues though that maybe you can help me with...

A minor issue I found with the outside cut tool is that if a part has a slot that is the same width as the cutting bit then the toolpath isn't created where the lines theoretically overlap. (see Offset Test.skp below). This is easily overcome by either using a smaller cutting bit or enlarging the width of the slot slightly, but I thought i'd point it out.

My main query is regarding the Centerline tool. Most of my designs incorporate pocket cuts where I generate the toolpaths manually using this tool. Using v918 of the Phlatscript I was able to easily choose the cutting order of the centerlines by applying them in the order I wanted them to be cut. In v920 I had the problem where the centerline tool didn't select connected edges which i'm really pleased has been fixed in v922, but i'm still struggling to manually define the cutting order.
The latest script doesn't appear to 'order selected edges', so a single line of connected edges are cut in sections rather than in a single pass. It also appears that i'm going to have to group each line in order to be able to replicate the toolpath that v918 produced.
I've attached the 'manually optimized' gcode from v918 and the gcodes created with v920 and v922 which illustrates the problem.

If anyone can explain what I need to do to get around the probem then i'd really appreciate it.

Si.

Attached files Ailerons v918.cnc (34.4 KB)Â Ailerons v920.cnc (43.9 KB)Â Ailerons v922.cnc (42.9 KB)Â Ailerons.skp (1.1 MB)Â Offset Test.skp (1.3 MB)Â

 

What you are seeing is not the intended behavior and I created another ticket. I'm sorry this causes problems with your models but I hope to have them fixed for the next release. If I get it fixed soon I will have it released before finishing up all the other tickets scheduled for 923.

 

Thanks for raising the tickets Tim. It's no big deal for me at the moment, thanks to Kwok's batch file I can quickly change between the scripts if necessary. It'll be awsome once I can do everyhing with one version of the Phlatscript though

Thanks for all your hard work, it's really appreciated!

Si.

 

Seeing Si's post reminds me, I have made up a few more batch files since the last ones. If anyone needs them, I have just updated the thread: viewtopic.php?f=98&t=1103

 

Yoram, sorry for any confusion, I was refering to Tim's offset algorithm not the native offset tool. If the offset tool worked properly with acute angles then the Phlatscript would have been much easier to develop IMO.
A number of coders on the Sketchunation forum have had simlar problems creating plugins due to the native offset tool's quirks. Tim's new script should solve all these problems from what I can tell.

Kwok, thanks again for the batch files, they really are a big timesaver when comparing new scripts to previous versions.

Si.

 

If anyone is interested in reading further about the problems involved in calculating the offsets I have attached a couple of PDFs. The name for the algorithm is called Straight Skeleton of Polygons.

One of the difficult parts of figuring it all out was the utter lack of sample code floating around the net. The algorithm I implemented is taken from "Straight Skeletons Implementation" by Petr Felkel and Stepan Obdrzalek. The implementation is about 300 lines in PhlatOffset.rb and there are a few comments that coincide with Felkel's paper. There is still more work to do as not all edge collisions are detected but I felt the improvement so far was worth releasing it. Attached files A Novel Type of Skeleton for Polygons.pdf (174.5 KB)Â Straight Skeletons Implementation.pdf (246 KB)Â

 

Thanks for posting those pdf's Tim, it's interesting to get a general idea of how the code works. I haven't studied them in depth, but it's good to see that the algorithm works for polygons with holes. That should make a pocketing tool easier to implement i would imagine.

Did you manage to obtain the C++ code for the algorithm or did you have to code it from the info in the pdfs?

Si. :geek: