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.