so you mean you want a file like tabs.skp attached to generate gcode like tabs.cnc attached?
I have hacked phlatmill.rb to generate ALL plunge movements, both down and up, at the given plunge feed rate.
find phlatmill.rb attached, save it over your existing one, and you have true plunge rates.
However, note that this WILL slow down your cut rate, especially since all retracts are at plunge speed.
This may not be the most desireable method but I'll leave the official programmers to incorporate this code as they see fit. I can see where withdrawing from a sticky material at G0 rate woudl not be desired, but mostly G0 for retracts should be ok. maybe it should be optional? Attached files PhlatMill.rb (10.3 KB)Â tabs.cnc (2.5 KB)Â tabs.skp (74.5 KB)Â

 

Optional is good, so now it is.... TRUEPLUNGE2 version of PhlatMill.rb attached (V0.924)
set @Limit_up_feed = true to enable up Z moves to be limted to the plunge feed rate, otherwise
the default is to only limit Z down movement to the plunge rate.

Note that this version fixes the bug mentioned at
viewtopic.php?f=100&t=300&start=125#p43438 Attached files PhlatMill.rb (11.1 KB)Â

 

and replying to himself again...
I have done some stuff and you'll find it all in the attached zip file.
To use these modifications you first install SketchUcam 1.0 and then unzip these files over the existing files.

Here is the blurb in the included description file TRUEPLUNGE.TXT
These files add features and fix a few bugs in SketchUCam 1.0

Unzip to Crogram FilesGoogleGoogle SketchUp 7ToolsPhlatboyz
or the equivalent for Sketchup 8

Features added
1 - Metric 3D Gcode (if model is metric)
A bug in setting the feedrate was also squashed

2 - All Plunge cuts use the plunge rate set in the options.
An optional setting allows retract rates to be limted too.
See PhlatMill.rb line 50

3 - Plunge cuts can have a depth factor set, so you can drill only halfway through, etc.
To use this feature you need to change the percentage in the entry box
at bottom right of the Sketchup screen AND press ENTER before clicking
to position a plunge cut. The entry box value will be set to the default
depth factor after each click.

4 - and I forgot to say, added in the code (from Yoram) that prevents retracts between multipass cuts.

A Dictionary entry has been added to Constants.rb
After the line
Dict_cut_depth_factor = "cut_depth_factor"
add
Dict_plunge_depth_factor = "plunge_depth_factor" # overrides cut_depth_factor if set

You should make a copy of your Constants.rb file before unzipping this
collection since the one included here has most values defined in metric
which will probably differ from your preferences.

Files changed:
[pre]
Phlatboyz
Phlat3D.rb
PhlatMill.rb
Constants.rb
Tools
GcodeUtil.rb
PlungeCut.rb
PlungeTool
[/pre]
Thanks to tsimmons who showed the way for the plunge tool depth factor
settings back in 2009 (branches/14_plunge_depth)

$Id: TRUEPLUNGE.TXT 1.1 2013/05/17 13:13:27 david Exp $

EDIT, file removed, seek the latest one down the thread

 

I am working on a further extention to the plunge tool.
This will allow spiral boring of holes larger than the bit diameter.
So instead of having to draw a circle and inside cut it, you could use the plunge tool
to position the hole and some way of specifying the size that I havn't figured out yet.
An extra option is climb or normal milling direction for the spirals (G02 or G03 really).

Anyone interested?

An exampe, of the proposed code is like this:
This should 'drill' an 8mm hole, 5mm deep, using a 3.2mm bit, at 20,20

