Hello Guest it is November 23, 2020, 10:28:01 PM

Author Topic: Maximum processing speed?  (Read 9175 times)

0 Members and 1 Guest are viewing this topic.

skunkworks

• 32
Re: Maximum processing speed?
« Reply #20 on: February 12, 2015, 07:35:39 AM »
how big?  you can attach files here it looks like if they are less than 6mb..  (additional options drop down in the reply page)

sam

MechanoMan

• 120
Re: Maximum processing speed?
« Reply #21 on: February 12, 2015, 04:33:20 PM »
Here it is.  6"x6", 0.0125 stepover= 2880 linear inches

It rasters across Y because that axis can be tuned a bit faster than the X on the real machine.

I'd like to take it to a LinuxCNC machine and see how long it takes there.

skunkworks

• 32
Re: Maximum processing speed?
« Reply #22 on: February 12, 2015, 08:52:08 PM »
With linuxcnc you have a path tolerance..  Times are as follows..  (btw the linuxcnc has a very poorly implemented run time estimate - doesn't take into account acceleration - says 8.1 minutes. )

Follow path within (using 40in/s^2-600ipm for xy and 50in/s^2-200ipm for z)
.001" = 44min21sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2017:27:51.png
.005" = 32min25sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2016:15:06.png
.010" = 25min27sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2016:41:28.png

Follow path within (using 200in/s^2-600ipm for xy and 200in/s^2-600ipm for z)
.001" = 21min16sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2018:12:31.png
.005" = 15min43sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2018:32:46.png
.010" = 12min33sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2018:58:18.png

Now one with Follow path within (using 300in/s^2-600ipm for xy and 300in/s^2-600ipm for z)
.001" = 17min45sec http://electronicsam.com/images/KandT/testing/forum/Screenshot%20from%202015-02-12%2019:49:09.png

This is using the new 2.7 pre-release version of linuxcnc (2.6.4 is current release).  It has a lot better trajectory planner in it.  (hope to release soon)  But it seems not too far off from what mach was doing.  (although increasing acc does increase cut speed)

sam

MechanoMan

• 120
Re: Maximum processing speed?
« Reply #23 on: February 12, 2015, 09:31:10 PM »
Hmm ok Mach3 has a tolerance variable I didn't know about:

Config->GeneralConfig->CV Control->CV Dist Tolerance
and
Mainscreen->Alt-6->CV Feedrate

However, they don't seem to have any effect.  With the impossibly high accelerations, adding a high CV tolerance, high Lookahead, and high CV Feedrate doesn't seem to make a difference.  In fact I'm getting 20.5 min now, so it seems to have slowed down.

BR549

• 6,939
Re: Maximum processing speed?
« Reply #24 on: February 13, 2015, 01:15:26 AM »
Looking at your Gcode it is saturated with micro XYZ moves in the range of .0001".  I don't think you willl EVER get that to run efficently. Mach3 or any other controller will never be able to get up to speed.

You would do well to repost the Part with a reasonable Move resolution.

Also use mach3 runtime estimate as a reasonable RUNTIME.  Basing a runtime on Distance x feedrate will not be a realistic value by a long shot.

Just a thought, (;-) TP
« Last Edit: February 13, 2015, 01:18:47 AM by BR549 »

Hood

• 25,846
• Carnoustie, Scotland
Re: Maximum processing speed?
« Reply #25 on: February 13, 2015, 02:46:12 AM »
Sam,
is that path tolerance  what it seems? If it is then I dont think having a tolerance of 10thou set is much use for anything like this, in my world that is 0.254mm.
In fact having even 1 thou tol set would be pretty crap on a lot of things and if it is a +/- tolerance then even worse.
Then again maybe that is not what it means?

I agree with TP, sort out your CAM so it will output more realistic minimum moves and you will see a big improvement on the times with no difference in the finished article.

Hood
« Last Edit: February 13, 2015, 02:47:44 AM by Hood »

MechanoMan

• 120
Re: Maximum processing speed?
« Reply #26 on: February 13, 2015, 04:25:18 AM »
OK, I took the CAM package and went from Very High to Standard image quality.

It doesn't seem to have made any difference, though.  The file size is the same, and there are no options I see to reduce it.

Of course the runtime inside Mach3 simulation was unchanged.  Same number of lines.

I'm not sure more lines is really going to reduce efficiency.  Having a curve made of 50 points and a smoother curve of 500 points should in theory be able to run in the same amount of time.

It's Vectric Aspire.  I doubt it's making any super-crazy G-code here.

Hood

• 25,846
• Carnoustie, Scotland
Re: Maximum processing speed?
« Reply #27 on: February 13, 2015, 04:46:10 AM »
Never used Vectric Aspire so can't say for sure but most CAM packages have an accuracy/tolerance setting.
For example here is a screenshot of the settings in BobCAD.

This is metric BTW

Hood

MechanoMan

• 120
Re: Maximum processing speed?
« Reply #28 on: February 13, 2015, 04:48:43 AM »
Hmm, Vectric Aspire has a Time Estimator.  It gives 16:04 for 600 ipm rapids, there's a "Scale Factor" variable underneath that, set to "2.0".  So, looks like they're just getting 7:02 min based on linear feedrate and rapids, and the Scale Factor is an arbitrary multiplier, it doesn't have a way to guess machine acceleration.

OK I found the "toolpath accuracy" option, it's not in the Toolpaths tab which is weird.  It was set to the default 0.0004".  I changed to 0.004, the file size dropped to 1/4 and the simulation time in Mach3 dropped to 15:52.  Interesting.
« Last Edit: February 13, 2015, 05:02:03 AM by MechanoMan »

MechanoMan

• 120
Re: Maximum processing speed?
« Reply #29 on: February 13, 2015, 05:30:52 AM »
The higher 0.004 tolerance is showing noticeable lines in Aspire's preview simulation, more visible in some designs than others.  Well it's making the vector lines show up.  Clearly what's happening is the rougher approximation is making inaccurate depth in different directions for different raster lines, and so the lines are pretty visible.  Not sure how visible they'll be on wood, though.