Duet3 as hardware for LinuxCNC?

dc42

@smoe, over the past few years we have been working to implement more CNC-related G- and M-codes in RepRapFirmware. However, we don't yet support all the ones that LinuxCNC uses. So I suggest you generate some sample GCode files, then see whether they include any commands that RRF doesn't yet support.

smoe

@dc42 , @jay_s_uk ,
Thank you both for your kind replies. What I had in mind was to tap into your communication with the RPi and find (preferred) or implement (if you allow) an interface in analogy to what LinuxCNC has with the MESA cards, or better, that mimics how you talk to the driver chip.

Any such interface could then be used for arbitrary other projects, be it marble machines or some other person may think that MIDI is the ultimate language and then uses your board to drive his violin.

For some initial benchmarking that I had in mind, comparing G-code of the current still original setup with your 15 years younger drivers, your board will be fine as it is, so I can start, but the summer I hope to bring a LinuxCNC-based solution.

markz

@smoe Is there a reason you want to use LinuxCNC?

I understand you like Linux but you can use a browser in Linux to control Reprap/Duet3 boards if that's your preference. Is there a feature in LinuxCNC you're looking for? Anything high level is almost certainly doable via the web api.

When you get down to the Mesa level I think the odds of working well with Reprap are extremely low and I'm not at all sure the connection even makes sense since it's so low level.

Using other hardware with the Duet boards is very easy using the web api. For example I have a camera application on my CNC totally integrated into my Duet Wifi - the camera app can move the gantry and raise/lower the head and ...

kr15_uk

You could simply wire Duet 3 Expansion Board directly if you're up for a challenge.
I've played with Duex5 (Duet2 expansion board) and Mega2560 to get decent drivers on Marlin back in a day.
Shouldn't be much different to certain extent right?!

smoe

@markz Any particular reason - I just helped packaging LinuxCNC up for Debian and would like to now use that package on my mill that I basically bought because of LinuxCNC and because of something that I wanted to mill - for a 3D printer, actually. Was pointed to Duet3 by a friend who already owns a Duet2 while looking for suitable drivers for a Mesa card - you may say I was not ready for Duet, yet.. But it is not only about G code.

For instance I want to attach glass scales to close feedback loops - which I just do not know if this is possible with Duet, yet. There may be other things coming up, like a tool changer, or maybe some interaction with a robot, no idea, I just know that LinuxCNC is a good community for that.

And finally, that Duet3 board looks so nice, it should not be hidden behind a web page.

smoe

@kr15_uk This sounds like a very nice idea. Many thanks!

markz

@smoe I don't know LinuxCnc, but using RRF programmatically is very simple.

I'm currently running RRF on a 3d printer (6HC), a 12sqft CNC router (Duet Wifi with external drivers), and a Taig milling machine (6HC). On my mill it works very well.

smoe

@markz I have ordered the Duet3 main board (for an easy start) and the extension (for LinuxCNC as proposed by @kr15_uk ) and now we'll see where this carries me.

tenaja

@markz said in Duet3 as hardware for LinuxCNC?:

@smoe Is there a reason you want to use LinuxCNC?

I am not the OP, but I can give a few reasons, coming from the perspective of someone who learned Fanuc first. (Fanuc is the most common control used on industrial ["real"] CNC machines.) Please do NOT read this as a Duet flame, but a few "reasons" why someone would want it to interface with LinuxCNC.

I have put duets in a handful of benchtop machines, and really like it...for 3d printers or small, limited machines. However, if you learned on a Fanuc or other real cnc controller, compared to LinuxCNC, duet software is like an annoying little toy that does not quite get things right, and always makes you wish for something better. Sure, it's perfect for 3d printers, and for hobbyists who haven't learned otherwise, but there's just those things where Duet fall short.

Here are a few examples.

The Duet "ignores" M0 and M1 for conditional stop. This is unsafe if you do not know it is nonstandard. Every industrial machine on the planet works like LinuxCNC and not like Duet. Every Yasnac, Fanuc, Haas, Fadal, General Dynamics, Flashcut and LinuxCNC machine I have ever used has been predictible with their behavior of M0 and M1, and none of them match Duet, and this is just one rudamentary command that should be simple to implement.

Another example is the need to configure e.g. extruders or heaters when you do not want those. LinuxCNC, for instance, only requires configuring systems or i/o you intend to use.

Duet cannot handle backlash, and that's critical for any application where precision is critical.

LinuxCNC has its flaws, but at least it follows industrial standards. Also, once you get comfortable with its interface, it is more comfortable than yet another new "non-standard" interface that is yet another hobbyists interpretation. And, it has interface choices.

LinuxCNC cannot toggle parallel ports fast enough, so they have used Mesa fpga cards to allow high speeds. I know there's a Raspberry Pi port, but it also has limitations. I could easily see a blend, like RPi & Klipper where the RPi runs the interface, and the Duet handles the I/O, instead of a Mesa card. With the Duet being a dumb pulse generator & I/O hardware, the RPi could make it into a very pleasant cnc experience.

dc42

@tenaja said in Duet3 as hardware for LinuxCNC?:

Another example is the need to configure e.g. extruders or heaters when you do not want those. LinuxCNC, for instance, only requires configuring systems or i/o you intend to use.

You can configure no extruders and no heaters in RepRapFirmware 3.

I will look at what the NIST standard says about M0 and M1.

Backlash compensation is scheduled for implementation in RRF 3.5.

markz

@tenaja Those are valid comments.

My impression after using RRF on a CNC (where it replaced something commercial much like LinuxCnc) and milling machine is that there are only three things I miss:

ability to accelerate and decelerate nonlinearly
a GUI more appropriate to a CNC
3d screw mapping

(3) is an absolute requirement so I custom wrote one inside of RRF which I embed each release (takes about 30 minutes) for my CNC. It would be nicer in the product.

(1) I'm looking into implementing but it's not that important

(2) takes a bit of coding so I'm waiting for the next release - with integrated CNC Gui so I can then work on it

I'm not a huge fan of backlash compensation. None of my machines need it (only the 3d printer has enough to matter). On my pick and place machine it's critical but that currently runs Marlin.

I'll be curious to hear how you feel RRF works out.

dc42

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

tenaja

@dc42 said in Duet3 as hardware for LinuxCNC?:

@tenaja said in Duet3 as hardware for LinuxCNC?:

Another example is the need to configure e.g. extruders or heaters when you do not want those. LinuxCNC, for instance, only requires configuring systems or i/o you intend to use.

You can configure no extruders and no heaters in RepRapFirmware 3.

I will look at what the NIST standard says about M0 and M1.

Backlash compensation is scheduled for implementation in RRF 3.5.

That is great news we are getting blacklash compensation--it could be a big step forward for a lot of projects.

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. I tried it on my first hobbyist machine, and it was a big relief when I upgraded its controller. That was the last time I will ever work with CNC without offsets.

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

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.

Duet3 as hardware for LinuxCNC?

Robert J.