A website estimates print time accurately from speed/acceleration/jerk
-
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.
-
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.
-
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.
-
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:
-
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.
-
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.
-
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.
-
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
-
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. -
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. :- ) )
-
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.
-
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!
-
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!
Good to know. The actual time always seems 5% slower than the predicted time. So I applied a 1.05 factor to the time estimation, the result became very accurate after that.
-
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!
Good to know. The actual time always seems 5% slower than the predicted time. So I applied a 1.05 factor to the time estimation, the result became very accurate after that.
Cant wait to see this integrated into the web interface. This with a realtime gcode visualizer will bring it up to par with Simplify3D
-
Great work. Always wondered why the slicers didn't implement a feature like this. Having this in the interface would be awesome. I'd love to see a estimated column in the files section so I can have a quick look to see how long time it would use to print a certain item.
-
Great work. Always wondered why the slicers didn't implement a feature like this. Having this in the interface would be awesome. I'd love to see a estimated column in the files section so I can have a quick look to see how long time it would use to print a certain item.
that is a great idea +1
-
yes, the idea is great, but…
everytime you go into the files folder the duet has to transfer the complete gcode to the web interface, so that it can calculate and display the estimated print time. If you have several large (>10MB) files, it can take some time. Are you sure, you will wait every time several 10s of seconds for the page to load?I think a button for every file you can click and the print time will be calculated and displayed in the column will be better,
All things have pros and cons.
-
I have it in mind to have the firmware run gcode files in simulation mode when the printer is otherwise idle, so that it can build up a database of how long each file will take to print. But that won't happen until I have converted the firmware to use an RTOS, which in turn means that it won't be implemented for the Duet 0.6 or 0.8.5.
DWC already maintains a cache of data about gcode files on the SD card. So a facility whereby you can ask DWC for a print time estimate and it runs this program to generate one would work quite well, because the result could be added to the cached file information.
-
Just checking this (the page is awesome!) I'm not quite sure about what parameter goes where…
Maximum Speed: M203 ; Set maximum speeds (mm/min)
Print Acceleration: M201 ; Set accelerations (mm/s^2)
Travel Acceleration: M201 ; Set accelerations (mm/s^2)
Jerk: M566 maybe??Can someone confirm?
Regards
-
Just checking this (the page is awesome!) I'm not quite sure about what parameter goes where…
Maximum Speed: M203 ; Set maximum speeds (mm/min)
Print Acceleration: M201 ; Set accelerations (mm/s^2)
Travel Acceleration: M201 ; Set accelerations (mm/s^2)
Jerk: M566 maybe??Can someone confirm?
Regards
Indeed.
I tested this calculator for several models I printed, with print time from 30[min] to 4[hours] depending on the model, and the results were very accurate, within +-1[min] which could be the time of hotend heating.
So, thanks for the great tool.
I hope it will be implemented in DWC.
