A website tool estimates print time accurately based on speed/acceleration/jerk

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. Also let me know if you'd like to see any other statistics being added.
screenshoot

Thank you for doing this - this will help me choose, as you said, most optimal value for jerk and acceleration. The website worked for me with a small file but 40MB file failed probably because it takes too long to upload.

PS.: have you considered implementing retraction option? I would think that retraction would have quite large effect on total print speed.

Edited 1 time(s). Last edit at 05/30/2017 11:30AM by newbob.

The software process everything locally, it doesn't upload your gcode. Since code is not optimized yet, it might take a long time for larger files. Surprisingly I found Microsoft Edge to be significantly faster than Chrome, you can try different browser if one fails.
I already have Retraction Count and Total Retract/Prime Time, is that what you relate to?

I tried IE and it just keeps the button beveled for a while than nothing happens, chrome just says the page has crashed and should be reloaded. As to my retraction question - jerk and speed for E axis would yield different total speed result depending on retraction length as, example, retraction of 4mm vs 1mm for every nozzle travel longer than x.

Making the program work faster is definitely high on my priority list. I'm working on optimizing memory usage, and adding multi-threading for the calculations. I think you just need to slice the model twice with both settings and compare the print time or time spent on retractions.

I've done some optimizations, the program should work much better on large files now.

Success - this time I got a result:

G-Code Statistics
Number of Lines
1294732

Print Time
04:09:47

Time Spent Accelerating/Decelerating
00:17:45 (7.1%)

Time Spent at Target Speed
03:52:01 (92.9%)

Total Move Commands (G0 & G1)
1292378

Move Commands Reached Target Speed
1241814 (96.1%)

Print Move / Travel Move
1216995 (94.2%) / 75383 (5.8%)

Total Distance Moved
797.84 m

Print / Travel Move Distance
602.59 m (75.5%) / 195.24 m (24.5%)

Average Speed
53.2 mm/s

Z Hop Count
0

Total Z Hop Time
00:00:00

Retraction Count
1020.5

Total Retract/Prime Time
00:05:31

Filament Usage
19.77 m

I'm glad it works for your large file now. My next step is to add a progress bar and make it multi-thread to further improve the speed.

After more testing I noticed that the App does not give results when Jerk value for E axis (I have not tested others) equals 0.

Thanks for letting me know. That's fixed now.

Can your tool read Slic3r or Cura configuration files? That would be a lot more convenient than having to go find the

The program already reads all relevant commands from the gcode. What you need to fill in is the max speed, acceleration and jerk settings of your printer, I don't think those are a part of the slic3r or cura configuration file. If you are controlling the acceleration inside the slicer, the acceleration change will be done by gcode commands, those command will be captured and process by the program.

Quote
Shen
The program already reads all relevant commands from the gcode. What you need to fill in is the max speed, acceleration and jerk settings of your printer, I don't think those are a part of the slic3r or cura configuration file. If you are controlling the acceleration inside the slicer, the acceleration change will be done by gcode commands, those command will be captured and process by the program.

Maybe a note up the top explain that these values are from the firmware or EEPROM settings to solve any confusion. When I first read the post i was going to flag that these values are taking from the firmware, till I saw that you have already accounted for that.

I'm planing to add those question mark beside the entries which you can mouse over and get more information.