S3D Print Time not Correct

[insta]

my print time estimates come from pronterface, and when I see the estimate, I just double it. for the same reasons stated above. The gcode demands that your printer makes a specific move, and then the firmware calculates how to make that move, making estimates a crapshoot.

Now it would be nice if you could clone your firmware to your slicer software and it emulate a print to figure out the time...but maybe were just not there yet.

One of the host softwares did that. They ported Marlin ...

[innkeeper]

i've never had a print estimate ever be consistently accurate with any software... i use them as a relative numbers and estimate based upon previous relative timings of other similar prints on the same combination of printer and software.

[Rara]

Wowwww...you aren't kidding. Until now I've noticed things taking longer than estimated, but I just loaded up a big job...estimate was 22:08. I am currently 38 hours and change, and am in the neighborhood of 60% or so done. If this is a universal problem with printing software, why is this such a hard thing to get even remotely close to accurate? I'm not a programmer/coder; just genuinely curious (and baffled). I mean, even +/- 20% accuracy would be incredibly helpful...had I known this would literally take a week to print I would have just bought what I am printing!

[jsc]

Here's a simple explanation. The gcode says to move from 0 to 200 at 200 mm/s. So the host says "that should take 1 second" and that's what goes into the print time estimate. But the firmware says, well, you can't go from 0 to 200 mm/s instantaneously, that would cause the stepper to skip, so we have to accelerate up to that speed. Then we have to slow down gradually as well so we don't slam to a stop at the end, which will also cause skipped steps. So now it takes somewhat longer than 1s. But how much longer depends on the firmware settings: what change in velocity is considered acceptable to jump to without acceleration (so called MAX_JERK), and how much acceleration is being used. And there is no way to know what those values are, as they will be different between firmware implementations, firmware builds, and even user adjustable. Oh, and plus the firmware is looking at what happened before and after this segment, because maybe it doesn't have to start or stop at a dead stop; if the segment before was coming in with some velocity, it's not going to bring that one to a stand still, it will blend the velocities together.

Say you're at a drag strip in a car that can max out at 100 mph. According to the time estimator, you can do the quarter mile in 9s because it doesn't consider the time it takes to get up to that speed. But according to the firmware you're in a Honda Civic and there's no way it's a 9s car. And you may or may not be allowed a rolling start, and there may or may not be a brick wall at the finish line....

[jsc]

I just found this: https://github.com/davr/Marlin/tree/estimate

It's a branch of Marlin that just does a dry run through your gcode and spits out how long it would take. It should be extremely accurate. I managed to build it on a Mac. Here it is, you should be able to run it if your version of OS X is up to date. Generally, I advise against running random programs downloaded off the internet, but you can trust me https://dl.dropboxusercontent.com/u/384 ... _estimator

Steps to DIY:

1. git clone https://github.com/davr/Marlin.git
2. cd Marlin
3. git checkout estimate
4. edit Makefile.calc to remove -static everywhere (no static builds on OS X any more)
5. edit Configuration.h for DEFAULT_MAX_ACCELERATION (4000 for X and Y), DEFAULT_ACCELERATION (2000), and DEFAULT_XYJERK (8)
6. make -f Makefile.calc

I don't have Windows build tools, but perhaps someone who does can build a binary?

[Bratag]

Here's a simple explanation. The gcode says to move from 0 to 200 at 200 mm/s. So the host says "that should take 1 second" and that's what goes into the print time estimate. But the firmware says, well, you can't go from 0 to 200 mm/s instantaneously, that would cause the stepper to skip, so we have to accelerate up to that speed. Then we have to slow down gradually as well so we don't slam to a stop at the end, which will also cause skipped steps. So now it takes somewhat longer than 1s. But how much longer depends on the firmware settings: what change in velocity is considered acceptable to jump to without acceleration (so called MAX_JERK), and how much acceleration is being used. And there is no way to know what those values are, as they will be different between firmware implementations, firmware builds, and even user adjustable. Oh, and plus the firmware is looking at what happened before and after this segment, because maybe it doesn't have to start or stop at a dead stop; if the segment before was coming in with some velocity, it's not going to bring that one to a stand still, it will blend the velocities together.

Say you're at a drag strip in a car that can max out at 100 mph. According to the time estimator, you can do the quarter mile in 9s because it doesn't consider the time it takes to get up to that speed. But according to the firmware you're in a Honda Civic and there's no way it's a 9s car. And you may or may not be allowed a rolling start, and there may or may not be a brick wall at the finish line....

That's a great explanation. With that being said it should be possible to come up with a ballpark equation that we could plug some numbers into in order to get a better idea of the actual time. My rule of thumb is +30%. If the print time says 120 minutes I assume its going to be close to 160 ish. Its reasonably accurate for my print settings for PETG.

[Rara]

Ah, that makes sense, I didn't know the G-code and settings for things like acceleration, etc, were separate entities. It makes more sense now. I wonder how the time accumulates though, as I think I am guessing this job will take about 300% of the estimated time. I'm running the "community approved" PET-G settings with the reduced speed/acceleration..but I am printing out 8 copies of the same part as well.

[jsc]

The time accumulates because each segment is taking longer than expected. OctoPrint, for one, tries to adjust for that dynamically.

Upload your g-code (if you like) and I can run the time estimator for you. I'm thinking of putting together a simple web service people can use to test it out.

[Rara]

The file is too big to attach unfortunately (still 15mb zipped!)...I started about 9:00 Sunday night and it's looking like it might another 8-10 hours.

I am running Windows though and am not much of a coder/programmer so that web interface does sound pretty nice right about now.

[jsc]

You can give it a try at http://jinschoi.duckdns.org:4567/

I don't guarantee that it will be up, but if you do give it a shot, let me know how accurate it is. It is compiled using the parameters I outlined below, so if your firmware has some different defaults, it may not be perfectly accurate. Also, it doesn't take into account the time for bed/extruder warmup.