A website estimates print time accurately from speed/acceleration/jerk

Shen

I've made a web tool (http://www.gcodeanalyser.com) to analyze gcode files, and report statistic about the file. The program estimates print time with max speed, acceleration and jerk taking into account, so it's quite accurate. It also reports many other information as well. I think this tool might help you find a balance between speed and quality. I'm very new to web development, so the code is not yet polished under the hood, but I will be optimizing the code and adding new features as a way to learn web development. Let me know what's the estimated print time vs actual print time for you.

percar

Looks good I'm going to try it out and compare

Whitewolf

You should fork the duet web control panel and add this as a tab under the print screen then submit a pull request to have it added into the official release.

Shen

@Whitewolf:

You should fork the duet web control panel and add this as a tab under the print screen then submit a pull request to have it added into the official release.

Good idea, but I need to clean up the code first, it's currently a little too messy.

Jackal

That's a nice tool, have you tried comparing it with Duet simulation mode times?
https://duet3d.com/wiki/G-code#M37:_Simulation_mode
I used it before and it gave accurate time (since it actually run all the code without moving the motors), but it takes quite a while.
Hope your online tool is faster

Shen

@Jackal:

That's a nice tool, have you tried comparing it with Duet simulation mode times?
https://duet3d.com/wiki/G-code#M37:_Simulation_mode
I used it before and it gave accurate time (since it actually run all the code without moving the motors), but it takes quite a while.
Hope your online tool is faster

Thanks for letting me know, I wasn't aware of that command before. I made comparison, with the same gcode and settings, my duet wifi reports 1 hour 56 minutes, and my website reports 1 hour 55 minutes. It took at least a minute on the duet wifi, but only 1 second with my website.

tomasf

Nice! Does this work properly with a delta, where the drives do not correspond directly to axes?
I got 8 hours 4 minutes for something that actually took something like 8 hours 30 minutes, which is much better than Simplify3D's estimates.
Having this integrated into the DWC (mainly to fill in the speeds automatically) would be nice.

kelchm

I've been meaning to ask – why are the units for jerk expressed in mm/s? Shouldn't it be mm/s^3?

Shen

@tomasf:

Nice! Does this work properly with a delta, where the drives do not correspond directly to axes?
I got 8 hours 4 minutes for something that actually took something like 8 hours 30 minutes, which is much better than Simplify3D's estimates.
Having this integrated into the DWC (mainly to fill in the speeds automatically) would be nice.

It should work for delta, since the x,y,z acceleration/jerk do not correspond directly to the axis as well.

Shen

@kelchm:

I've been meaning to ask – why are the units for jerk expressed in mm/s? Shouldn't it be mm/s^3?

Jerk in 3D printing does not refer to the same thing as in physics. In 3D printing jerk is the maximum allowed instant speed change. With higher jerk values you can take sharper turns without slowing down.

chrishamm

This looks really nice! Would you mind if I integrate your analyser in a future web interface version? I think the firmware already provides most of the required values, so that would allow further automatisation. I'd have to redistribute your work under the terms of the GPLv3 though.

Whitewolf

@chrishamm:

This looks really nice! Would you mind if I integrate your analyser in a future web interface version? I think the firmware already provides most of the required values, so that would allow further automatisation. I'd have to redistribute your work under the terms of the GPLv3 though.

He already agreed to do so:

https://www.duet3d.com/forum/thread.php?pid=15574#p15574

Shen

@chrishamm:

This looks really nice! Would you mind if I integrate your analyser in a future web interface version? I think the firmware already provides most of the required values, so that would allow further automatisation. I'd have to redistribute your work under the terms of the GPLv3 though.

I wouldn't mind at all, but currently the code quality is not good enough. I just started refactoring the code.

lignumaqua

Unfortunately this fails for me every time, always with a 'Maximum call stack size exceeded' error. Tried with multiple different gcode files in both Safari and Chrome.

Shen

@lignumaqua:

Unfortunately this fails for me every time, always with a 'Maximum call stack size exceeded' error. Tried with multiple different gcode files in both Safari and Chrome.

Can you provide the gcode files? I have been updating the JavaScript files, if your browser caches the javascript files and one of the JavaScript file is not up to date, you might see that error.

lignumaqua

@Shen:

Can you provide the gcode files? I have been updating the JavaScript files, if your browser caches the javascript files and one of the JavaScript file is not up to date, you might see that error.

I cleared the browser caches, and even tried a completely different browser (Opera this time) but still always get the same error I'm afraid. Line 509 and line 420 of the js look to be recursive in some way: [c]calculateTimeByAcceleration(gcode.nextMovementGcode);[/c]

Here's a sample gcode file https://www.dropbox.com/s/1eyzuovyeoioe0f/ipadmount.gcode?dl=0

Shen

The problem is this line in your gcode:
"G1 S1 X50 Y50 F5000: FRONT LEFT TO HEAT UP"
You used a colon instead of a semi colon. It's a part of your starting gcode that's why none of your file works. I should have used some kind of gcode error handling, but I haven't got a change to work on it yet.

lignumaqua

@Shen:

The problem is this line in your gcode:
"G1 S1 X50 Y50 F5000: FRONT LEFT TO HEAT UP"
You used a colon instead of a semi colon. It's a part of your starting gcode that's why none of your file works. I should have used some kind of gcode error handling, but I haven't got a change to work on it yet.

Well, so I did. Doh! Thank you for spotting that. Page works as expected now. (As you knew it would. :- ) )

Shen

@lignumaqua:

@Shen:

The problem is this line in your gcode:
"G1 S1 X50 Y50 F5000: FRONT LEFT TO HEAT UP"
You used a colon instead of a semi colon. It's a part of your starting gcode that's why none of your file works. I should have used some kind of gcode error handling, but I haven't got a change to work on it yet.

Well, so I did. Doh! Thank you for spotting that. Page works as expected now. (As you knew it would. :- ) )

No problem, I just added some simple error handling code that would prevent problems like that.

lignumaqua

Shen - ran another test today. Your app predicted a print time of 2 hours and 10 seconds. Actual time taken was 2 hours and 14 seconds. Pretty darn good!