-
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.
-
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.
As in my reply to the last person, there should be no reason like many other code bases before it that functionality could not be modular. I find it hard to follow logic that says we shouldnt do it because its not something I am interested in, otherwise why do we have Delta vs Cartesan vs corexy configurations….. I have no interest in Delta printers so why should that code be added in? see my point there.
Modular code bases allow for exactly these kinds of concerns, think of it as plugins for your (insert favorite web application name here), being opensource and being that anyone can compile I do not see a reason to exclude any features when if you wanted just 3d printer functionality and some other guy wanted just CNC functionality and some other guy wanted both CNC and 3D and laser for project X then there is no reason he shouldnt be able to compile the modules to do so.
-
Changing the gcode parser is not like adding another 3D-printer kinematic. ( AFAIK, they are all based on the same parser )
I'd be happy, when the parser can do all_in_one without compromising, but I have my concernes.Although RRF is opensource, most of the users do not compile their own builds. As a RADDS owner I tried to follow the "how to make your own build" paper from RRF github, but failed to understand the paper. ( Seems written from an insider for insiders )
David and Tony are concerned about the additional support required for two RRF branches, but guess what happens, when everyone builds his own FW, trying to taylor the HW-resources for their needs. -
I don't think changing the gcode parser will be difficult. From what I have seen there are just two additional features we need to support:
1. Multiple GCode commands or multiple MCode commands on one line. The NIST standard has restrictions on what commands can be put on the same line, but I'll probably allow almost any combination of GCodes or any combination of MCodes, with just a few exceptions, and execute them in left to right order.
2. GCode command numbers can have decimal points in them e.g. G92.1
If it is necessary to interpret gcode commands differently according to whether the firmware is driving a 3D printer or a CNC machine, then I'll probably implement codes M451, M452 and M452 as defined at http://reprap.org/wiki/G-code#M291:_Display_message_and_optionally_wait_for_response.
-
Changing the gcode parser is not like adding another 3D-printer kinematic. ( AFAIK, they are all based on the same parser )
I'd be happy, when the parser can do all_in_one without compromising, but I have my concernes.Although RRF is opensource, most of the users do not compile their own builds. As a RADDS owner I tried to follow the "how to make your own build" paper from RRF github, but failed to understand the paper. ( Seems written from an insider for insiders )
David and Tony are concerned about the additional support required for two RRF branches, but guess what happens, when everyone builds his own FW, trying to taylor the HW-resources for their needs.Forgive me if I am wrong here because I have not yet dug into the firmware side of things (on my list to do) but if we were to implement a pluggable module to keep things clean, is there something in particular preventing an online compiler that pulls directly from github and downloads the resulting binaries based on the users selection? a tool similar to what there is now for downloading configuration.
I would even be willing to develop it if need be. The concerns on this subject are valid just seems to me there are workable solutions to those concerns
-
All of that is certainly possible, and thanks for your offer. However, our policy with RRF is that a single compiled binary should meet the needs of all users, except those with very specialised requirements, or those who want to make their own firmware modifications ("one binary to rule them all"). Other firmwares require some users to recompile the firmware to enable or disable functionality, either because they don't have sufficient load-time configurability, or because the hardware doesn't have enough flash or (more usually) enough RAM to support all of the functions available. In RRF we are only at 75% flash capacity even allowing for the 64Kb kept in reserve to help with flashing new firmware via the web interface - and we could reduce that 64Kb if we needed to. On the Duet WiFi and Duet Ethernet, we have spare RAM as well, and I haven't tried to economise on RAM usage yet (e.g. I use a 8K SD card write buffer, because it gives slightly better file upload speeds than 4K does).
The other issue with using pluggable modules is that they only work well if new functionality can be implemented using the existing interfaces. In fact this is rarely the case. Almost every new features I add cuts across module boundaries and requires changes to the module interfaces.
One particular situation in which a pluggable module might be useful is for supporting additional kinematics. I have refactored the kinematics code extensively in RRF 1.19 to make it easier to support new kinematics. But this still assumes that new kinematics can be implemented using a fixed set of interfaces. In practice, each kinematics appears to have its own specialised requirements. I still haven't worked out an interface for controlling homing behaviour that will work for all of Cartesian, Linear Delta, CoreXY and Scara kinematics. One option is to move much of the homing code into the kinematics classes; but that defeats the objective of making it straightforward to add classes for new kinematics.
So my preference is to make the GCode parsing changes that CNC applications need - and support this extended parsing on 3D printers too unless there is a good reason not to - and to add support for CNC-specific gcodes. Most of this is not likely to happen before firmware version 1.21 because version 1.20 will be mostly about changing RRF for the Duet WiFi and Duet Ethernet to use a RTOS kernel.
-
There's one minor thing I want to mention early:
It seems that tool diameter, spindle speed, and feed rate have a "golden ratio". At least Fusion360 always changes the spindle speed, when I change tools or reduce feed rate.
My point is, when the planner has to cut feed rate because max. feed rate is lower than gcode numbers, the planner has to reduce spindle RPM as well.
That's only my observation, please feel free to correct me. -
….......................It seems that tool diameter, spindle speed, and feed rate have a "golden ratio". ............................
That's very true in machining terms. There is always an optimum cutting speed, and by that I mean material removal speed. Either too slow, or too fast can result in the tool overheating due to friction, whereby it first goes blue then becomes brittle and breaks. (At least that was the case way back in the 60s when I was an apprentice).
-
Looking forward to firmware 1.22
