Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes

jrwaters2

I noticed G10 is being deprecated in the future and that M568 - "Set Tool Settings" will be used. The draft release notes for beta2 state "M568 has been repurposed: Set Tool Settings to set tool offsets . . ."

In the Gcode Wiki, the M568 command already alludes to the change (i.e. states that M568 is being re-defined). However, it makes no mention of supporting tool offsets.

I know G10 will continue to work and I know things are still under development so apologies if this is not helpful. Just wanted to point it out in case it was an oversight.

Phaedrux

This is as good a place as any to start the discussion. As you say, things are still being worked out. There will be more communication along the way.

deckingman

@jrwaters2 Thanks for bring that to our attention and ..................

.............oh for f**ks sake! I have numerous different configuration files to suit my multiple hot ends, one of which is a 6 input mixing hot end with 10 tools defined by default. I'm going to have to change all those tools, in all those files as well as dozens of macros and a handful of post processing scripts which all use G10 to set active and standby temperatures. Then there are all my slicer start and end gcode files, as well as all the backup copies of those all those files.

I'm getting seriously pi**ed off with all the changes I keep having to make due to changed firmware behaviour.

garyd9

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

...all use G10 to set active and standby temperatures. Then there are all my slicer start and end gcode files, as well as all the backup copies of those all those files.

For those that don't really use standby temps, they might be better off sticking with the forever "depreciated" M104 and M109 for setting tool temps. Yes, they are "depreciated", but as long as nearly every slicer still uses them for setting temps, RRF will be forced to keep supporting them for the same purpose.

To be honest, I don't know why duet3d keeps changing how temps are set for extruder tools. They are basically forced by slicers to keep supporting M104/109, so why not just extend those two commands to also support setting standby temps and stop trying to redefine what is already common usage?

For example (proposed is the "A" parameter):

M104 T1 S200 A150 ; set tool 1 active temp to 200 and standby temp to 150

deckingman

@garyd9 said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

...all use G10 to set active and standby temperatures. Then there are all my slicer start and end gcode files, as well as all the backup copies of those all those files.

For those that don't really use standby temps, they might be better off sticking with the forever "depreciated" M104 and M109 for setting tool temps. Yes, they are "depreciated", but as long as nearly every slicer still uses them for setting temps, RRF will be forced to keep supporting them for the same purpose.

To be honest, I don't know why duet3d keeps changing how temps are set for extruder tools. They are basically forced by slicers to keep supporting M104/109, so why not just extend those two commands to also support setting standby temps and stop trying to redefine what is already common usage?

For example (proposed is the "A" parameter):

M104 T1 S200 A150 ; set tool 1 active temp to 200 and standby temp to 150

