Duet3 as hardware for LinuxCNC?

[A Former User]

This post is deleted!

[tenaja]

@arnold_r_clark said in Duet3 as hardware for LinuxCNC?:

@tenaja said in Duet3 as hardware for LinuxCNC?:

@dc42 LinuxCNC lets you set up a chart of offsets. This lets you set up a list of workspace offsets (i.e. for your vise corner--or several vises, if you have multiple setups at once) and also a list of tool offsets (to set tool diameter and length, in a mill) for numerous tools. It also lets you edit any offset in the middle of a cut so you can adjust for tool wear, etc, and have immediate corrections.

How do we do those things with RRF?

Having a cursory glance at the duet g-code dictionary it that shows that

G10: Set workplace coordinate offset or tool offset

Is what you want, and I would surmise that with macro's you could create a "chart" of differing offsets contained within those different macro's and call that macro to set the differing offset as required.

Yes, I saw that, too...so how would you set up a chart of those so they were not littered around your code, unfindable and uneditable on a whim?
Having the feature in a 3d printer config file where you are controlling the extruded quantity and having it on a mill where you swap out tools many times in a setup and have the need to compensate for tool wear regularly (and instantly) are two different things.
From a CNC operators viewpoint, a one-time code buried in the gcode file does not encompass tool offset that a real cnc machine control does.

[tenaja]

@rjenkinsgb
Steppers can do just fine in a milling machine. If you size them properly and know their capabilities, and stick to those capabilities you will have no issues.

You have to plan ahead not to overload them, especially if you are pushing the limits of weak steppers. Sure, you also have to do that in servo cnc gcode, too, and at least those machines will stop in an error. OTOH, with LinuxCNC, you could add encoders, and have the same feedback and error faults. (This is a "why LinuxCNC" thread, afterall.

I have found the gwizard feeds & speeds tool invaluable in ensuring you don't take more of a cut than a machine is capable of.

[A Former User]

This post is deleted!

[rjenkinsgb]

@tenaja said in Duet3 as hardware for LinuxCNC?:

Steppers can do just fine in a milling machine. If you size them properly and know their capabilities, and stick to those capabilities you will have no issues.

I don't disagree at all - it's how they are driven and incorporated in the axis position feedback loop that determines the axis capabilities.

A stepper is in effect the concept as a multi-pole brushless DC servo motor - a set of phase coils creating a rotatable magnetic field around a permanent magnet rotor.

The big differences are the precision of the drive waveforms applied to the phase windings - and how much they can be out of position before "slipping".

[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