I'd like to see the current feed rate in the Status panel. The preference for this plug-in would let you select the preferred units to display. Maybe even the option for dual units.
1 Like
That would assume the printer told you what the feedrate was. Most printers don't output that as any sort of status, and if changed from the LCD panel on the printer, OctoPrint might not know it was changed.
Repetier firmware does output it as a message when changed (99% sure it does), but as far as I'm aware you can't actively query it like you can with temperatures, so if you refreshed the page or open a new browser session, the value would be lost. You could save the last known value and display that, but it could end up being inaccurate.
For something like this to happen, the firmware would need to output more info as part of its status updates, perhaps extending M105 to include feed / flow rates.
Can’t you just watch the GCODE being sent to the controller and display that?
No because:
It's the same situation with the selected tool, the fan speed and the feedrate and flowrate modifiers. The minute I build this in by just monitoring the stuff sent to the printer, you can bet on someone opening a ticket "It doesn't work when I modify this stuff from my printer's controller" and loads of people getting confused by this and chiming in with "I ran into the same problem, please fix"
1 Like
How does the Control tab modify the feed rate? Is that a firmware supported feature?
It sends a GCODE command implemented by the firmware that modifies the feedrate modifier. However, that command doesn't return the current modified value (at least not on non-Repetier-firmwares) and there's no way to query it as well.
I personally wouldn't mind if it wasn't the modified rate. It could just say "Programed Rate:"
Of course others might be more particular. Sounds like it's not an easy thing to do.
Is it possible to do a Terminal type filter that shows what Feed Rates are being sent?
Don't confuse feed rate with feed rate modifier or speed factor override percentage (and extrude factor override percentage).
One is determined by your GCODE (that's the F parameters attached to a whole lot of G0 and G1 commands, can change a whole lot during the course of a print). It usually doesn't make sense to manually modify that. That's not what the slider in OctoPrint modifies however, it sends M220 commands to set the override factor, in short a factor applied by the firmware to those F values. If you set it to 110 for example you increase the feedrate by 10%, if you set it to 90 you decrease it to 90%. That's the same modifier that you can also influence when you turn up the speed through your printer's LCD controller.
If you want to limit the terminal to that you'd need to filter out everything that isn't Send: M220.*. A plugin could also log this stuff on the UI in some way.
Do you actually, really, truly, madly, deeply, mean feedrate? As in, G1 F2000 <-- that number there? If so, monitoring the terminal is about the only way you'll ever get that number.
Any plugin will lag slightly behind the printer though, once gcode is sent to the printer it enters the printer's buffer and so will be executed some-time-later™
Or do you mean the feed rate modifier number that the control tab sends? That number modifies the speeds the printer executes (octoprint still sends the original speeds, the printer modifies it internally based on the multiplier).
Or do you mean a combination of both? Do you want to display the absolute feedrate (mm/s or mm/min) * feedrate multiplier?
I understand the difference. Ideally you would want the absolute rate but it doesn't sound like the firmware is designed to spit that out. I forgot that there is a lag between what GCODE is sent vs what is currently being executed. I suppose that varies from machine to machine depending on how big a buffer it has.
Does the Terminal echo what is currently being executed? I seem to recall that there are some PlugIn's that monitor the Terminal for desired content.
I did a thing https://github.com/ntoff/OctoPrint-FeedRate test the thing
It puts the last sent feedrate into the navbar, the units will display whatever you tell it to (or should anyway).
You'll have to install manually since it's not registered (yet)
Does the Terminal echo what is currently being executed?
some firmwares have a debug flag that tells them to echo back commands, and one in particular has a compile time flag that tells it to echo back when executed, so if your firmware is A) one of the ones that can echo back and B) has the flag set to echo on execution rather than receive, then yes, otherwise (99% of the time) no, the terminal shows only what is being sent TO the printer.
My printer (SnapMaker) uses some flavor of Marlin.
I'll give your test a try tonight.
I should also mention it updates in real time so how fast / often the number changes will depend on how often the feedrate gets sent to the printer. It might stay on one value forever or if it's like my gcode, it'll change so rapidly as to be utterly useless (which realistically this number is useless to a human during a print, more useful during manual control)
Works. Yup, it does change fast depending on what is happening. I could see that there was a lag from what it was displaying to when it actually was moving at that rate.
I don't know if it is interfering with the DisplayLayerProgress plug-in or not. It was not showing the total number of layers for some reason. It was just showing "Progress n% Layer x of -", missing the final total number of layers. I know that it was working correctly previously.
It would be nice to be able to convert the feed rate units to something different. mm/min to mm/s for example. I suppose to be very general you could have a multiplier which would let the user convert it to whatever they wanted and not have to do the complicated unit conversion math.
Is it possible to filter out the rapid moves and just show the "printing moves"? Are the rapid moves always done with a G0 command and the printing moves with a G1?
Anyway, thanks for what you've done. I find it useful.
Is it possible to filter out the rapid moves and just show the "printing moves"? Are the rapid moves always done with a G0 command and the printing moves with a G1?
Not really, no. There are no G0 moves mixed in with the G1 moves in the gcode my particular slicer outputs, and even if there were that wouldn't stop the rapid changes you'd see.
You might be able to tell it what your travel speed is manually, and just have it filter out any speed that happens to match that speed, but you're still going to see rapid fire speeds.
I don't know if it is interfering with the DisplayLayerProgress plug-in or not.
I don't have the "DisplayLayerProgress" plugin installed but I guess it's entirely possible they might both try to use the same variable names or something? I'll install it & have a sticky beak.
It would be nice to be able to convert the feed rate units to something different.
...
not have to do the complicated unit conversion math.
Printers pretty much only operate in mm/min or mm/sec as far as I'm aware so it probably wouldn't be that complicated to do something like having a setting for "slicer units" and then "display units" and just convert back & forth.
So apparently it relies on slicer comments to determine the maximum and current layer to display there, for me it shows absolutely nothing at all with or without my feedrate plugin installed so I don't know.
@Tone Personaly I am not sure why someone needs the feedrate information of the gcode-statements visible, BUT I added @PythonAteMyPerl implementation into my DisplayLayerProgress-Plugin
At the moment it is not included into the master-branch, so you need to install it via ZIP-URL:
https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/archive/feature/feedrate.zip
Converting feedrate-unit is not included.......yet.
Please give me a feedback if it's works for you. Then I will merge the implementation to the master-branch.
BR
Olli
I just added the ability to set a different display unit to the slicer unit if you'd like to also integrate that. Also, if you'd like to take over entirely then that is quite ok by me.
The DisplayLayerProgress thing I was seeing was just do to the particular file I was printing. Subsequent files displayed progress just fine. @OllisGit I'm just in the middle of printing some things, as soon as I get a break, I'll try out your new version.
The GCODE viewer seems to be pretty well in sync with the printer, how does it do that?