-
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. -
Ok so looking at the NIST standard GCodes (both G and M):
Implemented (minor additions might be required):
-
G0 rapid positioning
-
G1 linear interpolation
-
G2 circular/helical interpolation (clockwise)
-
G3 circular/helical interpolation (counterclockwise)
-
G4 dwell
-
G10 coordinate system origin setting
-
G20 inch system selection
-
G21 millimeter system selection
-
G28 return to home
-
G90 absolute distance mode
-
G91 incremental distance mode
-
G92 offset coordinate systems and set parameters
-
M0 program stop
-
M1 optional program stop
-
M3 turn spindle clockwise
Not implemented but something else is implemented instead that may or may not make up for it
-
G30 return to secondary home (It is a simple probe in RRF)
-
G38.2 straight probe (its G30 in RRF)
-
G43 tool length offset (plus) (covered by the Z offset in G10?)
-
G49 cancel tool length offset (covered by the Z offset in G10?)
-
G53 motion in machine coordinate system (Covered by G90, although G90 is modal)
-
G92.1 cancel offset coordinate systems and set parameters to zero (Not implemented but G92 gets most of the way there)
-
G94 units per minute feed rate mode (this is the way RRF deals with feedrate by default)
-
G98 initial level return in canned cycles (not implemented y the amount of Z movement or tool movement on a axis can be just another line in a macro)
-
G99 R-point level return in canned cycles (not implemented y the amount of Z movement or tool movement on a axis can be just another line in a macro)
-
M30 program end, pallet shuttle, and reset (Delete an SD card file!)
Not implemented at all yet
-
G17 XY-plane selection
-
G18 XZ-plane selection
-
G19 YZ-plane selection
-
G40 cancel cutter radius compensation
-
G41 start cutter radius compensation left
-
G42 start cutter radius compensation right
-
G54 - G59.2 use preset work coordinate system 1-9
-
G61 set path control mode: exact path
-
G61.1 set path control mode: exact stop
-
G64 set path control mode: continuous
-
G80 cancel motion mode (including any canned cycle)
-
G81-G89 canned cycles (use macros?)
-
G92.2 cancel offset coordinate systems but do not reset parameters
-
G92.3 apply parameters to offset coordinate systems
-
G93 inverse time feed rate mode
-
M2 program end
-
M4 turn spindle counterclockwise
-
M5 stop spindle turning
-
M6 tool change
-
M7 mist coolant on
-
M8 flood coolant on
-
M9 mist and flood coolant off
-
M48 enable speed and feed overrides
-
M49 disable speed and feed overrides
-
M60 pallet shuttle and program stop
-
Also the S switch for spindle speed
So quite a lot to do, some of which is relatively straight forward (switch on and off coolant, spindles), while other parts would need serious consideration ( XZ,YZ plane, various co-ordinate systems, path modes).
-
-
I agree it's probably a bit overkill to ask for full C++ support in macros, but from what I know, the "canned cycles" would require some loop structures, counters and boolean algebra. None of that is implemented in gcode.
Maybe we can post-process such a canned cycle in gcode compatible code?Re G17-G19: Do we need more than G17 in a 3 axis machine?
Re G43 & G49: AFAIK the tool length offset is based on the first tool length, so we'd need a default length to start with.
Because there are different WCS ( G54-G59 ), the offset would have to be adapted.
Re G40-G42: I've seen options in Fusion360 to do that and grbl for instance only allows G40 mode, so we might not need it.Anyway, I'm glad there is enough interest from yours side to get things started and get another notch in the belt.
Duet with RRF will be the most versatile controller one day! -
Regarding loops: gcode Macros can call themselves recursively. The issue is we don't have real branching.
We have up to 6 axis so it's probably something we want in the longer term.
There is definitely interest on this side however what would be helpful is to further group and prioritise each of the logical groupings of functions. Once we have that we can see where they for in the evergrowing wishlist!
-
How do you set the exit strategy in gcode for recursive macros?
If number_of_loops =>max_loops or Z<= Z_min then returnAlso we don't have variables like [c] Z=Z-last_Z [/c]
-
Yep no exit strategy, just input changes. No variables either right now.
As I have said before, extending gcode in this way is akin to what happened to GPUs/shader language/ML (albeit on a smaller scale).
Have you a concrete example of where this is required? Arguably much of the higher level functionality should be the job of the slicer/gcode generator.
-
No, I haven't seen such canned cycle yet, but it made sense to me they would be something like parametric subroutines, like cutting threads or drilling standarized screw holes?
OTOH, the filesize on SD-card can be very huge nowadays, given the price/GB. So why would anyone care about compressing and simplifying the file by using subroutines? -
Yes, if the gcode generator just puts another chunck on gcode in for each threaded hole or whatever and the file size gets big that did not appear to be a problem.
On other CNC firmwares that implement these canned cycles, are they written in gcode or hard coded into the firmware? If in gcode then we can use a macro.
Let's parked extending gcode with branching and variables for now and look at the list of G/M codes. Does anyone want to have a go at grouping and prioritising them ?
-
Is the plan to implement these CNC commands into existing firmware making a single universal "do all" firmware or have a separate firmware exclusively for CNC machines? If it's the former, then I have a few concerns.
-
Ian
I don't think the decision has been made, the issue with a totally seperate version is that it increases the support requirements.
My preference would be to have one or more CNC modes (this already exists for the Roland Mill, but expand it to be more general). Ultimately a 3d printer is a subset of a larger family of CNC machine.
We already have Delta, Corexy and Cartesian modes so this could be an extension of that concept.
-
I believe the support will be much more difficult, when the user has to "undefine" thermistors, heaters, extruders a.s.o. to make a CNC machine out of a 3D printer firmware.
Not to mention PanelDue or DWC…
To ease up things, there should be a sample config on SD-card image for a cartesian mill with X, Y1, Y2, Z and U axis ( or 2nd Z-axis?).
What do you mean with grouping the G/M codes? Work out the differences between dialects? Then we should start with a list of dialects RRF will support.
For now we have grbl, mach3, wincnc, roland.
Is Linuxcnc an option? AFAIK, it runs on PC-internal controller cards? USB-support seems very limited. -
Tony,
So my concerns with a "one size fits all approach" (and these are just my personal observations) are that we'll have a whole bunch of G and M codes that aren't appropriate for a 3D printer. I've had instances of DWC reporting unsupported commands like M1070. Nobody has as yet come up with an explanation of how or why this happens but the commands are definitely not in the gcode file. This isn't a real issue because no action is taken. But if a command existed that was supported but only for CNC machines, and it somehow crept into a 3D gcode file, by some weird means like the above, or by strange slicer behaviour or by "fat fingered" post slice editing and it got acted on, it could have some weird, unpredictable or detrimental effect. That's why personally I think additive 3D printer firmware should be separate from subtractive CNC 3D printer firmware. (It's at this point that someone will jump on and say they want to build a machine that is both an additive 3D printer as well as a subtractive CNC machine - hell lets throw in laser cutter as well)
As a general observation (and again this is just me) I believe that Duet firmware is already in danger of becoming too bloated. I appreciate that the intention is to give every user what they ask for, but for new users "coming in from the cold" we are already seeing comments about how complicated it all is.
Just my rambling thoughts…...........
-
I've only seen a few lines of CNC milling code, but it seems, the "." dot has several different meanings there.
1st. The classic decimal dot [c]X1.234[/c]
2nd The subcommand [c]G19.1[/c]
3rd The end of line
[c]G1
Xnnn Ynnn
Xmmm Ymmm
Xmnm Ynmn.
G0[/c]
I'm concerned these different meanings will slow down the gcode parser, especially when integrated in 3D printer fw.
The last thing I want is reduced printquality ( not the right term actually ) for many, just to make some CNC guys happy.It seems the parser needs a rewriting anyway to be able to read several G-commands in one line and properly deal with subcommands a.s.o.
-
Tony,
So my concerns with a "one size fits all approach" (and these are just my personal observations) are that we'll have a whole bunch of G and M codes that aren't appropriate for a 3D printer. I've had instances of DWC reporting unsupported commands like M1070. Nobody has as yet come up with an explanation of how or why this happens but the commands are definitely not in the gcode file. This isn't a real issue because no action is taken. But if a command existed that was supported but only for CNC machines, and it somehow crept into a 3D gcode file, by some weird means like the above, or by strange slicer behaviour or by "fat fingered" post slice editing and it got acted on, it could have some weird, unpredictable or detrimental effect. That's why personally I think additive 3D printer firmware should be separate from subtractive CNC 3D printer firmware. (It's at this point that someone will jump on and say they want to build a machine that is both an additive 3D printer as well as a subtractive CNC machine - hell lets throw in laser cutter as well)
As a general observation (and again this is just me) I believe that Duet firmware is already in danger of becoming too bloated. I appreciate that the intention is to give every user what they ask for, but for new users "coming in from the cold" we are already seeing comments about how complicated it all is.
Just my rambling thoughts…...........
Smoothieboard has both not sure how it is implemented, whether it uses different firmware for both functions but I do know that it is used for both CNC and 3D printers. Yes I am one of the people who would like to see the board support both additive and subtraction manufacturing just by switching out tools on my current printer…. Many of the retail printers do something similar, in fact I just linked to a Delta that accomplishes this through magnetic tool heads.
But the functionality can be used to go much further than just swappable tools, Project Escher was designed not to be strictly a 3D printer, but multiple gantries with different tools can work together on a single project. While I understand your concerns on feature creep, Duet is the only opensource board that I am aware of that supports expansion boards and is capable of doing more advanced use cases (after some firmware changes).
Maybe to address your concerns there might be a way to create modules for those who wish to expand the Duets functionality so we are not limited to XYZ printers but instead allowed the freedom to pick from a set of features that apply to our particular application.
