Show Time Remaining / Passes Remaining

[cojarbi]

We have in LW3 an estimated time the operation will take. It could be very useful to have this but to go a little further show a live counter with relevant information

• Time passed / total time ( laser and router )
• Current pass / Total passes ( for laser )

[iceblu3710]

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.

[iceblu3710]

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.

[cprezzi]

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.

[cprezzi]

@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?

[ghost]

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

[ghost]

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

[tbfleming]

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

[cprezzi]

Job stats from LW3 are back:

[cprezzi]

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).

[ghost]

I like that plan. Just like 'windows time' it can change through the job too. 2 hours from done. 5 min. 3 day. -2 seconds. 5 min lol

On Feb 24, 2017 9:25 PM, "Claudio Prezzi" [email protected] wrote:

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).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/110#issuecomment-282381282, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2ysR8b9CotbUwa6yqsODxdKXwvZ3ks5rfy6agaJpZM4LXRHj .

[cprezzi]

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

[cojarbi]

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?

[cprezzi]

@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?

[cojarbi]

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

[cprezzi]

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?

[jorgerobles]

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

[tbfleming]

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.

[jorgerobles]

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

[tbfleming]

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

[jorgerobles]

Opps, My fault (jumbled comment marks.)

[ghost]

https://github.com/hudbrog/gCodeViewer was the original viewer, reworked first by John lauer to add G2/G3 parsing. Then reworked by Andrew Hodel to simplify, then reworked by me to add the laserweb grid, and the S value opacity. Then reworked by Håkan Båstedt to use Buffer Geometry for lower memory. So i wouldnt say go all the way back then. The parser we had in lw3 was plenty much better than its forefather (;

On Mar 21, 2017 10:38 PM, "Todd Fleming" [email protected] wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/110#issuecomment-288210895, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr26NDJ3SiK9LFedFcwRlXmI-bVGuQks5roDU8gaJpZM4LXRHj .

[jorgerobles]

Ok then. Will check for gcode time estimation :)

[jonbev]

@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?

[jorgerobles]

@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

[ghost]

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

[tbfleming]

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

[cprezzi]

@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.

[cprezzi]

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?

[jorgerobles]

@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

[tbfleming]

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.