Wouldn't it be easier if we had separate CNC and FDM firmware?
-
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.
Manuel
Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
with probably always latest firmware/DWC (incl. betas or self-compiled)
My Tool Collection -
"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.
-
@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!
