for example a 10 min print takes 18 mins a scan which should take 5 mins takes 11 mins! i need help
If you find a bug, it is best to report it directly through the Flux Help Center support. The forums are for discussing things, but are not the best channels for reporting bugs.
The best workaround I can give you is to have patience.
i can have patience but not wrong timings anyway, thanks for the help! ill submit the bug…
Timing for 3D printing was never 100% accurate from day 1, each new version of FS changed it sometime for the good, sometimes for the bad! Lately the Cura engine can be off target by a big amount depending on the complexity of prints.
Welcome to the club. 3D Printing timing is never accurate… have yet to hear someone say for any printer or software that they have near accurate timing… but Flux Studio has at times been pretty good… but seems to have slipped again lately. Why, I can’t say… because I haven’t tried to make my own I haven’t had to come to grips with all the variables, and as such, don’t know what is making it so hard. But it must be… as I would have thought somebody would have worked it out by now… surely it’s just maths!
What’s probably going on is a difference in acceleration and jerk settings between the slicer and the machine’s firmware. The print head doesn’t move at a constant rate, the speed that you tell it to print at is actually just the maximum ‘speed limit’. Acceleration is exactly what it sounds like, and jerk is the instantaneous speed change that’s allowable, instantly jumping from 0 to 40mm/s for example… The slicer will assume a value for both of these settings when it calculates the printing time, but how your printer handles the GCode can vary based on the firmware that you have loaded. I’d bet money that this is what’s mismatched, and causing the discrepancy.
For example, the slicer may tell the print head to speed up to 60 in 1 second, but if your firmware’s jerk is 40 and accel is 10, it would actually take 2 seconds to reach 60 (40 instantly, plus 2 seconds of acceleration). Do that times a couple hundred infill and perimeter lines, and you’re off by several minutes.
Very good description Jim. I was scratching my head for a while over why there were time gaps when loading external gcode from S3D or Prusa Slic3r too and basically came up with the same conclusion, but you’ve explained it much better.
There’s always a difference of a few minutes between what one slicer estimates and what FS says. And even FS if you use only FS will often finish a print at 94 or 95%. So yes, those times are estimates at best, and I’m not sure without getting into some serious fine-tuning (that I don’t know if we could even do on FLUX) that it would change.
Meh, if it’s printing good, what’s a few minutes one way or the other. It just means I can watch another layer