Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: MechanoMan on February 10, 2015, 05:55:05 AM
-
I am doing some raster 3D carving, and noting that the speed seems limited in ways that can't be explained by the actual machine.
I have a 6"x6" relief with a 1/16" ballnose doing 20% stepover. So 2880 linear inches. Feedrate 400ipm. By itself, 2880/400= 7.2 min. Which, I understand, decelerating to a stop to lift up over a feature with an abrupt change in Z-height takes extra time. And I watched it, on flat areas it rips right across but really slows to a crawl across detail with Z-movement.
The machine's XY axes were set at 600 ipm 40 in/sec/sec accel, z set at 200/50. This got 37:30 runtime. So I play with possible more aggressive numbers for acceleration and get only modest gains.
For information purposes I went in and entered the max acceleration Mach3 allowed, which was 187. Well it lowered the runtime some, to 22:44. Tried kicking Z up to 400 ipm and still no improvement. Kicked XY down to 400 ipm max, which opened up acceleration to be set to 281 in/sec/sec. Still no significant change in runtime.
Well if acceleration was the limiting factor, those crazy high acceleration numbers should have brought it close to 7.2 min. But no dice.
Had a theory "maybe the Ethernet Smoothstepper has a processing limit" so I changed to a profile with Parallel Port. No difference.
Loaded Mach3 on a different PC just in case somehow it was looking at processor speed and slowing down the run if the PC couldn't calculate that fast. No difference.
Changed Kernel Speed and restarted. No difference.
Doubled the ipm in the file, no effect.
So it seems like motor performance is not the reason time cannot be brought below 22:44. Mach3 is introducing some sort of speed limit across detail that has nothing to do with acceleration- what is it??
-
Are you in exact stop mode?
What is your look ahead set to?
Hood
-
A friend of mine makes guitar necks. With Mach3 and a UC100, his programs took 1hr 5 minutes. When he switched to the UCCNC control software (which controls the UC100), the same program would run in 45 minutes. Roughly 30% speed increase, and more accuracy. It appears that there are issues with the trajectory planner in Mach3.
One thing you can try is to increase the lookahead to a higher number. My froend says it increases the speed, but results in Mach3 occasionally rounding some corners.
-
Switching to Exact Stop, it doubled the runtime, so it definitely wasn't using it before. So I went back to CV mode.
Lookahead was 20. I changed to 40 and I changed to 5. Nothing made a difference.
I did watch the actual feedrate during the physical run. It changed so much you couldn't make anything of it, but I saw like 120- 70 when it went into the detail work. Adjusting the Feedrate % slider had no effect. The Feedrate was already set to 400 ipm but it wasn't ever able to do that so setting to 200% didn't change anything. I'm suring lowering it to 25% (100 ipm max) would start to slow it down, of course.
-
Change the lookahead to 200 and see if it makes any difference.
-
Nope, no difference.
-
Think about this: If acceleration is set for 281 in/sec/sec the equation is D=1/2AT^2 and V=AT so to get to 400ipm or 6.666 inches per second in 0.023 seconds in a distance of .079" and to stop will take another 0.079" and for a total move required of 0.158" in. 0.046 seconds to start and stop while reaching 400ipm. Note that at a constant velocity of 400ipm the same distance 0.158" is traversed in half the time or 0.023 seconds. This means that the best you could accomplish with moves of 0.158" starting and stopping is twice as long as the total distance at a constant 400 ipm. Shorter moves make the time longer, longer moves reduce the time.
-
Several things happening here. The Z cannot move any faster than the Acceleration values will let it in. AND the XY cannot move any faster than the Z will let them.
To do 3d cnc well with Micro moves it takes a very light fast excellerating machine to do it fast. TOP speed means very little. It is ALL about how FAST you can excellerate .
When your machine runs I bet it gets nowhere near the Feedrate you have set.
Just a thought, (;-) TP
-
Could you post the gcode?
-
Think about this: If acceleration is set for 281 in/sec/sec the equation is D=1/2AT^2 and V=AT so to get to 400ipm or 6.666 inches per second in 0.023 seconds in a distance of .079" and to stop will take another 0.079" and for a total move required of 0.158" in. 0.046 seconds to start and stop while reaching 400ipm. Note that at a constant velocity of 400ipm the same distance 0.158" is traversed in half the time or 0.023 seconds. This means that the best you could accomplish with moves of 0.158" starting and stopping is twice as long as the total distance at a constant 400 ipm. Shorter moves make the time longer, longer moves reduce the time.
But the numbers disprove that. Feedrate time would be 7.2 minutes. Of course you don't actually get that with 3D carving. It's taking 33.5 min, which is 26.3 min overhead- but can this be explained as acceleration delays? Let's see.
Well, time spent in acceleration would be easily tested because it should be fundamentally proportional to the reciprocal of the acceleration parameters. If you double the acceleration parameters for all axes, that would halve the acceleration delays so that overhead time would be halved. That should be 13.15min overhead, plus the 7.2 min, is 20.35 min. But I get 25.13 min, so there's still 17.9 min of overhead. So a full 4.75 min of runtime can't be explained.
So next I change acceleration by 10x, so it should be 7.2 min+ 2.26 min =9.5min. But no, it's 19.9 minutes, it's still got a 12.7 min overhead, of which 10.1 min is unexplained.
Well then that CAN'T be caused by acceleration delays, because the overhead does NOT scale with the reciprocal of acceleration. Something additional is going on inside Mach3 that has nothing to do with acceleration delays.
-
Sure it can be explained YOUR MACHINE cannot run at the values you have selected for accelleration .
(;-) TP
-
Sure it can be explained YOUR MACHINE cannot run at the values you have selected for accelleration .
(;-) TP
You're missing the point there. Yes, obvious a real machine could not sustain 400 ipm and do the run in 7.2 min. The question is, does the real-world acceleration limits really require the 33.5 min runtime?
The analysis is actually showing NO. It's showing the run is being limited by something in Mach3's software which is NOT ipm OR acceleration and thus not physically necessary. The runtime is about 50% higher than it should be with the conservative acceleration limits for an actual machine.
There was never an intent to ask "why can't I run it at 10g acceleration". Rather, to see how much of the overhead is coming from acceleration. The results show that the runtime overhead isn't scaling with acceleration limits- so it's not originating from acceleration limits at all. At from the look of it, that 10 min physically unnecessary "mystery overhead" is slowing down the actual run with conservative accelerations by ~10 min.
-
There is the possibility that speed is being reduced by processing overhead. On a Fadal 4020 I was programming for we got some very slight hesitations in the cutting motion produced by a program that was running a macro that calculated the tool path. I made a change to the program that made all the calculations happen while the machine was rapiding and not cutting and the hesitations went away.
-
There is the possibility that speed is being reduced by processing overhead. On a Fadal 4020 I was programming for we got some very slight hesitations in the cutting motion produced by a program that was running a macro that calculated the tool path. I made a change to the program that made all the calculations happen while the machine was rapiding and not cutting and the hesitations went away.
Any equivalent on Mach3?
I tried it on different computers, and got the same results. Well Simulation and actual run are the same AFAIK, but I'm obviously doing my tests in Simulation. If there were real-world computational lag of creating pulses, I'd be surprised if Simulation could model that without actually creating pulses. In any case I tried it on the Ethernet Smoothstepper profile and the Printer Port profile. Those are totally different CPU loading, but they had the same Simulation time problems.
-
If you're using CV mode, then you really have no idea how acceleration is affecting cut times, unless you know exactly what Mach3 is doing between each move. There are several CV mode options, that can all affect total cut times.
But I believe that the real issue here is with Mach3's trajectory planner.
-
Yeah this is turning out to be a bummer. I built the hardware around the Ethernet Smoothstepper and speed for large 3D carvings is important here. It's looking like Mach3 could be a slow-dog at all of this and I'm stuck with it because ESS can't work with LinuxCNC/EMC2 or anything else.
I can at least load the design into a LinuxCNC machine and see what it says about the runtime.
-
Are you simulating with a demo version or is it licensed ? Do you have a test program I can run.
(;-)TP
-
Next question WHERE are you getting your Estimated Run Time from ?
(;-) TP
-
no chance to see the gcode?
thanks
sam
-
Any good way to upload it? It's a big file.
-
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
-
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.
-
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
-
Hmm ok Mach3 has a tolerance variable I didn't know about:
http://www.machsupport.com/wp-content/uploads/2013/02/Mach3_CVSettings_v2.pdf (http://www.machsupport.com/wp-content/uploads/2013/02/Mach3_CVSettings_v2.pdf)
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.
-
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
-
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
-
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.
-
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
-
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.
-
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.
-
Would be surprised if you do see it on the part.
Hood
-
Only one way to find out. Simulation window doesn't depict how the material actually reacts to tool strikes.
-
ALSO look to reduce the feedrate to just above the average you see when running the code. Trying to run the machine at 500 when the best it will average with combined moves is about 100 can SLOW the overall process.
Just a thought, (;-) TP
-
I don't see how reducing the feedrate alone would improve it. Now you often can improve acceleration if you reduce feedrate, and then the greater acceleration will help, but using a slower speed alone will always be worse.
I found 0.004 tolerance DID notably degrade the wood's appearance. However, 0.002 was only marginally slower than 0.004 and I didn't see any artifacts.
-
We did a LOT of 3d testing in the early days of Mach3 (;-)
(;-) TP
-
Well, I did look at lowered feedrates BTW. It's always the same or slightly worse to lower the feedrate. I don't understand how it could improve it??
-
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
It's been awhile skunkworks, but if you're still around, plz tell me- HOW do you get these figures? Did you actually have to spend 44 min of real time measuring the run, or is there an effective simulator that doesn't actually spend realtime?