Build Time correction

[raphaelmerz]

When I compare the build time in S3D with the effective build time theres always a huge difference between them.
But the difference is always about 20% too much in S3D compared with real time.

Please add an option to give a multiplicator for time correction.

Thanks

[arhi]

the multiplicator will not help you 'cause the issue with with acceleration that s3d is not accounting for (since it is handled by firmware) and "max speed" (also in firmware, but much rarely a problem then acceleration and jerk / junction deviation)

[raphaelmerz]

When S3D says 2h my print time is 1h40...
When S3D says 20min my print time is 18min...

In my case always 19-21% so yes! It would work for me.

[Aha]

I WISH it could be reduced to even under 20%. I'm sometimes fighting much, much higher differences!

I tried printing the Fillenium Malcon - S3D suggested just under 6 hours. It took over 16!!!!!

While that's extreme, 20%, 30%, or more deviation at 5+ hours is horrible.

If you need us to look up all the acceleration and jerk settings if we want an accurate time, it may be a pain, but it's not unreasonable to force us to do. Much more reasonable than making us go to some gcode sites to get an accurate timing forcast.

[arhi]

Much more reasonable than making us go to some gcode sites to get an accurate timing forcast.

you can integrate gcodestat and embed M117 into gcode so you get proper time-left report on your printer's display every X% it will just require you save the g-code from the s3d every time so it can be postprocessed

[jmtrappier]

Mine is seriously underestimating the print time...so this is not a fixed 20% issue, at least not for everyone.

[HautKarl]

Much more reasonable than making us go to some gcode sites to get an accurate timing forcast.

you can integrate gcodestat and embed M117 into gcode so you get proper time-left report on your printer's display every X% it will just require you save the g-code from the s3d every time so it can be postprocessed

Hi Arhi-

The argument -s 5 doesn't produce results, so I used --step_frequency 5 which worked.
Also, the results were: 100%, 95%, 89%, 84%, etc. Is this the intended behavior rather than 100%, 95%, 90%, etc?

Thanks for a much needed accurate estimate!
-HK

[arhi]

The argument -s 5 doesn't produce results, so I used --step_frequency 5 which worked.

that's weird ?!

Code: Select all

      {"help", no_argument, NULL, 'h'},
      {"quiet", no_argument, NULL, 'q'},
      {"alert", no_argument, NULL, 'w'},
	   {"gcode", required_argument, NULL, 'g'},
      {"output", required_argument, NULL, 'o'},
      {"config", required_argument, NULL, 'c'},
      {"acceleration", required_argument, NULL, 'a'},
      {"junction_deviation", required_argument, NULL, 'd'},
      {"jerk", required_argument, NULL, 'j'},
      {"heatup_time", required_argument, NULL, 't'},
      {"max_x_speed", required_argument, NULL, 'x'},
      {"max_y_speed", required_argument, NULL, 'y'},
      {"max_z_speed", required_argument, NULL, 'z'},
      {"retract_time", required_argument, NULL, 'r'},
      {"prime_time", required_argument, NULL, 'p'},
      {"percent_step", required_argument, NULL, 's'},
      {"api_url", required_argument, NULL, 'u'},
      {"api_key", required_argument, NULL, 'k'},

it is standard geptopt library, parameter is either s or --percent_step .. the --step_frequency does not exist anywhere in the code

Also, the results were: 100%, 95%, 89%, 84%, etc. Is this the intended behavior rather than 100%, 95%, 90%, etc?

that is expected 'cause I don't want to break a single g-code line, only to insert M117 between existing G-Code lines and the "round" percentages are sometimes "during" a gcode line so you don't get "exact" % numbers there

the way it works is I want to print "status" at XX% when I'm up to that number, I will put M117 after the first G-code line that is finished and will calculate (rounded) at what % I really am. If you have lot of short, fast lines around that "place" you will have "exact, round" % number (95%, 80%, 25%...) but if you have a long slow line that takes a while you'll be few % "more finished" when that long slow line finishes

Thanks for a much needed accurate estimate!

what I would like is for ppl to lemme know how precise these estimates are to what they are seeing in real life. for me, for smoothieware it's on the dot, especially 'cause I do preheat bed and extruder manually before I start to print (as I have to cover the bed with insulator for it to reach high temperatures in real time and then manually remove that insulator before printing) so I can compare real print time from the octoprint statistic..
on the other hand, many ppl use repetier or marlin or klipper, replicape, that duo garbage.. and for them only acceleration calculation works properly, the jerk is not so some small discrepancies should happen but I'd like to know how big they are .. is it inside 0.5% as I expect or it's more