Marlin: [FR] feedback on feed and flow rate changes

[maukcc]

When sending a M220 or M221 code you will not get a feedback of current values.
When using host software (octoprint) and you set a feed or flow rate you will see the set rate on that instance. when one logs in from another computer you do not see the current values.

We propose that when a M220 Sxxx is send, a message is sent back to the host with current values.

Also / or when M220 or M221 is sent without variables it is a query for current settings.

[maukcc]

I am guessing that most feature-requests get stale

[jneilliii]

I do think this would be beneficial. As it stands now there is confusion on how this works within host software (like OctoPrint) and the effect of making changes on the printer directly and that change not being reported to other connected hosts. This could effect both LCD control, TFT control, and host software control. So much so that the latest version of OctoPrint has removed the display of this information and has made it into a set only mode, causing even more confusion.

[thinkyhead]

It's a longstanding convention in Marlin not to be so chatty. Some slicers like to insert codes that change planner values frequently, and if we made all codes reflexively echo back their values every time they are set it gets a bit ridiculous. If hosts need to know these values so they can present an interface for editing them, the current convention in Marlin is to send the code with no parameters.

[maukcc]

Ah, and that works as well for M220 and M221. good.

[jneilliii]

I still think that things that can be changed by an LCD controller should report those changes to the host when modifications are done from there. It's no different than how temperature changes are reported currently. As it stands now the host software (no matter what it is) has no knowledge of "current state" and therefore fan speed, feed rate, flow rate are an unknown variable to the host. If the user doesn't know what the "current state" is then making changes to those values could potentially cause unexpected results.

[maukcc]

I do agree that these values should be known to the host. But to send them every x seconds would crowd the serial transfer. So I would send them to host when they get changed. And maybe send all variables at print start while heaters are heating. I would say this calls for a new issue

[thinkyhead]

The problem of keeping hosts informed of the machine state is not entirely straightforward, and there is no defined standard as yet. There has to be a balance between the amount of extra serial traffic that commands may produce versus keeping hosts in sync up the second. The LCD code in Marlin seldom modifies internal parameters by going through the G-code parser, so there will need to be extra reporting layer added for the benefit of controller edits paired with host printing, and a list of every parameter that a host might want to know about, and so on….

[jneilliii]

I understand it's not a minimal task to incorporate the change and I appreciate everything that the Marlin team is doing. I question though if this may start to become more relevant of an issue with the increased amount of TFT displays. Don't they act as host controllers themselves to the main print control board?

[AnHardt]

From an other perspective that only means - the concept of this displays is crap.
Dual mode is crap because Marlin-mode can change parameters without a way to notice the TFT.
Only a chain (Host - TFT - Marlin) without display in Marlin-mode and without a SD-Card on the board Marlin is running on would have the chance to analyse the data stream and could be aware of all changes.

[thinkyhead]

The approach we've been taking so far has been to "broadcast" certain messages to all serial outputs so that the PC host and the serial-based controller are both informed. In general, we tend to tailor these things to the specific controller, since each one has its own onboard code. One positive fix that was prompted by these controllers was to make M114 non-blocking, because some MKS controller sends periodic M114 commands to keep itself updated. Anyway, we can make a collection of utilities to help with these situations, and work on some reasonable standards for passing information to hosts, and there are some related features already in the hopper, such as the stuff for PanelDue that other hosts can borrow.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.