[pre]
%
G21 G61
G0 Z2
(HOLE 8 dia at 20,20)
(DEPTH 5)
(BIT 3.2)
G0 X20 Y20
G0 Z1
G1 Z-5 F194
G0 Z2
(MULTI)
(0 2.4)
(SPIRAL 20,20,5,1.6,3.2,389,CCW)
G0 Y18.4
G1 Z0
(Z step 1.25)
G03 X20 Y18.4 Z-1.25 I0 J1.6 F389
G03 X20 Y18.4 Z-2.5 I0 J1.6 F389
G03 X20 Y18.4 Z-3.75 I0 J1.6 F389
G03 X20 Y18.4 Z-5 I0 J1.6 F389
G03 X20 Y18.4 I0 J1.6 F389
(SPIRAL END)
g0 Z1
(1.6 2.4)
(offset clamped)
(SPIRAL 20,20,5,2.4,3.2,389,CCW)
G0 Y17.6
G1 Z0
(Z step 1.25)
G03 X20 Y17.6 Z-1.25 I0 J2.4 F389
G03 X20 Y17.6 Z-2.5 I0 J2.4 F389
G03 X20 Y17.6 Z-3.75 I0 J2.4 F389
G03 X20 Y17.6 Z-5 I0 J2.4 F389
G03 X20 Y17.6 I0 J2.4 F389
(SPIRAL END)
G1 Y20
G0 Z2
G0 X0 Y0
%
[/pre]

You will note that Z depth is limited to half bit diameter, and stepover is also half bit diameter.
It first does a simple plunge for the center of the hole, then does one or more spiral cuts around that
ending with flat circles at the bottom of the holes.

I envision this mainly for thos eholes that are just a bit bigger than the bit. Like when you need a 4mm hole for a spar, but are using a 3mm bit for all the cutting.
One could of course use it for circular pockets and even quite large holes, but I think if you want a large hole just draw a circle and inside cut it.

