Wouldn't it be easier if we had separate CNC and FDM firmware?
-
"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!