While waiting for the SPJS to be smarter so we can get real ETA,

While waiting for the SPJS to be smarter so we can get real ETA, I have been thinking about approximating ETA. I notice that Gcode widget has all the gcode, it should be able to approximate the amount of unit it has to move and show a percentage.

G0 and G1 are straight, D(nextPosition - currentPosition) / feed rate would give a feed-less measurement of how much we are progressing. G2 and G3 can be approximated by the same way.

Would this be a good thing to be implemented on the gcode widget? Or should it be in the TinyG/Grbl widget since we eventually will have better gcode line positioning and thus get much more accurate ETA that way.

Did u get your TinyG?

Yes I did. :slight_smile: I am holding it in my hot little hands. I am going to 3d printing a mount for it on my machine.

I don’t think Serial Port JSON Server is the place to get ETA’s from. SPJS is just a dumb buffering program that speaks websockets on one end and serial port on the other end. The key for ETA is the Gcode Widget and/or 3D Viewer Widget. The 3D Viewer widget is the only widget that parses the Gcode. In that process it could determine feedrates on each line. It should so the simulator runs at the actual speed. Then it could do the best calculation.

What i meant is to have SPJS reporting its current processed gcode line via an offline id. With that ability, we would be able to make accurate forecast once all the parsing has been done by either the gcode or the 3d widget.

Well, if you look at the latest github checkin for SPJS it’s getting close. The implementation will look something like this wiki entry https://github.com/johnlauer/serial-port-json-server/wiki

I assume there will be a new signal for the serial port widget that updates the gcode line and current position?

Yeah. There will be an onQueue, onWrite, onComplete. What i’m finding though is the onComplete comes back quicker than the onWrite so I may just eliminate that event as its somewhat useless, but it depends on the Gcode, so maybe it’s worth keeping. I’m trying to get an onExecuted as well. The onExecuted would be when the line of Gcode is fully done executing. It’s turning out to be really hard to determine this as neither TinyG or Grbl give a msg when the line is done executing so you have to infer it.