I have made no attempt to draw the feature to scale, so it will be hard to tell which plunge cuts are going to be big holes and which will be just normal plunges. Same with plunge cuts with reduced depth, they all look the same until the Gcode runs (-:

 

Nice work swarfer. How about writing a plugin that will allow you to designate a starting point to start cutting at on each piece in your layout.

Alot of my cut time is wasted on traverse movement from one part to the next.

-Buk

 

Good stuff swarfer! It's nice to see the script getting worked on again (you and tigerpilot).
The depth setting on plunge and retract feedrate are great additions.
I think any addition is nice to have like the spiral option. I myself might not have much use for it but that doesn't mean someone else along the way wouldn't.
I like 7up's suggestion a lot and have hoped for something like this for a long time.

Thanks for you work!

 

in hard materials, for holes not much larger than the bit, there is less stress on the bit, and you can cut at a higher feedrate than the plunge rate (in hard materials, remember).

for larger holes, it is better to just use an inside cut on a drawn circle, with multipass.

The way I've been testing spiral boring, it always uses a sort of multipass because the depth per rotation is limited to about half bit diameter.

 

I see the point but I think it would be better to simply let the code select the shortest route to the next cut. This was way there is less user messing around, and it stills cuts in group order.

I'll put it on my list...

 

The group (part) cut order is not the problem, there's already a plugin for that. We need something to assign the starting point within each group (part).

 

ah, now that leads to something else I'm thinking about.....
but first, I agree with this point now, starting on a corner would be much better. I think this can be organized automatically quite easily, though it may interfere with the minimization of travel from cut to cut.

the thing I'm thinking about is hard materials. and what I'm thinking is that a plunge cut into hard materials could be replaced by a sloping cut . This means a 4 sided cut would actually cut 5 sides, since the first side would have to be cut twice. Complication is that the slope cut would have to be in a side without a tab, and a longish side rather than a short one (need to limit the plunge rate).
I'll have to think about this some more.

Meanwhile I'll look at selecting an acute corner for the start. I notice cuts often start on the edges of tabs which should also be avoided. I hope there is an API call for finding the angle between 2 edges...

 

The best way I can explain it is with a picture...

The cutting will start at Point A which is also where it will end. My machine then has to traverse to the other end of the material to Point B, that is also where that cut will end. It then will traverse the length of the material to start cutting at Point C. This is just unnecessary wasted time. If I could assign the starting points at Point X it would eliminate a lot of cutting (traverse) time. Attached files

 

agreed, but that might also be done by the software searching for 'nearest point in next group' no?
thing is, I think this is within what I know about Sketchup and Ruby at this time, whereas the 'click to specifiy a cut start', well, I dunno where to start (-:

 

Yes, it would be great if the software could take care of it.

 

not perfect, but try this....
tries to find closest point, but moves away from tab segments even if that makes the start point further away.

set @optimize (near the top) to true to get optimized cuts, set to false to get it 'as is was'.
When I compare cut times with it on and off EMC simulation reports exactly the same cut time.
Maybe because my G00 rate is very fast?

EDIT: images of cut paths showing the difference between optimized and unoptimized. Note that this file has not tabs and that might change things....
Optimized
Unoptimized

Note that you need to install my previous changes in the zip file a few posts above before installing this mod, just so you have ALL the latest code

EDIT: 30 MAy 2013 file removed, superceded by sketchucam-trueplunge.zip further down the thread

 

Nice job Thank you swarfer
Here is a quick video showing a test of the new cut order on an existing file that I had worked up.
Looks like it does a great job! I normally on see an order like this if I group and create my own order. looks like that will be a thing of the past. Way to go
p.s. also included the gcode as well
Mark and Trish Attached files NewCutOrder.zip (3.1 MB)Â

 

That looks good, I am pleased so far. However, I fixed a couple of bugs today
(it does some weird stuff when trying to optimize a group of plunge cuts, and don't go near pocket zigzags!) aaaaaaaaaaaaaaaaand
added the spiral hole cutting stuff as well.... let me generate a teaser image....


a simple face, outside cut for reference, and a bunch of plunge cuts.
bright purple lines indicate the depth has been set, and of course size indicates the size has been set.
these are with a 3mm bit, so the ~12mm holes will generate 3 or 4 spiral cuts. The big hole at right bottom is in fact only 50% deep

and it supports a new way of doing multipass plunge cuts, but basically if doing a single pass the center hole will be a fulldepth plunge followed by bitdia/2 per rev spiral cuts.
If multipass is selected the center hole will peck drill, then the spiral cuts will be done using the multipass depth per rev. all plunging is at plunge rate, spirals at normal feed rate.

But, I'll only post the code tomorrow (my tomorrow, 8 hours ahead of texas) after I test it on SU8, and my packaging tools are on the other computer at work. I really should stick it all into subversion I suppose. Also need to clean up some of the gcode comments etc, and remove the indenting I put in to make sense of it all. Found some interesting 'features' in ruby today..... like using (x/y).ceil does not return a length which therefore cannot be easily metric formatted for output.

right, enough brain dump, to bed....

 

Wow this is going to be great swarfer looks awesome so far!

BTW swarfer I applied to the SketchUp Extension Warehouse http://extensions.sketchup.com/ so if we are able to blend all of these new upgrades and changes into SketchUcam we have been approved to post SketchUcam there! It will be open source of course They show a way to package it all into an easy to install .RBZ file that can be loaded right from the new SketchUp(2013) Make.
This is all very exciting! Thank you again so much for all of your help in making this possible
Mark and Trish

 

Nice new options. I've turned a few onto the plugin and they really like it.

Hate to slightly derail here but I can't get the latest sketchucam to show it's toolbar in SK2013. (xp sp3)
I've allowed full control, it shows it active, but no toolbar. It's still in the tools menu though so it still is good.

 

Did you make sure its checked in the View>Toolbars.. menu?

 

Oh yes, checked in both extensions dialog and views.

I'm not to big on the new 'view' popup either. And where is the 'save tool bar locations' button.(or what ever it's called) :? And they also made the 'large tool set' into a single vertical column so now you have to build you own to make it look like the old two column setup :x I haven't gone any further than that because I don't what to start converting till I know that they fixed the program stability issues.

I'm really starting to wonder if I should of gone the cheaper Bonzai3D for my serious work then just exported into SK8 for the g-code creation. :roll:

 

oops, I have created a bug in the multipass generation of pocket zigzags so there will be a delay while I figure out what I did wrong.