Using G10 to set active and standby temperatures goes right back to the very early days of RepRap firmware when Duet only made the 06 board and before DC42 got involved with the firmware. That was the method that RepRap Pro (Andrian Bower's company) used for my very first printer which was a Mendel Tricolour. So that's what I've been using ever since.
Since then, G10 has been given additional functionality (by dc42). Now he wants to remove it's original intended purpose and force everyone who uses it to make extensive changes to their machine files.
Coming just after my having to change all my homing files to get around a bug in the previous stable firmware, this makes me so angry.....

chrishamm

@deckingman The warning message for G10 wasn't intended by the core team and we've reverted this change in the upcoming 3.3-b2. Removing or breaking functionality in a minor version update doesn't work because it's a breaking change and that kind of change belongs into a major update. So we may actually consider this change for RRF 4 but not before.

G10 is problematic because there are lots of overloads and because it conflicts with existing CNC applications, but since the early RRF days this has been a great improvement over M104/M109. So yes, M568 might be nicer in the future but the deprecation of G10 isn't planned in RRF3 despite that warning message.

Sorry for the confusion.

dc42

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

Since then, G10 has been given additional functionality (by dc42).

The only G10 functionality I have added is functions that have been defined for CNC applications for many years, most if not all of them predating RepRapFirmware.

@garyd9 said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

For example (proposed is the "A" parameter):
M104 T1 S200 A150 ; set tool 1 active temp to 200 and standby temp to 150

Unfortunately there is a fundamental difference between M104 and G10/M568. With M104, heating is expected to start immediately. With G10/M568, heating doesn't start until the tool enters the appropriate active or standby mode. Furthermore, some slicers do standby temperature management themselves, and they expect M104 Snnn to set the temperature of as tool that is on standby.

deckingman

@dc42 I say again, from a user's point of view, it would be better if there was different firmware versions for (subtractive) CNC machines and (additive) 3DPrinters, rather than this "one size fits all" approach. Life would be much better if we had firmware that did one thing well, without the unnecessary "features" for other machine types and the constant need to reconfigure our machines every time the firmware gets updated. Backwards compatibility is becoming more and more of a nightmare.

jay_s_uk

@deckingman except for machines that incorporate both. then you'd be on the 3 firmware versions.

deckingman

@jay_s_uk said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

@deckingman except for machines that incorporate both. then you'd be on the 3 firmware versions.

So what? From a user's perspective, that would still be better. Fundamentally it comes down to the fact that Duet can't/won't employ more people or allow more contributors to manage the firmware. So the management of the firmware is being done to accommodate the limited resources available and to hell with the fact that it's a complete PITA for end users.

dc42

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

So what? From a user's perspective, that would still be better.

There are at least two machines using RRF with both additive and subtractive capabilities used within a single job. So a single firmware needs to support both.

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

Fundamentally it comes down to the fact that Duet can't/won't employ more people...

If we charged much higher industrial-level prices for Duets instead of the present prices, and didn't open source the designs and the firmware, then we could do that.

deckingman

@dc42 said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

Fundamentally it comes down to the fact that Duet can't/won't employ more people...

If we charged much higher industrial-level prices for Duets instead of the present prices, and didn't open source the designs and the firmware, then we could do that.

Yup. It's your choice. You choose to make and sell a few boards which just about cover very limited R&D resources, while giving away the designs to cloners who will always be able to undercut you on price, because they don't have any R&D costs to recoup (in fact, you even support those cloners by giving them your firmware for nothing and spending time providing support for them on these forums). Or, you could choose not to share the design, sell very many more boards (without having to increase the cost) which in turn would fund the resources needed to support the product in a more customer focused and user friendly way.

Or another way of looking at it, could be that happy customers spread the word which leads to increased sales, which lead to more profit, which can fund more R&D. The converse is true of unhappy customers.

T3P3Tony

@deckingman I don't want this to degenerate into an open source/closed source thread but it is important to note:

RRF was originally written by Adrian Bowyer. I am not sure if any of that original code exists any more in RRF 3.3, it has gradually been extended and re-written. None the less the whole project is licensed GPL. If we wanted to make a closed source firmware we would need to start from scratch. (edited to add, the current firmware has contributions for people outside the core Duet team who probably would not (or more likely could not) have contributed if we did not publish the source)
Yes we do have cloners, would there be fewer clones on the market if we did not release information about our boards? Possibly but given the proliferation of clones on non opensource designs, that's not a given.

T3P3Tony

Bringing it back on topic. G10 is not changing in RRF 3.3. At some, TBD, point in the future (possibly RRF 4?) the use of G10 for temperature settings (as opposed to the older, CNC, use for tool offsets) will be removed. Before that there will no doubt be many more discussions about when and why. A new tool parameter ( Spindle RPM) has been added to M568 and we took the opportunity to add other tool related settings there rather than trying to shoehorn another parameter into the already overloaded G10. If you are not using a spindle you can ignore all this for now. If you are using a spindle, there is now a parameter to set the RPM.

deckingman

@T3P3Tony That's good to know. Will you be amending the documentation which currently states quote "Note that this use of G10 is deprecated in RRF 3.3beta2 and will be removed in a later version. Use M568 instead." ?

BTW, much of this animosity could be avoided if users are consulted beforehand. Or at the very least, a statement setting out the reason why something has to be changed along with possible alternative ways to achieve that change.

Simply announcing a fundamental change to the firmware, which might require users to carry out significant changes to their machine configuration files, without any consultation or input from those users, is bound to get people's back's up (well it does me). People will in general accept change if the reasons for that change are given, rather than it being imposed upon them by diktat.

jrwaters2

@T3P3Tony said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

M568

Thanks - will the offsets also be added to M568? That was the piece I was asking about.

T3P3Tony

@deckingman

@deckingman said in Regarding upcoming RepRapFirmware 3.3beta2 G10 M568 changes:

Will you be amending the documentation which currently states quote "Note that this use of G10 is deprecated in RRF 3.3beta2 and will be removed in a later version. Use M568 instead." ?

yep have done so

BTW, much of this animosity could be avoided if users are consulted beforehand. Or at the very least, a statement setting out the reason why something has to be changed along with possible alternative ways to achieve that change.
Simply announcing a fundamental change to the firmware, which might require users to carry out significant changes to their machine configuration files, without any consultation or input from those users, is bound to get people's back's up (well it does me). People will in general accept change if the reasons for that change are given, rather than it being imposed upon them by diktat.

Agreed. We try to do so, this one slipped through the net!

T3P3Tony

@jrwaters2 Not in my understanding of the changes. Tool offsets should be G10 L1 ...

jrwaters2

Thanks @deckingman