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



  • 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.



  • "Everything is possible"; but it can't be an easy task to balance new features, existing features, new products, etc, especially when you inherit a can of worms from all the decisions made by the early advances in open source 3d-printing trying to fit printing into the well defined g-codes used for cnc, and subsequently trying to support both.

    I can see that its frustrating to seeing the finish line and being told to advance to Start and do not collect $200, and getting sent to jail on the next roll; but thats just par for the course for both beta software and monopoly.

    I'll probably be testing the beta and release candidates for RRF3 in CNC mode on one of my printers when I finish the 3d touch probe for it, but I won't buy a new Duet and set up the CNC router before the second minor release or something like that.


  • administrators

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

    @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.

    A lot of it could work that way. If we were short of flash memory on the Duets, then I would probably do exactly that - leave out support for CNC-specific GCodes in the build for 3D printers, and leave out 3D printing-specific GCodes for the CNC build. However we're not short of flash memory even on the Duet 06, so I don't need to do separate firmware builds.

    The specific issue in this case was that the temporary solution I implemented to support remapping endstop inputs broke M585, and there wasn't an easy workaround. We have CNC users who need fixes and features not present in 2.02, so I had to get M585 working again. Even if there had been an easy way to disable endstop remapping when the mode is CNC, I expect CNC users to need endstop remapping too before long. So I decided to spend the time on implementing endstop remapping properly in RRF 3 rather than spending time on a workaround which would have been thrown away after a few weeks. I'm sorry this inconvenienced you. In retrospect, I should have deferred endstop remapping until RRF3 in the first place.



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

    @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.

    Brilliant! I have a fully functioning 3D printer again!. Thank you so much.

    Just out of curiosity, was that difficult to do?



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

    Just out of curiosity, was that difficult to do?

    The difficulty here was that David usually combines a lot of changes in one code revision (no offense, just stating here) and the challenge in that is finding the relevant bits that make up this specific behavior. And this was the case on both introduction as well as removal of the feature.

    Now that it's sorted out it can be very easily reapplied on all future revisions.



  • @wilriker Thanks again - I owe you. 👍


Log in to reply