# Are Finish/Remaining Time very inaccurate for anyone else **URL:** \ **Category:** Snapmaker2.0 Troubleshooting guides\ **Created:** [November 16, 2021, 9:15pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020 "2021-11-16T21:15:26Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Fenn](https://avatars.discourse-cdn.com/v4/letter/f/c5a1d2/32.png) [@Fenn](https://forum.snapmaker.com/u/Fenn)\ **Post date:** [November 16, 2021, 9:15pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/1 "2021-11-16T21:15:26Z")
For laser engraving I used to think the “Finish Time” an “Remaining Time” were very inaccurate cause I was fine tuning settings mid print but it seems that’s not it. Anyone know why this might be? Does anyone have common settings for laser etching? ---
**Author:** ![brent113](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.snapmaker.com/brent113/32/11114_2.png) [@brent113](https://forum.snapmaker.com/u/brent113)\ **Post date:** [November 16, 2021, 9:17pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/2 "2021-11-16T21:17:50Z")
The time remaining calculation is a naive estimation based on number of lines of code. It is not a full kinematic model of what the program is actually doing. If you need to know a more accurate time estimate use a slicer that takes into account machine kinematics when calculating print time. > **[How to make Cura accurately estimate the print time](http://lokspace.eu/how-to-make-cura-accurately-estimate-the-print-time/)** > > For many users this is all too well-known "issue": Cura says your print will take 15 hours, you hit "Print!", and after 20 hours, it's still f\*\*\*ing printing... News flash: this does not affect only Cura. It affects every slicer to a different extent... These instructions are basically correct except the values need to be extracted from the M503 gcode command instead of the places it lists. ---
**Author:** ![Fenn](https://avatars.discourse-cdn.com/v4/letter/f/c5a1d2/32.png) [@Fenn](https://forum.snapmaker.com/u/Fenn)\ **Post date:** [November 16, 2021, 9:19pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/3 "2021-11-16T21:19:32Z")
> [@brent113](#): > > time remaining calculation is a naive estimation based on number of lines of code. It is not a full kinematic model of what the program is actually doing. > > If you need to know a more accurate time estimate use a slicer that takes into account machine kinematics when calculating print time. ah that’s for 3D printign I mean for laser but thanks for heads up ---
**Author:** ![brent113](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.snapmaker.com/brent113/32/11114_2.png) [@brent113](https://forum.snapmaker.com/u/brent113)\ **Post date:** [November 16, 2021, 9:20pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/4 "2021-11-16T21:20:14Z")
> [@Fenn](#): > > ah that’s for 3D printign I mean for laser but thanks for heads up There’s no difference. For laser the touchscreen uses a naïve estimate based on lines of code remaining. Use a laser software that calculates machine kinematics, like Lightburn. Plug in the M503 values. It’s worth noting that there is a “bug” (really an incredible programming oversight) that drastically increases laser times. If you want to read all about it you can read my PR that would fix it if Snapmaker can ever get around to accepting it > > > This pull request adds a new feature: Laser Inline Power. This greatly enhances …job completion time and quality for many types of jobs. > > This pull request implements a feature from Marlin that was added to Marlin after Snapmaker forked. This addition is based on the work contained in this pull: https://github.com/MarlinFirmware/Marlin/pull/15335. Inline laser power is also a standard feature on GRBL firmware, another common laser cutter firmware. > > \### Summary of New Features > \- Enables optional use of inline power control by using a new I parameter on \`M3\`-\`M5\` in the form of \`M3 Pxx I\` (https://marlinfw.org/docs/gcode/M003.html) > \- Increases compatibility by adding traditional power specified with the 0-255 S parameter in form of \`M3 Sxx\` > \- Adds optional new parameter \`Sxx\` and \`Pxx\` to \`G0\`-\`G3\` movement commands to move with inline laser power specified in the form of \`G1 Yxx Pxx\`. (https://marlinfw.org/docs/gcode/G000-G001.html) > \- A \`G28\` home command disables the laser for enhanced safety. > \- Increases compatibility by adding traditional power specified with the 0-255 S parameter in form of \`M3 Sxx\` > > \### Additional Changes > \- A \`G28\` home command disables the laser for enhanced safety. > \- Modified how the fan and power limits are controlled in \`toolhead\_laser.cpp\` to accommodate calls from within the stepper ISR by not triggering CAN communications within the ISR. > \- Removes handler for unsupported air assist / coolant controls so that they return the standard unknown gcode handler so as to properly communicate to controlling software that air assist is unavailable. > > When not enabling laser inline power the machine behaves the same as previous firmware, with the exception of the change made to \`G28\`. > > \### Description of Laser Inline Power Behavior > When enabled by using the \`I\` parameter laser control is moved into the planner and motion control modules to allow for smooth power changes. > > \*\*First a review of previous laser power control:\*\* > The \`M3\` command first calls \`planner.synchronize();\` which waits for all motion to complete. The machine decelerates and comes to a stop, then the laser power is changes, and then the machine accelerates to continue. Each deceleration/acceleration results in additional dwell that affects the accuracy of dwell timing, resulting in a slightly darker than intended laser burn. This is most pronounced when using continuously variable power in software like Lightburn (Lightburn calls this 'grayscale' mode, which is not dithered). > > \*\*New behavior of laser inline power\*\* > Control of the laser power has been moved into the planner and stepper ISR. The planner adds the requested power onto the motion block. As the blocks are executed in the stepper ISR the laser power is scaled with acceleration trapezoid to eliminate darkening caused by the machine moving at less than the commanded speed with the full laser power. > !\[image\](https://user-images.githubusercontent.com/7025732/137256766-a3f7e4df-7c1a-4672-8c68-fe8c84da3362.png) > > As the laser power is being controlled via the planner the \`planner.synchronize();\` is not necessary which allows the machine to use optimized exit and entry velocities similar to 3D printing. > > \*\*Comparison between old and new behavior\*\* > Here is a sample from a job using grayscale mode from Lightburn without laser inline power. Each concentric circle on the left and vertical line on the right is where the laser power changed, resulting in a pause as the motion came to a stop and resumed. > !\[image\](https://user-images.githubusercontent.com/7025732/137254443-7a224ea0-2bff-4c1b-a137-e5d9faa247bc.png) > > By enabling laser inline power and eliminating harmful motion pauses the job completes approximately 2x faster and is of higher quality. > !\[image\](https://user-images.githubusercontent.com/7025732/137254610-1fed1b8b-1417-4d60-8306-83c929706be4.png) > > When Lightburn or other software is configured to use inline power it generates gcode similar to the following: > \`\`\`text > G1 X0.3 S131.3 > G1 X0.7 S130.1 > G1 X0.1 S129.5 > G1 X0.8 S128.9 > \`\`\` The relevant description is this: **First a review of previous laser power control:** The `M3` command first calls `planner.synchronize();` which waits for all motion to complete. The machine decelerates and comes to a stop, then the laser power is changes, and then the machine accelerates to continue. Each deceleration/acceleration results in additional dwell that affects the accuracy of dwell timing, resulting in a slightly darker than intended laser burn. This is most pronounced when using continuously variable power in software like Lightburn (Lightburn calls this ‘grayscale’ mode, which is not dithered). **New behavior of laser inline power** Control of the laser power has been moved into the planner and stepper ISR. The planner adds the requested power onto the motion block. As the blocks are executed in the stepper ISR the laser power is scaled with acceleration trapezoid to eliminate darkening caused by the machine moving at less than the commanded speed with the full laser power. ---
**Author:** ![clewis](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.snapmaker.com/clewis/32/3255_2.png) [@clewis](https://forum.snapmaker.com/u/clewis)\ **Post date:** [November 16, 2021, 11:10pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/5 "2021-11-16T23:10:16Z")
Technically, the time calculation is a [naive estimation based on bytes](https://forum.snapmaker.com/t/wondering-what-the-progress-on-the-touchscreen-actually-means/20584/2). But most GCode commands are similar length, so there isn’t a lot of practical difference between the two. ---
**Author:** ![brent113](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.snapmaker.com/brent113/32/11114_2.png) [@brent113](https://forum.snapmaker.com/u/brent113)\ **Post date:** [November 16, 2021, 11:18pm UTC](https://forum.snapmaker.com/t/are-finish-remaining-time-very-inaccurate-for-anyone-else/22020/6 "2021-11-16T23:18:24Z")
I do love that. As if there is an assumption that longer lines of gcode=longer to execute. hahahaha. I know it’s because the file pointers are easier to keep track of but that’s less funny.