What controls overall cutting times

[mikejohn]

Gerald suggested I start a new thread here as this (http://www.talkshopbot.com/forum/show.cgi?tpc=312&post=34986#POST34986) one was getting too long.

I posted this question
I now wonder how many different variables there are in determining the speed for cutting, starting from a .dxf file?
The original design?
The machine?
The conversion (toolpath)coding?
The ramp values?
The machine operating software?
The computer running the machine operating software?

What else?

..........Mike

[benchmark]

Mike

So that we can arrive at an accurate comparison
perhaps I could have the 13 VR values you used on the file.

I was also interested in the font type and what programme you used to create the SBP file.


Paul

[jhicks]

Mike, in addition to these I would add, location of start points on multiple part cuts,chip load of course, bit diameter and geometry, straight lines vs curves, Safe Z between moves, and material. Finally the judgement to cut the "perfect cut edge" at slower speeds vs less perfect and lightly sand.
In general it hasn't been a major concern but we do often preview and ask "How can we improve the strategy & efficiency" before running finals especially on long files. I find that by watching and timing a pilot file 1st sometimes, you see where you need to make changes, then edit for best plan and implementation. Once those general "standards" are well understood, we tend to adopt the appropriate strategies universally as much as possible.

[gerald_d]

If "ramping" were not an issue, then the "move" speeds will be constant throughout the whole cutting process and there would be no surprises with cutting times......

But the above will only be true if the PC generating the pulses (steps) is fast enough...

And if the software that generates the toolpath has not thrown in surplus movements.....

And if the (stepping) motors have enough torque to hold the speed against the cutting force.....

But, a strong machine has mass, which causes inertia, and it cannot change direction while maintaining peak speed. The masses must smoothly accelerate and decelerate (the speeds must "ramp") when going through tight changes of direction. Think of a sports car through a tight mountain pass - better brakes will improve its speed! Better grip/acceleration also increases it speed. A better line through a bend (within the tolerance of the road width) also helps. On a CNC machine, the drivers and software control of them are critical in achieving the best acceleration / deceleration. ("Ramping" is a coarse concept here - we need more finesse - "trajectory control" sounds more elegant). As you see, the Gecko/Mach combination gets more out of given motors in terms of "trajectory" control and hence overall speed.

[gerald_d]

3 posts at the same time!

[benchmark]

Hi Gerald

If "ramping" were not an issue, then the "move" speeds will be constant throughout the whole cutting process and there would be no surprises with cutting times......

I totally agree

That is where I got my suprise... so I ran mike's file in Windows V3.4.21 and got a time of nearly 13min.....surpise, surprise.


I am running a P3 with 512MB ram in the workshop, I was looking for a reason why ? Was it a case of Windozer or vastly different ramping values, hence my question to Mike.

Mike,

Do you run this file as a paying job? Perhaps I can make a suggestion and reduce the Z up and down values between letters from 20mm to 5mm it will save over 2 mt of positioning distance. (Unless you have a clamping issue)

Paul

[gerald_d]

Paul, the Mach system has "ramping" totally under control. There is only one parameter to tune to the mechanics (inertia) of a machine. Once set, it applies for all speeds, all curve radii, all whatever. This parameter is the obvious engineering unit of "Acceleration" in mm/sec/sec. The variable definitions of "ramping" as used by ShopBot are too complex and fuzzy. (see also this thread (http://www.talkshopbot.com/forum/messages/1843/9773.html).)

I agree that Mikes 20mm clearance is far too much if time is critical.

[mikejohn]

Paul
I apologise for not giving the VR values imediately. I need to check the workshop computer.
The font is good old Times New Roman!
You ask "Do I run this as a paying job?" I do. Nearly 400 in the year since I have had my Shopbot. Just 2 lines, not 3. They are for the entrance doors to apartment blocks. In this part of the world there are many apartment blocks! It did start as a sort of community help project, but it is profitable, particularly as it is using time on the Shopbot when it has finished cutting rocking horses.

I have never thought about the z up distance!! Just put in 20 as it seemed right. There are no clamping issues, 6 up signs fit into a simple holding jig.
It is this, and ramping, whatever , that made me start this thread.
With that file I doubt if the Shopbot ever reaches the set speeds, so how can you possibly calculate chip load? And I guess there are many files out there which are similar.

.............Mike

[mikejohn]

This is the file we are talking about.
It measures 650mm (26") x 180mm (7").


9076

The majority of signs are just the bottom 2 lines.

.......Mike

[mikejohn]

Steve M posted this in the original thread
Mike Gcode inch file generated a time of well over 20 minutes. The arc were being cut as line segments.

The improved VisualMill file reduced the cutting time to 11 min. 48 sec.
I have taken the liberty to repost it here, as I now believe it is not just the machine that controls file cutting times.

..............Mike

[gerald_d]

Summary:

The blue v-carved sign shown above is the basis of a speed test. All the relevant files are zipped together in this file (http://www.mechlift.com/speedtest.zip) (speedtest.zip 942kB). Right click on link, save target as...

Mike used mm.sbp, on a PRT96Standard in 10 min 45 sec. Cut speed x/y 50mm(2")PS, z 25mm(1")PS, Jog x/y 100mm(4")PS, Jog z 50mm(2") PS

John used mm.sbp, on an Alpha in 6 min 5 sec. XY speed 300mm/sec, Z speed 100mm/sec. Jog XY 700mm/sec, Z 300mm/sec.

Steve used the inch.dxf file, made a g-code cutting file with Visualmill, and cut it on a Mach/Gecko router with ShopBot motors in 11 min. 48 sec. Don't know what his speed settings were. Don't know if Steve tried to run inch.tap?

I used the mm.tap file, and air cut it on a Mach/Gecko router with ShopBot motors in 7 min. 25 sec. The set speeds were 50mm/sec (some verticals were slower - Mike's program inserted the speeds)

Paul used mm.sbp on an Alpha at over 13 minutes.

Is my summary correct?

(Subsequently, Mike has reduced the safe clearance height and knocked nearly 20% off the time)

Any other volunteers to test the time to aircut these signs? Move speeds set to 2 inches/second on PRTStandards and 10 inches/second on Alphas.

[tom_fiddler]

I have found that trying to get the highest speed will often reduce the quality of my product. I V carve alot of signs in oak.... the wood limits my speed more than anything.

Just my thoughts
Tom

[mikejohn]

Tom
I agree that quality of cut is often more important than speed.
Above, Paul advised me to reduce my Z up value from 20mm to 5mm. I did this and reduced my cutting time from 10 min 45 sec to 8 min 40 sec.
I had paid no real attention to this in the past. I wonder what else I might be missing.
Z moves prior to and after a jog have no bearing on cut quality, so anyone can safely save time with this.
I haven't been able to find a thread on the Forum that looks at all factors that relate to time or speed. Is this really the first?

.............Mike

[Mayo]

If your toolpath software uses an intelligent sorting method, this can also speed things up through efficient motion control. Is your cutter moving all over the place in a seemingly haphazard fashion until the sign is done, or is it cutting first the interior of letters, then the exterior, then moving horizontally (or vertically) to the next letter in line? If your software does not have this capability automatically, then set up your cutting file so that there is no (or as little as possible) wasted motion of the cutter.

[mikejohn]

If your Shopbot is working full out, with no hours to spare, then speed is important. Or rather, shorter file cutting times are important. If the Shopbot is nowhere near being used to its full capacity, do cutting times matter?
Cutting times are not everything, quality of cut may be more important.
A recent thread concentrated on the benefits of speed by upgrading controlers and software.
I have looked at speed against cutting times.
In a straight line cut, the time taken is very close, but slightly more, than what you would expect.
Take the same line length, but divide it into 50 segments going left/right at 90º angles, and the time is increased significantly. Make those segments arcs, but keep the overall length the same, and it takes even longer.

I created the following .dxf file in AutoCad.


9077
It is a crude representation of New Zealand, with a non-existing bridge linking north and south island.
The map is about a meter long (39").
The line is 3946mm long (155")

The following graph shows the time taken to cut at differing set speeds.

9078
The blue line shows the set or target speed.
On the Target speed (x) axis
1 = 12.5mmps (1/2")
2 = 25mmps (1")
3 = 50mmps (2")
4 =100mmps (4")
5 =150mmps (6")

The red line shows the actual average speed attained

1= 5.3mmps(1/5")
2= 8.9mmps (1/3")
3= 14mmps (9/16")
4= 18.7mmps (7/10")
5= 21.6mmps (7/8")
All imperial conversions are approximate.
The Yellow line may be the most interesting. It shows the percentage of actual speed against target speed.This starts at only a little over 40%, but sinks to something around 18%.
Increasing the cutting speed alone is not going to make anything like the time savings you might expect.
Why is this? Everytime any CNC router, even the largest, makes a change in direction, it has to slow down,often stop, and then accelerate again. This is ramping.
If you extrapolate to speeds greater than I have shown, then might we expect the percentages to get even smaller?
Any decrease in cutting times may be important for some people. I think it is also important to have a true estimate of what those gains might be.
I feel, but haven't tested, that if the above .dxf file was toolpathed using different toolpath software above, then different times may be achieved with machines running at the same mmps.

Admin, please do not delete this. It does not challenge anyones claims per se. What it does do is puts any such claims in there true light.

...........Mike

[dirk]

Have a look at this video. It was shot in 2001.
this is being driven by a small nema 23 pacific scientific stepper motor. http://www.marketplace.nl/sensa/HDM48000-12m.p.m.mpg

[mikejohn]

Dirk
Could you explain more about what we are seeing in the video?

............Mike

[richards]

Dirk,
That video is fascinating. It looks like you have linear rails, a ball screw, and vortex chillers. The speed is amazing, especially when you're cutting metal. What were the feed rates of the two axes? What was the router/spindle speed? There doesn't seem to be any 'chatter' marking of any kind.

[dirk]

My point is high speed with high accuracy are very possible. There has been drive technology to achieve this for some time. The limits will change from the electronics and motors limiting speed to the capabilities of the physical drive components to handle this speed. 3 D movement has been very time consuming and marginally profitable. Speed is important on this type of work. Our machines can run 8 hours just to cut a high quality litho. Imagine cutting that down to less than 1 hour. I am in no way recommending this system, but to simply show that it is possible.
Here’s a link to the web page describing the system

http://www.marketplace.nl/sensa/index.html

Dirk

[jsfrost]

Interesting DXF Mike, and it leads to a cut optimization question I've been needing to ask.

In my application, that would be Lake New Zealand, and the task would be to clear the interior to a depth of say 1/4 inch. The end goal is a representation of the lake for display. Appearance is important, absolute accuracy is not. If the scale is large the primary clear might be with a 1/2 EM, followed by cleanup with 1/4 EM and possibly more with 1/8EM. Done in PW or Insignia, the final toolpath has hunderds of "pecks" with the smaller bits. Some add important detail, others just kiss the shoreline with the bit edge, adding lots of cut time, and no visual appeal. Is there a way, other than hand edit of the cut file, to simplify for faster cut?

[drodda]

Dirk,

Any ideas on where this fits in the Price range category. Are we comparing a $1,000,000.00 machine to our $15,000.00 machines? This is very impressive to watch though but some on here are struggling with spending the money to get a spindle. I can only guess as to what this would cost?

[dirk]

I think your looking at a price range of $3,000 for their new smaller version, and under 10,000 for their larger model.
Dirk

[Brian Moran]

Jim,
With regard to simplifying boundaries, a useful technique to remove 'noise' is to select the vectors, offset out by say 1/8", offset the vectors back in by 1/4" and then offset out again by 1/8". This will remove all features both 'male' and 'female' smaller than 1/8" but leave the overall shape the same size. This is the basic technique used when creating inlays to remove all parts of the boundaries smaller than the cutter radius.

Brian

[jsfrost]

Thanks Brian,

In my Lake example, some of the small detail is important feature and some is noise. But if I use your method, then selectively add back important (maybe just important to me) detail from the original DXF to the "Noise free" version, that might work.

[mikejohn]

Brians post above is the sort of information that is of interest.
It is becoming obvious to me that by fully understanding how to produce a cutting file, from concept, through drawing, through conversion can greatly reduce overall cutting times, and/or improve resolution.
If you go back to my original question at the top of this thread, there are probably more parameters that can be added.
I feel these are avenues worth exploring.
A lot of this improvement is free.
Optomising files, how do we do it?


..........Mike