Wouldn't it be easier if we had separate CNC and FDM firmware?



  • Warning - this is a rant!

    This post is prompted by the fact that my FDM printer is currently broken because it needs a feature that has been withdrawn because it interferes with CNC users requirements. I don't often complain but TBH, I'm pretty miffed. The choice I have is to use a version of firmware that works fine with my 3rd gantry but suffers from the I2C errors, or use a version of firmware that fixes the I2C errors but doesn't support re-mapping of end stops (because that upsets something CNC related) and so renders my 3rd gantry unusable. Or wait until version 3 of the firmware becomes usable (whenever that might be).

    When the Duet team first decided that they were going to start supporting CNC users, I expressed my concern that this would make what is already very complex firmware even more complex and make configuration for new users even harder. I suggested a separate version of firmware but this was dismissed. I am now appealing again because there are a number of significant differences between additive manufacturing machines and subtractive manufacturing machines.

    A few examples that come to mind are that with additive manufacturing we start with a blank build plate so only need to know the coordinates of that build plate and only need to home to a corner of that plate. Whereas with subtractive manufacturing, there is a great lump of metal on the build surface so we need to home to positions that are relative to that lump of metal that can be any size or shape, rather than the plate on which it sits..

    Subtractive CNC machines tend to use much heavier tools and so are usually screw driven and therefore have a need for backlash compensation, whereas additive 3d printers tend to use much lighter print heads which are usually (and arguably should be) belt driven, with no need to compensate for backlash. The exception to that is Z axes but even here, gravity ensures that the same part of the thread form is always in contact and so takes care of any potential backlash.

    Still on the subject of tools, CNC machines generally need much heavier tools and so the entire motion system is different. In 3D printers, we are largely limited by how fast we can melt and extrude plastic and so can easily run into problems when trying to use additive CNC type accelerations and "jerk" because the extruded plastic won't behave the same way as the print head.

    Also CNC machines don't generally need to have a heated bed, heated chamber or heated tools and they don't have to wait for those heaters to get up to temperature. They don't generally have part cooling fans but they do have to run and control spindle speeds and maybe coolant pumps.

    These are just a few examples of differences and I'm sure there are many more. In my experience, anything that tries to do everything tends to do many things fairly well but will will never do any one job as well as something that is dedicated to it.

    So wouldn't it just be a lot easier if we had two versions of firmware - one for additive 3D printers with all the features that are needed for that purpose but none of the ones that are not, and vice versa for subtractive CNC machines?

    If not, then can I just have a version of firmware that fixes the I2C errors and also allows me to home my 3rd gantry?



  • The firmware is set to CNC mode. Can't understand why the command was deleted for the printers.



  • @deckingman said in Wouldn't it be easier if we had separate CNC and FDM firmware?:

    So wouldn't it just be a lot easier if we had two versions of firmware - one for additive 3D printers with all the features that are needed for that purpose but none of the ones that are not, and vice versa for subtractive CNC machines?

    There are hybrid machines out there that actually are a combination of 3D printer and (light) CNC router. For these it will be mandatory that the firmware supports both modes.

    Other than that I can fully understand your approach of "do one thing and do it good".

    If not, then can I just have a version of firmware that fixes the I2C errors and also allows me to home my 3rd gantry?

    I will look into whether I can provide this to you.



  • @wilriker hybrid users could store both firmware on sdcard and switch between via for example a macro. The flashing process on Duet is decent fast.



  • As long as flash size isn't a limitation it shouldn't be necessary to have different firmware for different functions; even as separate images they would likely still have a considerable shared code base and the i2c bug would be just as likely to have affected the FDM version even if the CNC version was in a different firmware image.

    The real issue release cycles and testing, combined with the natural focus on RRF3 and Duet3 and limited resources preventing backporting to RRF2.

    Kudos to wilriker!



  • OK, so here we go. I uploaded a RRF build based on 2.03RC3 that brings back M574 Cnn:nn parameter to my Dropbox.

    Caution

    I have no possibility to test this build right now. I think I found all the necessary code parts to restore the feature of M574 Cnn:nn but I am not a 100% certain about this. Please test this carefully and be prepared to perform an emergency stop in case the motors do not stop if you manually trigger the corresponding endstop.

    EDIT: I tested homing X with endstop plugged in Y and vice versa and it worked as expected. If anything else is required and not working please report back here and I try to find the missing parts.


  • administrators

    There are also early beta builds of RRF3 available on Dropbox. See the thread on RRF3 for the links. I intend to make new builds available later today or tomorrow.



  • @bearer said in Wouldn't it be easier if we had separate CNC and FDM firmware?:

    As long as flash size isn't a limitation it shouldn't be necessary to have different firmware for different functions; even as separate images they would likely still have a considerable shared code base and the i2c bug would be just as likely to have affected the FDM version even if the CNC version was in a different firmware image.

    The real issue release cycles and testing, combined with the natural focus on RRF3 and Duet3 and limited resources preventing backporting to RRF2.

    Kudos to wilriker!

    For sure the I2C errors afflict people who use the Duex expansion boards so it would equally apply to CNC users as well as FDM users. Also, for sure 90% or more of the code would be common. But wouldn't it just be easier to have 2 versions where that 10% or less can be different, rather than trying to make the firmware "universal" ?

    I'm one of the earliest adopters of Duet2 series and long time supporter of Duet products. I had a pre-production version of the Deut Ethernet before they became generally available and likewise the Duex5 expansion board. I was the first user to have a mixing hot end and it was at my request that David instigated firmware retraction to retract all filaments concurrently, for which I am grateful. So I understand the need to be patient and I'm not one to normally complain or resort to having a rant.

    But the thing is, I developed and built a force cancelling gantry which works well at stabilising a printer with high moving mass. But I could never home this third gantry so it was of limited use and I waited patiently for about 6 months for the ability to map end stops to axes, which allowed me to home this 3rd gantry. But this has now been dropped because it has adverse effects for the new CNC users and I am back to square 1.

    So as an early adopter and long time supporter of Duet 3D printer firmware, I feel a bit let down that a facility that I need and have been using has been dropped because it is detrimental to new CNC users. Hence my suggestion that different versions of firmware might allow David to satisfy the needs of newer CNC users without upsetting long established 3D printer users.



  • @deckingman To clarify a bit better what was the actual issue here: the problem was M585. This is not specific to CNC users. It's a command to probe a tool and set it's tool offsets. Probably most tool changing machines could or do use this command. A specialty in this very command was that it was possible to directly provide an endstop input to check for this very move without changing the axis' endstop beforehand and changing it back afterwards.

    The changes implemented to M574 (you waited for so lang) in turn broke this (existing and already used) feature. That's the reason why it was removed. David's wording that it there were issues only for CNC users was obviously a poor choice and misleading.

    But since I understand your frustration I provided you with a build that has both I2C fixes and M574 Cnn:nn above - but of course this again breaks M585 and as such is not intended for everyone.



  • @deckingman said in Wouldn't it be easier if we had separate CNC and FDM firmware?:

    But wouldn't it just be easier to have 2 versions where that 10% or less can be different, rather than trying to make the firmware "universal" ?

    My point was that it wouldn't have prevented the issue at hand, and as long as there isn't hardware limitations necessitating separation of the modes there is little to gain by doing it. And while I haven't checked the write specs for the flash I doubt going back and forth daily or even multiple times pr day is something that scales well.

    While I understand its frustrating, its par for the course of early adoption, I want to put a Duet on my CNC instead of trying to find a new computer for LinuxCNC; but won't happen until RRF3 is stable.



  • @wilriker

    Thanks Manuel - I appreciate your help. I note your "CAUTION" in large type so I'll maybe give it a go when I'm feeling brave.

    I don't want to argue the point, especially as you are trying to help, but M585 is for a separate probe tool which isn't the same as using an existing tool as a probe. If I ever convert my milling machine or lathe to CNC, I'll no doubt find that feature useful but not on my printer.



  • @bearer You misunderstand my point. So let's assume that you wait for RRF 3 which will have the features you are waiting for to suit your CNC requirement. You build a machine and start using it but there is a bug in the firmware. That gets fixed but the update that fixes the bug also withdraws one of the features that you waited so long for because it causes problems for 3D printer users. The release notes say that you'll have to wait for RRF4 to get your feature back. How would you feel about that? You now have the choice of putting up with the first bug, or limiting what your can machine because one of the features has been withdrawn, or waiting for RR4. That's where I am at (or would be if it wasn't for @wilriker's kind offer). There was no discussion, no apology, just a comment in the release notes to the effect that this is how it is going to be. The reason later transpires that it is because someone decided that using a CNC probing tool was more important than homing additional axes - tough luck deckingman.

    But just take a gander through the current list of gcode. I'm not a writer of code but look at G10 for example. It takes the form of (3D printer) tool offset if there are P R or S but no L parameter but if there is an L parameter it takes the form of (CNC) workspace co-ordinates but then again if there are no parameters at all, it takes the form of (3D printer) firmware retraction. That must be nightmare to administer all within the same firmware.



  • I love rants. I had exactly the same thought just weeks ago. I completely agree.

    It's not just CNC... there should more or less that, plus conditional compilation and whole unique implementation for various axes geometries etc. There are characteristics of every printer which cannot be taken advantage of unless the feature spaghetti is untangled - there's not that much CPU and RAM; it can't be just C unions and conditional statements forever.

    I don't have that much experience with firmware development, but I work at a "productronics" (I don't know the right term) company and experience shows that configuration is pure evil when it comes to machines which take months to years to build and over ten years to run...



  • @deckingman said in Wouldn't it be easier if we had separate CNC and FDM firmware?:

    @bearer You misunderstand my point

    Nope, maybe re-read wilriker's response? Its not CNC specific at all, and if the change to M574 had been subject to review before implementation and testing before release you would not have lost a feature, but never received it in the first place.

    And even if a specific G/M code required different behaviour for different modes (like f.ex. laser mode and G0/G1) its almost neither here nor there if its a run-time change or a completely different firmware image - the important part is that the correct places to write conditional code is found, and if not new features from one mode will be able to affect the others regardless of how the the firmware is delivered.



  • @deckingman said in Wouldn't it be easier if we had separate CNC and FDM firmware?:

    Thanks Manuel - I appreciate your help. I note your "CAUTION" in large type so I'll maybe give it a go when I'm feeling brave.

    Ian, I was brave for you. I got to flashing this build on my machine and successfully home X with endstop plugged into Y endstop and vice versa. So if homing is the only place you need it you are totally safe to go forward with this build.

    Ref M585: there is at least one user I know of with a 3D printer using it. A corresponding thread can be found here. But I can see that the wording in documentation leads to the impression it is for a separate probe tool as it is more common on CNC machines.

    But I also understand that you are angry that a feature you have been waiting for so long gets removed for to restore a feature that looks like it got nothing to do with 3D printing in the first place. I would probably feel the same if something similar happened to me.

    P.S.: Also I want to make you happy with this custom build because I might need you to run your new toys for me. 😂


  • administrators

    The reason why I am very unlikely to do separate builds for CNC and FDM machines is that it would double the number of firmware binaries that I have to build, and more importantly test. I already build 5 binaries and test 3 of them on 5 or 6 different setups, and there is no way that I am going to double that. Excessive use of conditionals in source code also makes it a nightmare to develop and maintain because of the way that different conditionals interact.

    I'd like to point out that the M574 facility to remap endstops was introduced in a beta version of firmware. One of the purposes of doing a beta release is so that the firmware can be exercised on a wider range of machines than I have, so that issues with new and modified features can be discovered before they go mainstream. In this case the beta test phase exposed the interaction of the new feature with M585, and it rapidly became clear that adding the new parameter to M574 was the wrong solution to the original problem.

    RRF3 is already available in beta form, with support for remapping endstops and also support for M585 (with some associated configuration changes). It currently lacks support for M577/M581/M582 and for extruder stall detection, but I expect to complete that support within a week. I intend that RRF 2.03 will be the last release in the 2.x series, and to release official RRF 3 betas once RRF 2.03 has been released.



  • @bearer Well I'm not a writer of code so maybe my impression of what is possible is too simplistic. I thought it was a bit like having libraries of functions. So a CNC version would simply include any common G and M codes plus any CNC specific codes and/or parameters from the entire "library". Then a 3D printer version would have the same common G and M codes plus any that are specific to 3D printers. Rather than both versions including every function that is available in the "library". Obviously that's not how it works.



  • @deckingman It would have been best to be implemented how you proposed/assumed. Reality unfortunately looks different - as in most software projects. Currently GCode parsing and handling is spread over three different files (and this is only counting the ones where the filename starts with GCode...) that are totalling 11,600 lines (or 12,300 if also counting the header file) as of right now.

    Splitting something like that into a more modular architecture is possible but requires a lot of time and motivation. And also other development would be put on hold for this project - or it would take ages.

    Short: it's a huge project to do that.



  • @wilriker Well I waited over a year before pressure advance would work with multiple extruders, and it's getting close to a year that I2C errors have been a problem, but I've only been waiting since last August to get my 3rd Gantry homing so I guess I'm just too impatient.

    But I'm sure we can come to an arrangement. If you can fork the firmware or whatever it is you do, I'm more than happy to do any machining that you might want.



  • @deckingman Ian, just in case you missed it: I tested the above linked build and it works. So you can you this to get your machine running again.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.