@thesfreader has made me very happy today. Thank you so much for your work, and Heffe even jumped in for some backup. What a wonderful team.
What has happened is in the coming updates we will have access to G0! Currently G0 and G1 do the exact same thing and are just considered moves. This update will let us have a true "Rapid" feedrate and "working" feedrate. In turn this should allow us to have a much easier time porting CAM software and updating the post processors since this is normal machine behavior. What we will need is to typically make sure the Z axis gets issued it's own rapid and it's own working rate to get most post processors on board. I am hoping this makes some of the built in defaults work better since we actually do have separate rates built into the firmware so if they work we are set!
Â
Thank you for your hard work. I appreciate it…and know I know we have anther coder in our midst…
Note that I also added the options to manage parenthese comments and “modal” movement mode where subsequent moves don’t need to re-specify the move mode (G0 or G1). All in all, I hope this will reduce the needs for (or complexity of ) a Marlin specific post-processor for use in CNC-like use cases, which is widely in the scope of the MPCNC.
I’ll probably add an other option here that would be more “standard” and use F only for G1…
And please take it as part of a major THANK YOU Ryan for all your work for us ;-).
Â
Non mandatory Open-source at its best here ^^
Â
Also I’m really grateful for Thinkyhead and the rest of Marlin team for allowing “CNC” updates inside of their software, which main target is 3D printer.
Â
Lastly, if Ryan you see any other “quick-wins” to be made in Marlin, in particular on its “perimeter”, I’ll be delighted to find out if I can help there too
If you are bored I have two that top my list I would love to see happen. 1-Zero Extruders (I know there are a few other PR’s). This would make dual endstops easier for other boards but not all that big of a deal. 2-Might be more interesting if you want to email me about this one.
Ryan (or anyone), have you tried sending enormous speeds, with reasonable limits in the firmware? Something like having a 5mm/s max on the Z and commanding a 3000mm/min movement? I know there were some problems with these limits in the past, especially because they would cause a reset in some versions. I’d be curious to check that accelerations and jerk work as advertised too.
It would be nice if we could assume G0 was as fast as the machine could go, and that could be adjusted in the firmware (although, you saw me fight for the behavior to limit it more in gcode ).
I think this puts a little more responsibility on the firmware to limit the top speed (especially the Z) and some responsibility on the user to adjust that if they want faster speeds.
It’s exciting to see though. I’m looking forward to some easy, fast travel moves.
No, not in a long time but it needs to be tested again. I will have to merge the newest stuff and test it, including the other changes we talked about a awhile ago, cnc coordinates, and softstop menu, and add the G92.
I do know a user just had his board choke from some small arc commands, that is still a bother to me. From what I understood the new buffer stuff should have seen the issue and slowed down to compensate. Or maybe I don;t have it enabled or something…The firmware is getting pretty massive and complicated.
P.S. Thanks for jumping in and being a supportive voice. You clearly understand all the code speak and I think that really helps get things into Marlin, they have a long list of stuff so votes of confidence seem to help.
Heffe, I was wondering about that too, since I think I saw some new artificial “speed limits” (depending on the CPU) having been introduced in recent (a few weeks ?) commits… Will have to check indeed.
Â
Also, Ryan, I just sent you a “contact” form with my email
).