Feed Rate

[mtsinc]

I've been trying to get FreeCAD (V0.17) to generate gcodes for my CNC mill, and, alas, finding new ways to crash it.

For my initial experiments, I set the horizontal feed rate for my tool at 20 mm/s, but when I went to run the program, the mill was moving far too slow.

I went back and checked the raw gcodes, and they contained "F20" elements in them, echoing the 20 mm/sec rate defined for the tool.

Problem is, unless there's something I don't know about, the actual gcode feed rate should be in mm (or inches) per MINUTE, not per second, so the proper generated "F" values should have been F1800, I think????

[sliptonic]

Which post-processor are you using?

[mtsinc]

grbl-post. But I don't know of any standard gcode implementation where gcode feed rates are per/second. All I've seen is per/minute. The fact that the tool GUI itself defaults to per-second is anomalous.

[JoshM]

grbl-post. But I don't know of any standard gcode implementation where gcode feed rates are per/second. All I've seen is per/minute. The fact that the tool GUI itself defaults to per-second is anomalous.

FreeCAD native units are in seconds, and some machines apparently do per/second, so it's only anomalous to you, me, and 90% of the rest of the world ... This is a stumbling block for every new user, despite the wiki FAQ covering it. I added it in there because I was confused too, and have seen a lot of similar posts.

Best,
Josh

[mtsinc]

Personally, I don't care to do my programming in Babylonian units, but that's apparently how MIT designed it.

But I'm not sure how to tell a CNC machine to feed in seconds, since there aren't any gcodes for that that I've ever heard of, and the g20/g21 documentation is for in/cm, not minutes/seconds. And I definitely don't want to run into a machine that takes a pre-recorded gcode program and runs by default off by a factor of 60. It's risky enough just trying to port from one CNC machine to another as it is.

All the CNC-expert sites I've seen seem to generally prefer in/sec for feed rates, which is annoying enough, since I usually design using metric. I'd be interested in hearing where these off-scale resources are just to see what they have to say.

Regardless, the grbl interpreter, like the original MIT design runs rates per minute, not per second, so regardless of what unit ratios are employed on the GUI or stored internal to FreeCAD, the gcodes coming out of the grbl post-processor need to either be scaled to inches/minute or mm/minute, depending on the G20/G21 state. Otherwise, it's a bug. After all, I can type in "1200 mm/min" straight from my operator's guide to the FreeCAD GUI and it will oblige me by immediately converting it to 20.0 mm/s, but if it then generates gcode with F20.0 in them, then that's simply not correct.


On a happier note, I have a project that I've been having to export as DXF and import into PyCAM to get a workable gcode program and instead get the gcodes straight from FreeCAD. Which was important, not only because it skips a lot of work, but also because the project has pockets of various depths, and DXF reduces everything to 2D. I'm still not totally clear on what button to use where in the FreeCAD Path workbench, but at least I'm learning.

[JoshM]

Have you adjusted your Units setting in the configuration? Make it Metric small parts, and your tool definitions are in mm/min.

That said, if you use the GCode inspector to look at fundamental Job code--as kept within FreeCAD Path, not what is exported to your machine--you will see a factor of 60.

There's a lot of useful info in the wiki.

https://www.freecadweb.org/wiki/Path_FA ... _object.3F

Most of the buttons you mention still getting used to are documented there as well.

-Josh

[herbk]

Hi mtsinc,

with a quick search in the net i'm in mind that grbl expects mm/s !!

http://www.diymachining.com/grbl-settin ... -to-guide/

[mtsinc]

Ironic that you should choose that site, since I ran across it yesterday while double-checking my assumed facts.

I'm not sure exactly why you sent me to this page, though. There's nothing regarding feed rates on it, and I don't use the Universal GCode Sender. It's a Java app and I'm using a Raspberry Pi as the control unit for my machine. UGS isn't fast enough for the Pi - either the Pi simply isn't powerful enough, or the Pi Java runtime lacks the extra optimizations that more powerful systems employ. So I use an app called bCNC.

As far as feed rates go, this is the more pertinent page: http://www.diymachining.com/grbl-feed-rate/ Where you will see that they are using units/minute as their basis.

Relating specifically to grbl, v1.1 supports G93/G94 feed rate mode commands, but they merely alter interpretation in terms of cutter speed, not in absolute time units.

Now a quick look around the source code for grbl does have one (and only one) instance where it references feed rate in per-second terms, but it's in a comment and I haven't determined whether that's incorrect of they convert to make internal operations easier. For all the outward-facing stuff (the gcodes themselves), the units are invariably in terms of per-minute.

The Wikipedia article on gcode explicitly defines feed rates in per-minute, as does all its sources I could run down. That's true both of CNC milling machines and of 3D printers. And, BTW, FreeCAD does quite well in design for 3D printers. Been using it for that for nearly a year now.

[JoshM]

You want to work in mm/minute, no? Were you not able to configure your system to do that?

[sliptonic]

Am I reading this right that there is a bug in the GRBL post processor? It's currently outputting as mm/s and should be outputting mm/min like linuxcnc?

This is a fairly easy change to make to the grbl post but I thought a lot of people were using it so I'd be surprised if such a basic bug hadn't surfaced yet.

@mlampert, do you use grbl?

If this is a bug, can we please have a mantis bug report for it?

I'm attaching a version of grbl_post.py that you can try. This is just a quick hack and not necessarily the way I would do it for real.