I've been using Cura for slicing and it does use G0 for rapid moves and G1 for printing moves. It would be nice to have the option to skip the G0 moves in the FeedRate display. That of course won't work for everyones slicer.
Edit: Trying it right now. I see that you can configure what is displayed in the bar. NICE. Looks good so far. Now, I had some ideas on how to get it closer in sync with the actual print. Maybe just estimate the lag and delay the display change to sync with the printer?
Yeah, you could potentially do something with buffers and be like "ok the printer will be x number of moves ahead so I'll wait until then to display the value" but every slicer is different (G1/G0) and every printer is different. Some may use arduino's with small buffers, some might use 32bit boards that somehow buffer the entire print.
I don't know how the gcode viewer does what it does, and even whether it does it intentionally, I was under the impression it too lagged behind. Maybe @foosel has some secret voodoo going on that slightly buffers the display?
Since @OllisGit seems willing to integrate the feedrate into their plugin, I'll discontinue my efforts, there's no point in having 2 plugins that do the same thing and their plugin offers more information.
@OllisGit one suggestion from me though is to make the feedrate display optional, people using the navbar temp plugin + yours are going to have quite a busy navbar and not everyone wants or needs to see that feedrate.
I believe the way it is configurable, you can omit whatever you don't want to use.
Maybe its just that the GCODE viewer takes a little time to generate the graphics and it's just chance that they appear to be in sync.
oh ok, I didn't try the feedrate branch. Also I'm only testing this on the virtual printer so I can't really tell how far ahead or behind the printer is from the displayed value.
The trouble with estimating the lag is the printer will execute different moves at different speeds, as far as I know there's no real (easy) way to emulate the printer's movements in a few lines of javascript. If someone else wants to do it then that's up to them. I don't know how you'd sync it up without having some sort of 2 way communication where the printer actually tells you which move it's currently doing. I'm not that smart.
To figure out how long the printer would take to make a move x mm long, at y speed, you'd also have to know the acceleration value for that axis and whether the axis will reach its top speed, how fast it reaches it, how slowly it decelerates, etc. You can't just go "for x mm long at y speed it'll take 5 seconds", that's why the print time estimator can be minutes off, or days off if your printer uses a stupidly low acceleration value. Your printer might not actually ever reach the speed it was set to, it might only reach 1/100th of that speed, or it might reach the full speed.
Math is hard. Too hard for me.
@PythonAteMyPerl short notice: the output is customizible by the user. the user could define which value (progress, layercount, feedrate, ...) is send to the navbar/printerdisplay also with additional text like feedrate-unit.
@PythonAteMyPerl thanks for the inital implementation, I will take over the feedrate-feature to my master branch so it will be available in the next offical release.
@Tone if you have any issue with the plugin or need more information in the navBar (e.g. fanspeed, temperature, ...) please create a issue on the github-page of the plugin.
BR
Olli
From watching the printer, the camera, and the GCode Viewer in various combinations I believe the viewer is just slightly ahead of the printer because it is synced to what is sent to the printer, not what the printer is actually printing. A small firmware buffer and they are pretty close, a large firmware buffer and the viewer is farther ahead. My RPi camera can't keep up with the printer so it is always behind (which I could reduce by using a lower resolution).
Understood. You definitely don’t want to try and calculate where is should be. I was just thinking that lag is probably some value in seconds on average and if the user could just tweak that to suit their particular setup that “on average” it would be a lot closer than without a lag offset.
Sorry for straining at a gnat here. My mind just loves to try and solve hard problems as a matter of exercise!
No secret voodoo, but maybe rate limiting. Updates to the frontend are restricted to "twice per second", otherwise a print with lots of moves could quickly overwhelm the network interface. The GCODE viewer gets synched by progress. On my own prints especially on long straight moves I see it "run ahead" due to this a ton of time. But it all depends on the printed model, the buffer sizes (yes, plural) inside the printer and so on if you can actually see this latency in the viewer or not.
fyi: the new version 1.7.0 of https://github.com/OllisGit/OctoPrint-DisplayLayerProgress is out now.
It is now possible to put "feedrate (g0/g1)" and "fanspeed" to the navbar or printer-display.
Just went into the documentation of marlin and saw that you can also read out the M220 value with M220...
So now it is possible to read out the feedrate overide, can we have a feature where you see the feedrate in the control tab? (or is there already a plugin for that...?!)
(same for M221, but then I have to ask the marlin community to make a read out for that as well...)
cheers / joris
I distinctly remember having that discussion on GitHub a while back, and while you can query it on certain versions of Marlin, there currently is no way to figure out IF you can, and sending an M220 without a parameter could have very bad side effects on various firmware out there.
So, this needs to be added to the capability report that's part of the M115 response, and THEN, yes, we can look into this.
edit Found it:
There is a way - check the Marlin version.
#if HAS_EXTRUDERS for Marlin 2.0.0 and later. 52c024eFrom my experience the version number as reported in M115 isn't dependable, at least not with Marlin. Too many vendors messing around with stuff they often don't even understand, without ever adjusting the version number.
So, this really needs to be put into a capability report. That's what they are for. Guessing functionality based on version number when it comes to firmware is just a way to tears.