Open CCSnell opened 8 years ago
Same question here!
Same again. What does the Smoothie implementation do? Does it use standard 3d printing g/mcodes? I have both Marlin and Repetier builds that support the M3/M5 and a few others and I love bCNC and would like to use it with Marlin or Repetier.
Would love to use bCNC with an mpcnc rumba (arduino) board.
So far i've broken the code to the separate files, so it should be relatively easy to add plugin to support new motion controller. It should be almost sufficient to add new plugin to this directory:
https://github.com/vlachoudis/bCNC/tree/master/bCNC/controllers
So if you are willing to add support for more controllers, the pull requests are certainly welcome.
So far i've broken the code to the separate files, so it should be relatively easy to add plugin to support new motion controller. It should be almost sufficient to add new plugin to this directory:
https://github.com/vlachoudis/bCNC/tree/master/bCNC/controllers
So if you are willing to add support for more controllers, the pull requests are certainly welcome.
I try to figure it out. Do you have any advice where to start please? Any notes about how you've integrated the Smoothie.py for example?
Any notes about how you've integrated the Smoothie.py for example?
I am not original author of any of this controller support logic. and the development process was quite suboptimal. Basicaly it was something like this: there was GRBL v0 support. then people came and started adding if() conditions to handle all the extra cases for GRBL v1 and Smoothie. Then i came and separated these randomly scattered conditional blocks of code to python classes in such way that they can be interchanged based on what controller do you use. Instead of the original branching code i now call method of the active controller class. Also when i figured that some of the code is reused across multiple controller classes, i've just created parent class (_genericController and _genericGRBL) that contains the common code to be inherited by child classes.
For example see the jog() method. There is generic jog method in _GenericController class, which is inherited by all plugins. but GRBL1 has its own jog implementation using the advanced GRBL jogging features.
So there was no real plan, it just organicaly evolved into the current state.
I try to figure it out. Do you have any advice where to start please?
I think first step would be to understand the marlin protocol. and try to tell how it is different from GRBL and/or smoothie. that way you will know if you can reuse some of the code from _genericController and/or _genericGRBL in your new class.
Once you know the difference, you can start to copy one of the existing controller plugin files and try to modify it under new name. If there is some case previously not handled by any of the controllers, you will have to add new method to the controller (as well as empty method with same name in _genericController) and then modify bCNC itself to call this method.
Maybe I contact the developer team of the Marlin and I hope we can collaborate somehow. As I see there is a demand for a Marlin support. The bCNC one of the best Open Source real time CNC controller app, while the Marlin supports huge amount of different CNC controller boards. This can be a great success.
Please also note that Marlin is mainly designed for use with 3D printers and i am not really sure how useful it would be for CNC milling.
Marlin has all the CNC capabilities built-in already. Many companies uses it to drive CNCs with propriety CNC software. You can check the firmware, it has laser and spindle support.
I started the work to implement support for Marlin firmware. Sadly, it is not as simple as to add a new controller-file and done. GRBL support a lot of non-standard commands, which are not part of the controller, but bCNC itself.
A non-comprehensive list where bCNC is not compatible with Marlin:
I would like to perform the changes in following steps:
Please let me know if this sound feasible to you?
I started the work to implement support for Marlin firmware. Sadly, it is not as simple as to add a new controller-file and done. GRBL support a lot of non-standard commands, which are not part of the controller, but bCNC itself.
A non-comprehensive list where bCNC is not compatible with Marlin:
- $ - commands are not supported by Mariln
- Non capitalized letters in G-code can be enabled in Marlin, however this is not the standard.
- Marlin requires a space between the parameters of a line
- G90 and G0 need to be on separate lines
- G10 is used for filament retraction in Marlin
I would like to perform the changes in following steps:
- Move the g-code sending entirely to the Controllers.
- Adopt the g-code generation in a way that it generates pseudo g-code (this approach is already in use in FreeCAD and will follow it)
- Add support for Marlin
Please let me know if this sound feasible to you?
It could be good if we check the Klipper FW too. Maybe it's much more easier to implement prior the Marlin, b/c it has a very thin FW on the boards, and all the calculations and g-code parsing are made on the server mostly in Python code as far as I remember. If we can solve the g-code related issues there, this can give us a head-start for the Marlin FWs.
Is there any plan to support Marlin/Repetier/RepRap in future releases? I know there are already versions of Marlin that have been ported over to work with GRBL, but those are always limited to whatever build they were forked from.