-
here is an example using the GRBL post processor built into Fusion 360
% (gcode test 1) (T2 D=3.175 CR=0 - ZMIN=0.5 - flat end mill) G90 G94 G17 G21 G28 G91 Z0 G90 (2D Pocket1) M9 T2 M6 S10000 M3 G54 M8 G0 X-1.691 Y52.654 Z15 Z5 G1 Z1.5 F762 Z0.817 X-1.684 Y52.65 Z0.747 X-1.664 Y52.638 Z0.68 X-1.632 Y52.618 Z0.62 X-1.589 Y52.592 Z0.569 X-1.538 Y52.56 Z0.531 X-1.481 Y52.525 Z0.508 X-1.42 Y52.488 Z0.5 G3 X0 Y52.088 I1.42 J2.318 G1 X50 G2 X52.088 Y50 J-2.088 G1 Y-50 G2 X50 Y-52.088 I-2.088 G1 X-50 G2 X-52.088 Y-50 J2.088 G1 Y50 G2 X-50 Y52.088 I2.088 G1 X0 G3 X0.098 Y52.103 J0.317 G1 X1.608 Y52.594 X1.675 Y52.615 Z0.508 X1.739 Y52.636 Z0.531 X1.796 Y52.655 Z0.569 X1.844 Y52.67 Z0.62 X1.88 Y52.682 Z0.68 X1.902 Y52.689 Z0.747 X1.91 Y52.692 Z0.817 G0 Z5 X-0.146 Y-0.605 G1 Z3.317 F762 G3 X-0.154 Y-0.583 Z3.198 I-1.402 J-0.557 X-0.181 Y-0.523 Z3.097 I-1.393 J-0.578 X-0.226 Y-0.434 Z3.027 I-1.366 J-0.638 X-0.287 Y-0.333 Z3 I-1.321 J-0.727 X-2.808 Y-1.989 Z2.835 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.669 I1.26 J0.828 X-2.808 Y-1.989 Z2.504 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.338 I1.26 J0.828 X-2.808 Y-1.989 Z2.173 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.007 I1.26 J0.828 X-2.808 Y-1.989 Z1.842 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.676 I1.26 J0.828 X-2.808 Y-1.989 Z1.511 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.345 I1.26 J0.828 X-2.808 Y-1.989 Z1.18 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.015 I1.26 J0.828 X-2.808 Y-1.989 Z0.849 I-1.26 J-0.828 X-0.287 Y-0.333 Z0.684 I1.26 J0.828 X-2.808 Y-1.989 Z0.518 I-1.26 J-0.828 X-2.452 Y-2.368 Z0.5 I1.26 J0.828 X-1.523 Y-1.128 I0.465 J0.62 X-2.452 Y-2.368 I-0.465 J-0.62 G2 X-1.98 Y-3.375 I-0.711 J-0.947 G3 X-1.075 Y-4.02 I0.659 J-0.033 X-2.9 Y0.524 I-0.913 J2.272 X-1.075 Y-4.02 I0.913 J-2.272 G2 X0.999 Y-4.285 I0.8 J-1.991 G3 X3.008 Y-3.705 I0.782 J1.06 X-6.983 Y0.209 I-4.995 J1.957 X3.008 Y-3.705 I4.995 J-1.957 G2 X4.816 Y-2.3 I2.085 J-0.817 G3 X6.195 Y-0.471 I-0.197 J1.583 X-10.17 Y-3.025 I-8.182 J-1.277 X6.195 Y-0.471 I8.182 J1.277 G2 X7.112 Y1.727 I2.251 J0.351 G3 X7.585 Y4.061 I-1.028 J1.423 X-11.56 Y-7.558 I-9.573 J-5.809 X7.585 Y4.061 I9.573 J5.809 G2 X7.616 Y6.496 I1.965 J1.193 G3 X7.27 Y8.905 I-1.566 J1.005 X-11.245 Y-12.402 I-9.257 J-10.654 X7.27 Y8.905 I9.257 J10.654 G2 X6.559 Y11.269 I1.517 J1.745 G3 X5.551 Y13.523 I-1.865 J0.518 X-9.526 Y-17.019 I-7.538 J-15.271 X5.551 Y13.523 I7.538 J15.271 G2 X4.257 Y15.654 I1.027 J2.081 G3 X2.739 Y17.63 I-1.99 J0.042 X-6.714 Y-21.126 I-4.726 J-19.378 X2.739 Y17.63 I4.726 J19.378 G2 X0.977 Y19.475 I0.561 J2.299 G3 X-0.956 Y21.141 I-2.026 J-0.396 X-3.019 Y-24.637 I-1.032 J-22.889 X-0.956 Y21.141 I1.032 J22.889 X-1.075 Y21.123 Z0.524 I-0.014 J-0.317 X-1.165 Y21.074 Z0.593 I0.105 J-0.3 X-1.215 Y21.026 Z0.696 I0.195 J-0.25 X-1.229 Y21.007 Z0.817 I0.244 J-0.203 G0 Z15 M9 G28 G91 Z0 G28 X0 Y0 M30 % -
The problem with the Grbl output is that it always start at max Z of the model and works towards the bed which is fine for a cnc mill but not for a 3D Printer I don't actually know if Fusion can output a GCODE File for a print object TBH.
HTH
Doug
-
Here is he same code but in a Mach 3 Post processor got Generic CNC
(GCODE TEST MACH3) (T2 D=3.175 CR=0\. - ZMIN=0.5 - FLAT END MILL) G90 G94 G91.1 G40 G49 G17 G21 G28 G91 Z0. G90 (2D POCKET1) M5 M9 T2 M6 S10000 M3 G54 M8 G0 X-1.691 Y52.654 G43 Z15\. H2 Z5. G1 Z1.5 F762. Z0.817 X-1.684 Y52.65 Z0.747 X-1.664 Y52.638 Z0.68 X-1.632 Y52.618 Z0.62 X-1.589 Y52.592 Z0.569 X-1.538 Y52.56 Z0.531 X-1.481 Y52.525 Z0.508 X-1.42 Y52.488 Z0.5 G3 X0\. Y52.088 I1.42 J2.318 G1 X50. G2 X52.088 Y50\. I0\. J-2.088 G1 Y-50. G2 X50\. Y-52.088 I-2.088 J0. G1 X-50. G2 X-52.088 Y-50\. I0\. J2.088 G1 Y50. G2 X-50\. Y52.088 I2.088 J0. G1 X0. G3 X0.098 Y52.103 I0\. J0.317 G1 X1.608 Y52.594 X1.675 Y52.615 Z0.508 X1.739 Y52.636 Z0.531 X1.796 Y52.655 Z0.569 X1.844 Y52.67 Z0.62 X1.88 Y52.682 Z0.68 X1.902 Y52.689 Z0.747 X1.91 Y52.692 Z0.817 G0 Z5. X-0.146 Y-0.605 G1 Z3.317 F762. G3 X-0.154 Y-0.583 Z3.198 I-1.402 J-0.557 X-0.181 Y-0.523 Z3.097 I-1.393 J-0.578 X-0.226 Y-0.434 Z3.027 I-1.366 J-0.638 X-0.287 Y-0.333 Z3\. I-1.321 J-0.727 X-2.808 Y-1.989 Z2.835 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.669 I1.26 J0.828 X-2.808 Y-1.989 Z2.504 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.338 I1.26 J0.828 X-2.808 Y-1.989 Z2.173 I-1.26 J-0.828 X-0.287 Y-0.333 Z2.007 I1.26 J0.828 X-2.808 Y-1.989 Z1.842 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.676 I1.26 J0.828 X-2.808 Y-1.989 Z1.511 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.345 I1.26 J0.828 X-2.808 Y-1.989 Z1.18 I-1.26 J-0.828 X-0.287 Y-0.333 Z1.015 I1.26 J0.828 X-2.808 Y-1.989 Z0.849 I-1.26 J-0.828 X-0.287 Y-0.333 Z0.684 I1.26 J0.828 X-2.808 Y-1.989 Z0.518 I-1.26 J-0.828 X-2.452 Y-2.368 Z0.5 I1.26 J0.828 X-1.523 Y-1.128 I0.465 J0.62 X-2.452 Y-2.368 I-0.465 J-0.62 G2 X-1.98 Y-3.375 I-0.711 J-0.947 G3 X-1.075 Y-4.02 I0.659 J-0.033 X-2.9 Y0.524 I-0.913 J2.272 X-1.075 Y-4.02 I0.913 J-2.272 G2 X0.999 Y-4.285 I0.8 J-1.991 G3 X3.008 Y-3.705 I0.782 J1.06 X-6.983 Y0.209 I-4.995 J1.957 X3.008 Y-3.705 I4.995 J-1.957 G2 X4.816 Y-2.3 I2.085 J-0.817 G3 X6.195 Y-0.471 I-0.197 J1.583 X-10.17 Y-3.025 I-8.182 J-1.277 X6.195 Y-0.471 I8.182 J1.277 G2 X7.112 Y1.727 I2.251 J0.351 G3 X7.585 Y4.061 I-1.028 J1.423 X-11.56 Y-7.558 I-9.573 J-5.809 X7.585 Y4.061 I9.573 J5.809 G2 X7.616 Y6.496 I1.965 J1.193 G3 X7.27 Y8.905 I-1.566 J1.005 X-11.245 Y-12.402 I-9.257 J-10.654 X7.27 Y8.905 I9.257 J10.654 G2 X6.559 Y11.269 I1.517 J1.745 G3 X5.551 Y13.523 I-1.865 J0.518 X-9.526 Y-17.019 I-7.538 J-15.271 X5.551 Y13.523 I7.538 J15.271 G2 X4.257 Y15.654 I1.027 J2.081 G3 X2.739 Y17.63 I-1.99 J0.042 X-6.714 Y-21.126 I-4.726 J-19.378 X2.739 Y17.63 I4.726 J19.378 G2 X0.977 Y19.475 I0.561 J2.299 G3 X-0.956 Y21.141 I-2.026 J-0.396 X-3.019 Y-24.637 I-1.032 J-22.889 X-0.956 Y21.141 I1.032 J22.889 X-1.075 Y21.123 Z0.524 I-0.014 J-0.317 X-1.165 Y21.074 Z0.593 I0.105 J-0.3 X-1.215 Y21.026 Z0.696 I0.195 J-0.25 X-1.229 Y21.007 Z0.817 I0.244 J-0.203 G0 Z15. M9 G28 G91 Z0. G28 X0\. Y0. M30 -
Yeah its quite different from the RepRap "standard" gcode ( which to be fair is very far away from the original gcode standard).
I think writing a mode that accepted this GRBL or MACH3 code in the firmware is probably not the way to go, it would be better to write a plugin for Fusion 360 to output compatible gcode. I have o idea how difficult that would be though.
-
I would have to look again because i never use the feature in 360 but I believe 360 itself doesnt even produce the gcode for printers, the print option (i believe) sends it to a slicer like simpllify3d
-
Autodesk does have their own slicer it can send to, you might take a look there
-
I do feel that this is something which should be an all integrated capability of Duet…. I envision a future where a Duet is controlling 5 independant xyz carriages like Project Escher but a couple tool heads are running a spindle or even pick and place for combining additive and subtractive manufacturing within a single printer.
Hint Hint
-
This is strictly for CNC milling and not 3D printer related.
the idea of a Duet Post Processor sounds interesting. I know with Smoothieboard it has a CNC mode, thought something similar could happen with Duet
Since GRBL is so common, wouldn't it be easier to have a interpreter in Duet to convert GRBL Gcode to Duet Code.that way all the CAM packages that can output GRBL gcode would be compatible and a custom processor for each CAM software wouldn't need to be created or maintained.
-
Hi I just registered here, but a few of you might recognize my user name from RepRap forum.
Over there, I had the same discussion with David (dc42) about CNC-implementation.
There seemed to have been an implementation of a "Roland" mill, but it is no longer pursued ATM. ( see M580 )
Might be a good idea to reuse these code fragments to implement a grbl-machine. -
If GRBL is the defacto standard for CNC gcode then it starts to make sense to have those commands when the firmware is in CNC mode (or maybe split up CNC mode to milling/turning/mutiaxis). What was not clear to me was that there was any particular standard for CNC gcode (other than the original gcode standard which everything has extended in different directions).
What does the gcode generation for subtractive CNC?
-
If GRBL is the defacto standard for CNC gcode then it starts to make sense to have those commands when the firmware is in CNC mode (or maybe split up CNC mode to milling/turning/mutiaxis). What was not clear to me was that there was any particular standard for CNC gcode (other than the original gcode standard which everything has extended in different directions).
What does the gcode generation for subtractive CNC?
I am by no means an expert in any of this, just starting to wrap my head around all of it (so forgive me if this is wrong) But when I was looking at Fusion360 and its ability to send CAM gcode to UCCNC controller for my CNC router what i found was there is not a built in post processor for UCCNC like there is for Mach3.
But I also found a number of UCCNC pros discussing this on a forum where they tried a number of post processors inside Fusion360 and the one they found to not only produce compatible code for UCCNC but also Mach3 and others was the post processor called "WinCNC"
Wouldn't it make sense to base the Duets gcode abilities on that of what WinCNC produces since it seems to be the most compatible amongst many controllers, seems to me they did their homework on gcode compatibility and if i understand it correctly (have not taken the time to look yet) you are able to edit the post processors inside fusion to see what needs to be added to Duet
-
IMHO the easiest way to support all kind of dialects is to include a module, which enables any user to define his own G/M-codes and put them in the macro folder. Of course a global database can help collecting them, so less experienced users can use them too.
The config-override file then contains a list of the standard G/M codes that have been altered by the user.Starting point would be a basic RRF version, where most of the in/outputs are not reserved for fans, endstops, thermistors etc.
Pins required for stepper drivers stay reserved.I don't know if that's possible, but it would put an end to discussions which CNC dialect deserves support by RRF.
-
I think we need to understand the problem in more detail before recommending one action or the other.
A general gcode override ability as o_lampe suggests is interesting but I can see how that could end up being very complex to support, especially for inexperienced users.
Is anyone able to point me to a resource that lists the various CNC dialects (great term!), The various codes they use and what functionality that actually is?
-
I've counted more than 80 different post processors in Fusion 360. Way to much to work out the differences between them.
It seems they wrapped the firmware around the machine, now we try the opposite way: finding one code for all machines…I believe they all have some basic functions in common.
On my wish list are:
3 axis control incl. homing, spindle management, coolant-pump for spindle and part and maybe some safety inputs ( flow sensor for coolant, temp sensor for spindle, enclosure door switch ) -
80 post processors? So 80 different gocde dialects? thats unfortunate.
For your wishlist:
All axis can be homed using G1 with the S1 switch.
Much of the rest could be implemented using these reprap gcodes:-
M3: Spindle On, Clockwise (CNC specific)
-
M4: Spindle On, Counter-Clockwise (CNC specific)
-
M5: Spindle Off (CNC specific)
-
M6: Tool change
-
M7: Mist Coolant On (CNC specific)
-
M8: Flood Coolant On (CNC specific)
-
M9: Coolant Off (CNC specific)
-
M10: Vacuum On (CNC specific)
-
M11: Vacuum Off (CNC specific)
These are in the reprap gcode specification but not implemented in RepRapFirmware except for M3 which is Roland Mill specific
I think it makes sense to extend the the :
https://duet3d.com/wiki/G-code#M580:_Select_RolandGcode into a "select CNC" and then
Having additional temperature triggers to trigger macros is on the wishlist, maybe a flow sensor can be similar enough to a temp or endstop trigger to run a macro when a threshold or state change is sensed.
-
-
That is why I was recommending the WinCNC post processor from Fusion360 as a model to base the gcode after. That post processor not only makes compatible gcode for WinCNC controllers but the code is also compatible with Mach3 and UCCNC controllers and some others… why not add Duet to that same compatibilitty list?
I do have to admit some bais here, I use a UCCNC controller on my CNC machine, i selected it for the same reasons that i selected Duet for my 3d printers (both are great controllers) the wincnc post processor allows compatibility of gcode with it as well as several others.
I would love to be able to do both subtractive and additive manufacturing from a 3d printer build though.
-
Here you go:
NIST RS274/NGC standard: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374
That is the full documentation for the RS274 standard which all controllers are based off of, they just all add their "extras" which are controller specific and is why we see so many post processors in fusion.
So if you base Duet off of that documentation we can move forward.
-
Much of the rest could be implemented using these reprap gcodes:
-
M3: Spindle On, Clockwise (CNC specific)
-
M4: Spindle On, Counter-Clockwise (CNC specific)
-
M5: Spindle Off (CNC specific)
-
M6: Tool change
-
M7: Mist Coolant On (CNC specific)
-
M8: Flood Coolant On (CNC specific)
-
M9: Coolant Off (CNC specific)
-
M10: Vacuum On (CNC specific)
-
M11: Vacuum Off (CNC specific)
I think all that is needed to support most of these is a new gcode command to configure which logical pin numbers control spindle on, spindle direction, mist coolant on, flood coolant on, and vacuum on. The exception is M6. It seems that in CNC gcode, a T command doesn't actually change to the specified tool, it just selects a tool ready for when the M6 command is issued. So we need a "CNC mode" state flag to change the behaviour to do this.
-
-
I think all that is needed to support most of these is a new gcode command to configure which logical pin numbers control spindle on, spindle direction, mist coolant on, flood coolant on, and vacuum on.
That is, what I meant with a new module inside RRF, where users can adapt their machines to these M codes. It makes sense to base it on a "naked" RRF version where only the basic functions are set and I can reuse fan-, heater-, or thermistor connectors etc. for my own purposes.
The new gcode would have to be able to call a (C++) macro, which describes the way the machine should respond in different scenarios.
Code words like IF, AND, OR, etc would make it perfect for almost any usecase beyond gcode- CNC. ( eg. robotics ) -
The new gcode would have to be able to call a (C++) macro, which describes the way the machine should respond in different scenarios.
Code words like IF, AND, OR, etc would make it perfect for almost any usecase beyond gcode- CNC. ( eg. robotics )I am not sure making the macos C++ would be a great idea for most users. Gcode should be sufficient (with appropriate additions).
You point about a "naked RRF" makes sense, David has already implmented the ability to disassociate some pins from their original function, see the notes here: https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.
David:
@dc42:I think all that is needed to support most of these is a new gcode command to configure which logical pin numbers control spindle on, spindle direction, mist coolant on, flood coolant on, and vacuum on. The exception is M6. It seems that in CNC gcode, a T command doesn't actually change to the specified tool, it just selects a tool ready for when the M6 command is issued. So we need a "CNC mode" state flag to change the behaviour to do this.
Could we set the pin numbers as flags to the M commands?
I think extending the Roland Mill M580 to general CNC mode makes sense
Whitewolf:
I know that ReprAp gcode is based on the NIST standard, the issue is it has many extensions past the standard (as apparently do GRBL, UCCNC etc) so its not as simple as just implementing that, however it is a good starting point (and the M codes I listed earlier are a subset of it). more to follow.
