Duet3 as hardware for LinuxCNC?

[rjenkinsgb]

@arnold_r_clark said in Duet3 as hardware for LinuxCNC?:

I think from your reply that you need to go and familiarize yourself with and fully understand how to use /deploy macro's as and when required, they would not be "littered" around the code at all, the base/core offsets would be contained within the config.g

That may be OK for basic length offsets, but as of yet Reprap Firmware does not support tool path offsets at all, that I can find.

They are one of the most fundamental facilities of a CNC milling machine.

ie. G40-41-42 codes in conventional gcode programming.
More info:
http://www.cnccode.com/4298/cnc-milling-g41-and-g42-codes-tool-radius-offset

[cjm]

@rjenkinsgb Apologies for a NOOB question but as many CAM programs seem capable of generating effective tool paths without requiring the G40,G41,G42 tool path offsets, what benefit does having them bring?

[A Former User]

This post is deleted!

[JoergS5]

I believe G40...G42 is not included in RRF, because RRF historically comes from 3D printing and the offsets are analogous the nozzle width, so the calculation is done inside the slicer. I don't see a big problem to calculate it in RRF for CNC (not a problem, but some effort of course).

I agree that a priotitized CNC wishlist would be good. I would not split 3D and CNC RRF parts, but handle it by creation of different RRF bin files by flags 3D/CNC/Laser..., so there is one development base, but diffferent created firmware files.

[dc42]

@rjenkinsgb said in Duet3 as hardware for LinuxCNC?:

The Duet does not have tool path offsets at all, as far as I am aware?
(G40/41/42)

Correct, RRF does not yet support cutter radius compensation.

[dc42]

@joergs5 said in Duet3 as hardware for LinuxCNC?:

I would not split 3D and CNC RRF parts, but handle it by creation of different RRF bin files by flags 3D/CNC/Laser..., so there is one development base, but diffferent created firmware files.

It's already a pain testing 5 main board firmware binaries, some of them on multiple machines. We don't want to treble that by having different binaries for FDM, CNC and Laser. Also there are at least two types of machine that use RRF on Duet to do both FDM and CNC operations.

[JoergS5]

@dc42 said in Duet3 as hardware for LinuxCNC?:

already a pain testing 5 main board firmware binaries

I understand the reasoning, thanks for explaining.

[roiki11]

@cjm

In a cnc program you want to adjust your toolpath based on measurements. So in one point you might see that the features are slightly too small. So you add cutter comp to cut a tiny bit smaller. You can also use it to walk your holes to a specific tolerance(for example). Add cutter comp to undersize the hole. Then walk back the offset and repeatedly run that program segment.

Cncs are not accurate like you imagine 3d printers to be. The machining process often requires fine tuning to get proper results and continuously regenerating the program is very slow and unnecessary. Just better to change a single value on the console and get on with it

[cjm]

@roiki11 Thanks very much for the explanation - helps me to understand better!

[tenaja]

@arnold_r_clark said in Duet3 as hardware for LinuxCNC?:

... the base/core offsets would be contained within the config.g

And this is the reason "offsets do not exist" from a CNC users perspective. You cannot very well rerun your config file in the middle of making a part, to make an adjustment, and then resume the part.

Now, if you could run an immediate command to adjust the offset, that would be an inconvenient workaround, but if it wouldn't mess with your gcode file position, it could work.

And my experience with cnc and 3d printers is that the former is far more accurate and repeatable. However, the precision required is also often far more demanding... But tools regularly need replacing, and the tools vary. Every time a tool is replaced, the offsets typically require adjustment... But you can't know the adjustment amount until you've cut chips. And you don't want to discard that cutting progress just because an offset needed adjustment. It's often not like filament, where it's so cheap it doesn't matter.

[JoergS5]

@tenaja said in Duet3 as hardware for LinuxCNC?:

this is the reason "offsets do not exist" from a CNC users perspective. You cannot very well rerun your config file in the middle of making a part

I think this is not the case. Most G-Code commands can be run within config, G-code file or command line at any time, there is no difference. (The exceptions being some drive mapping/adding commands and similar). So I see no problem to change tool offsets between moves at any time.

[tenaja]

@joergs5
In a normal cnc machine, with a normal cnc controller, if you need to make an adjustment in the middle of the program, without restarting, these are the steps:

• Hit pause
• Navigate to the offset page
• Make the adjustment
• Navigate to the program page
• Hit start (to continue the gcode where you left off)

The program continues from where it was, using the new offset.

How would that workflow be on duet?

[dc42]

@tenaja said in Duet3 as hardware for LinuxCNC?:

@joergs5
In a normal cnc machine, with a normal cnc controller, if you need to make an adjustment in the middle of the program, without restarting, these are the steps:

• Hit pause
• Navigate to the offset page
• Make the adjustment
• Navigate to the program page
• Hit start (to continue the gcode where you left off)

The program continues from where it was, using the new offset.

How would that workflow be on duet?

Hit pause, send the command to change the offset, hit resume.

[tenaja]

@dc42 said in Duet3 as hardware for LinuxCNC?:

@tenaja said in Duet3 as hardware for LinuxCNC?:

@joergs5
In a normal cnc machine, with a normal cnc controller, if you need to make an adjustment in the middle of the program, without restarting, these are the steps:

• Hit pause
• Navigate to the offset page
• Make the adjustment
• Navigate to the program page
• Hit start (to continue the gcode where you left off)

The program continues from where it was, using the new offset.

How would that workflow be on duet?

Hit pause, send the command to change the offset, hit resume.

But then when you turn it on the next day to make another, is that number retained, for every tool?

[JoergS5]

@tenaja I would not want to persist changes if they are e.g. temporary changes to tool offsets. But it may be a matter of taste or of situation and how one works.

I think it's a question whether you want to persist the changes or not. There is e.g. M500 to store and M501 to restore by a config-override.g file at firmware startup, and tool offsets can be stored with this with M500 P10. Whether it works for multiple tools completely, I don't know for sure. https://duet3d.dozuki.com/Wiki/M500

[Miss Rebekah]

canned drill cycles, g80 g81,g82,g83. cutter comp, a feed hold button that stops immediately( deal breaker for me) single block mode. an offset table for wcs and tools.

[dc42]

@miss-rebekah cutter radius compensation and feed hold are under consideration for implementation in RRF 3.5. Canned drill cycles can probably be implemented already as macro files, now that you can not only create a macro file called G80.g to implement the G80 command but also pass parameters to it.

[Miss Rebekah]

@dc42 thank you for your reply G80 is cancel canned driling cycle so without g81,2,or 3. there is nothing to cancel. g80 is just cancel there are no parameters or switches in iso gcode.

please give the option to use either wear or diameter comp, with diameter comp usually all your lead-ins require a linear move equal to or greater than of the radius of the tool this is a pain in a small hole but there are people out there that love it. i prefer wear comp less can go wrong .000 wont crash your part like in diameter mode.

feed hold would probably get me to swap my linux cnc setup on my router to robot arm and use my duet 2 on router.

Thanks