What controls overall cutting times

[mikejohn]

Gerald suggested I start a new thread here as this 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.)

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").


12827.gif

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