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.



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



  • @deckingman You're welcome! 🙂


Log in to reply