This might be a dumb question but,

(Jason Gullickson) #1

This might be a dumb question but, why doesn’t Printrun produce exact printing time predictions? Seems like the gcode should be able to tell it everything it needs to know to know exactly how long the job should take, but maybe I’m overlooking something?

I have a simular question about Slic3r’s estimate of filament meters?

(Marcus Wolschon) #2

One word: Acceleration.

(Jason Gullickson) #3

Ah-ha! Thank-you @Marcus_Wolschon

(Jason Gullickson) #4

Ah that makes sense too @John_Ridley (nice to see you in the group btw, your blog has helped me immensely!)

(Whosawhatsis) #5

I don’t think printrun even attempts to calculate print duration that way, at least not for the real-time “hh:mm:ss remaining” display. I’m pretty sure this estimate is done by calculating the the average time per line of gcode and multiplying by the number of lines remaining, probably using some kind of running average of the last 100 lines, or perhaps something weighted.

Repetier host seems to do its time remaining estimations in the way you suggest, and those estimates are chronically optimistic for this reason. There is a preference that allows you to add X% to this estimate to try to make it more accurate, but that will depend on the speed/acceleration settings in the firmware, the feed rates set in your slicer, and the size of and angles between the facets in your model, which determine how close to maximum speed you are able to accelerate while printing them.

(Billy) #6

KISSlicer recentely added the option to enter an XY acceleration value and the time estimates are now MUCH better.

(Taylor Alexander) #7

These softwares should be able to get exact times of they know how your firmware calculates acceleration (and since the firmwares are open source - they could know that). But print time is rigidly determined by the microcontroller on the printer (if it wasn’t, you see lost steps) so one should be able to nearly exactly calculate print times. But no one seems to do that.

(Jason Gullickson) #8

Sounds a lot harder than its worth :). For me it was just a curiosity (although knowing the amount of filament needed would be more important when deciding if I’ll have enough loaded up to complete a job).

Sounds like the firmware knows best, I haven’t played with what Marlin can display while printing (picked up an LCD but haven’t wired it up yet), does it provide any feedback like this or is it just basic status information?

(Taylor Alexander) #9

I’m not sure how you surmise that its not worth it. Once the code is implemented it would happen in less than a second on any decent computer, and the code itself probably isn’t very complex to someone who has poked around in those programs’ source before. So a bit of work for much improved information? Might be worth it to somebody.

(Taylor Alexander) #10

Ah, yeah I meant on the PC. But the PC could save that in the gcode’s header for the arduino to spit back out. I was suggesting taking the arduino’s implementation of gcode interpretation and running that on a PC to calculate the run time exactly.

(Taylor Alexander) #11

Pronterface can poll those values from the printer. Plus most people likely print to just one printer.

Sometimes I just go to sleep, but sometimes I’m waiting for a print to finish and knowing exactly when it would finish would be handy. Rarely is more information not helpful.

(Jonathan “se5a” Sorensen) #12

yeah it would be calculated from pronterface. I think there’s gcodes to get the acel and top speed settings in the firmware? if not, it could be very easily added. (hell I added the M93 get current steps to sprinter - as my first ever arduino project even)

(Taylor Alexander) #13

Yeah, there’s gcodes to pull all the printer’s settings.