Duet3 as hardware for LinuxCNC?

[dc42]

@tenaja said in Duet3 as hardware for LinuxCNC?:

I forgot one last important point--offsets; both workspace and tool. They are super helpful with CNC, and I would never dream of using a CNC machine without them.

RRF has supported both tool offsets and workspace offsets for years.

[tenaja]

@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?

[markz]

@dc42 I haven't looked into this in detail but my understanding is that milling metal (esp. inside corners) is smoother on the machine if you use a higher order function for accel/decel - and it would help with some intricate stuff I've been doing. I've started looking into it for edge condition work since my wishlist is now very short and it rates to be a small amount of coding that wouldn't impact stock RRF.

Two links:
https://www.researchgate.net/publication/269365916_An_S-curve_AccelerationDeceleration_Design_for_CNC_Machine_Tools_Using_Quintic_Feedrate_Function

and

https://www.pmdcorp.com/resources/type/articles/get/s-curve-profiles-deep-dive-article

[rjenkinsgb]

@dc42 said in Duet3 as hardware for LinuxCNC?:

can you explain #1 in more detail? Why do you need it, and how would you set the acceleration/deceleration profiles?

I suspect he means the ability to adjust tool path speed & acceleration rather than just axis speed?

eg. for one example:
Milling into an internal corner of a pocket, the speed on the existing path has to slow down dramatically before the cutter buries itself in the wall it's going to start moving along after the change in direction, so the cutter is not overloaded.

With an external corner the load drops off as it reaches the end of the move on that axis and starts along the next side, so it does not need to slow down in the same way. The path at that point would also follow a small radius so the cutter "rolls around" the corner position.

Those behaviours depend on the tool offset being either left or right of tool path and the direction of the corner.

The Duet does not have tool path offsets at all, as far as I am aware?
(G40/41/42)
They are normally also used with a separate editable tool geometry table; at minimum, length from the toolholder or chuck and diameter .

I just do not know how practical it is to try and duplicate serious (high force in proportion to drive capability) milling type axis control on a controller such as a Duet, based around stepper motors?

CNC axes have to compensate for both the direct load of "pushing" a tool in to a workpiece, and the reaction force of a rotating cutter trying to push sideways to the feed direction, affecting other axes.

Industrial CNCs use axis drives with torque feedback as the lowest level of the axis control loop; the velocity loop in turn controls torque, and the position loop controls velocity.
(Plus a kind of PID system that takes inputs from different stages of the overall axis system).

Is that torque control stage possible with the motor drivers used on the Duet boards?

I can't see it working properly at all with the external closed loop driver modules, as the CNC does not not have axis position feedback with those, at present; the most critical feedback loop, for actual position, is open.

An axis add-on board that also has an analog setpoint output, for use with larger external servo drives, and with differential ABZ quadrature position feedback, plus a good set of non dedicated 24V I/O connections could be a more practical alternative.

The ABZ feedback is because precision CNCs do not use switches directly as home positions - the switch is just to tell the CNC/PLC that the feedback device is in the correct rotation or cycle for it to look at the Z pulse from the encoder or scale and pick up the precise position from that. And differential to avoid interference on longer cable runs and with higher current motors in use.

Also display - continuous "live" axis position, feedrate, distance to go & spindle speed, with active M code and G code status plus override percentages.

All serious industrial CNCs also have an integrated PLC of some I/O size, to handle the machine mechanics, with the CNC only directly interfacing with the axes drives and estop, and all other hardware signals being passed between the CNC side and PLC side as virtual I/O in memory and then handled via the PLC program and PLC controlled I/O to adapt to the specific machine hardware.

Note that I'm not criticising Duet boards or Reprap firmware; for what they are designed for, they are superb.

It's just that having worked with large machine tools for 40+ years (and written a CNC system from scratch back in the 80s) there is simply so much that is radically different in controlling a machine tool compared to a 3D printer, it seems to me that the two should be each based on dedicated firmware (and possibly hardware) rather than trying to pack everything for both types of system into a single program & ending up with a jack of all trades but master of none result.

The Duet CPUs are orders of magnitude faster and more capable than a lot of older CNCs that can do high speed micron precision contour machining, but the machine and drive interfaces are just not there at present, for anything much above "desktop" size machines.

For an example of what I'd consider the minimal capabilities for a "perfect" small CNC system, have a look at the Heidenhain TNC360 from the early 1990s; that has everything needed, without the bells & whistles and excess complexities of newer controls.
(Ignore the graphics & non G code programming capabilities etc., they are not relevant to the machine control side).

[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.