The total time metrics are definitely the most useful as I currently keep a log of my 40W's tube hours so I know when I need to start saving for a replacement.

I imagine the GCODE could be parsed for line segments and every F change sum up the previous path and divide by that mm/min.

The downside is that would be a TON of Math.sqrt calls and I suspect something like a Raspberry Pi may freak out.

Just had a though. The Shoe Laser selection is a canvas context. You could count all the green pixels and then apply the average feed rate that dpi. Would be waaaay faster and probably accurate enough for a guesstimate time.

I do already have "some" job metrics on server side:

Job started at Fri Feb 24 2017 18:24:26 GMT 0100 (Mitteleuropäische Zeit)
Job finished at Fri Feb 24 2017 18:30:27 GMT 0100 (Mitteleuropäische Zeit)
Elapsed time: 361 seconds.
Ave. Speed: 333 lines/s

It should be possible to save a usage summary on server side, and let the client query it.

@cojarbi Where do we have an estimated time (preview) for the job duration in LW3? I only see a distance esimation.

• It's not so eays to estimate how long a job will run out of gcode (especially when using feed overrides).
• The time passed / total time would not be a problem, I could add that.
• For current pass / total passes I could only guess that a change in z-axes is a new pass, but that's not a clear sign. Isn't it enough to see the z position?

We had it in LW2 - but with that big refactoring on the parser to increase its performance, it stopped working. Some of the code still exists though.

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L756-L774

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L788-L790

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L773 was actually quite accurate (;

LW4's gcode preview uses an acceleration-less approximation for the slider.

Job stats from LW3 are back:

I have an idea for the duration estimation, at least while the job is running.
I could count how many queue lines was processed over a period (like 5s) and calculate the rest duration (ETA: like file transfer dialog from Windows).

Right, could jump around but people are used to it from Windows ;)

Thanks guys. The passes count would be more related to laser diode mostly as currently if I'm not mistaken enabling Z stage will rub a pass on all vectors and then change Z, socould that be a trigger?

@cojarbi Yes, that could be a trigger, but what if there is no Z change? Most Laser cutters don't have a Z-stage.
The gcode generator could place a command into the code to tell me when a new pass starts? And probably at the start, how many passes to expect?

We have now a Z stage enable button and we need to select amount of passes , so if passes > 1 then start counting ??

I would't use Z-moves for that, as this would not work on milling. It should be very easy to add a comment line to the gcode when a new pass starts.
@tbfleming @lautr3k What do you think?

https://github.com/hudbrog/gCodeViewer has a worker we could use (CC-A-4.0)

We could add special comments to gcode generation to mark each operation and mark each pass. The sender could report back when it hits each one.

@tbfleming I like the idea :)
"#: Pass 1" ?

Comments are either ; blah or (blah): http://linuxcnc.org/docs/html/gcode/overview.html#gcode:comments

Maybe ; Operation: 3/4 Pass: 7/9

I prefer counting starts at 0; a single-operation single-pass file would have just a single marker: ; Operation: 0/1 Pass: 0/1

Opps, My fault (jumbled comment marks.)

Ok then. Will check for gcode time estimation :)

@cprezzi noticed yesterday that if the last operation is a long one (in my case a rectangle that took about 2 mins to cut) the finished time is output at the time the operation is sent to the machine and not when it has finished. Anything you can do about that?

@openhardwarecoza the LW3 parser does much more than estimating time maybe a leaner one purpose code, like https://github.com/cncjs/gcode-parser could help

Agreed, was just giving the history lesson as to where gcode.ws already did fit in (:

The temp parser doesn't do a lot; hopefully the replacement permanent parser also won't do a lot.

@jonbev At the moment, the job is "finished" when the last line has been accepted by the controller. At this time, the controller planner queue still has some commands to execute (max. 16 for Grbl or 32 for Smoothie). Unfortunatelly there is no event from the controller after a command has been executed.

It would probably be possible to wait until no moves are detected for a certain period, but that would be guesswork.

I see two things of interest. First the estimated duration in the CAM tab and second the job progress in JOG.
Instead of showing the queue length aboove the DRO, I could show a progress bar of % queue position.

By the way: Wouldn't MACHINE or OPERATE be better names than JOG?

@tbfleming please take a look to https://github.com/cncjs/gcode-toolpath Seems quality code regarding parsing.
BTW, What does the tmpParser lacks of? I've seen a nice implementation of G2/G3 on https://github.com/cncjs/cncjs/blob/master/src/web/widgets/Visualizer/GCodeVisualizer.js

It looks like they made a fundamental error: they treat G numbers as strings. e.g. it will mishandle "G0.0", which is the same as "G0". I doubt any cam would generate "G0.0", but that kind of mistake makes me uneasy.

The temp parser only supports the tiny gcode subset that the rasterizer and path cam generates. It's missing G2/G3, inch mode, canned cycles, work coordinate systems (would be a major PITA to show graphically), and probably more.

Here's where it accepts G0 but not G0.0: https://github.com/cncjs/gcode-toolpath/blob/master/src/index.js#L41

What would be a good timing algorithm?
I'm not trying to replicate the 18 steps planner of @chamnit, only get a nice ballpark (Improving @openhardwarecoza 's Factor 1.32 😄 ), without getting mudded.

For each former line:

• Calculate the time of each axis movement

  1. Calculate entering acceleration time (using entering speed), and then its distance (using average speed)
  2. Calculate the time of the remaining distance at F
  3. Calculate exiting acceleration time (picking actual speed). Apply a ballpark junction time factor.

• Accumulate the longest time of all the moved axis

• Latest command should compute latest line.

..anyone...?

You've entered the realm of firmware-specific wild guessing. The only way to know which techniques produce reasonable approximations is to run a very large number of experiments covering a wide range of gcode files in combination with a wide range of firmware settings.

😄 I did plan to name the function guesstimate.
Including a huge ballpark, the accuracy should be enough to tell if the job is about 1 hour, or 2, etc.Even with 3d printers, an accuracy of 85% is enough.
Did you see any awful error in the algorithm? Not speaking of the Joint factor...

I don't see anything obvious, but I'm not sure what your steps mean.

Interesting use of LaserWeb2 code: http://dangerousprototypes.com/store/lasercut
I got that link from someone who asked me if we could do something like that for his website.

Reviewing this thread I almost forgot the guesstimator I made. I've got an epiphany right now, we could implement a deviation factor though using own user gcode. Kind of learning the machine deviation from several works. Will be ballparking anyways, but maybe more precise.