A website estimates print time accurately from speed/acceleration/jerk
-
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.
-
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.
-
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 -
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 fasterThanks 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.
-
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. -
I've been meaning to ask – why are the units for jerk expressed in mm/s? Shouldn't it be mm/s^3?
-
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
