Yesterday I visited the Duet3D booth and had the pleasure to meet the team and have a chat with David and Christian.

It made me realize just how much is going on behind the curtains and how much work and passion those guys are pouring into the development of new features and constant improvement of the overall system.

I am super excited about what's to come.
I hope you guys have a great last day at Formnext!

Max

Good morning!

I know that this has been discussed several times already. I started this thread to collect the available closed loop options for the Duet3.

I have two custom large format printers in the making. One with a build volume of 1000x1000x1000mm for printing architecture models and one with 500x500x1000mm for printing speaker enclosures. With a Build volume this large speed and reliability are essential. Therefore, a closed-loop motion system is a "must have" for my clients.

For the Duet3 I have found the following options:

1. Duet3 + Duet3 Expansion 1XD + external closed loop stepper drivers that accept step/dir signals

2. @dc42 I am aware that there is a closed-loop extension board in the making for the Duet3. Is there already a rough estimate on the release date or beta test?

3. Is there an alternative "of the shelve" closed loop solution available that support the CAN FD protocol?

Cheers,
Max

I would like to use the constant surface speed feature on my Duet based CNC-Lathe.

I am using a generic Haas turning post Processor with some minor adjustments that I have tested with Fusion360 or Solidworks+HSMWorks.

the constant surface speed GCode (G96) is defined on the Haascnc G-Code dictionary as follows:

"G96 commands the control to maintain a constant cutting speed at the tip of the tool. The spindle RPM is based on the diameter of the part where the cut is taking place, and the commanded S value (RPM=3.82xSFM/DIA). This means the spindle speed increases as the tool gets closer to X0. When Setting 9 is set to INCH, the S value specifies Surface Feet Per Minute. When Setting 9 is set to MM, the S value specifies Surface Meters Per Minute.

WARNING: It is safest to specify a maximum spindle speed for the Constant Surface Speed feature. Use G50 to set a maximum spindle RPM. Not setting a limit allows the spindle speed to increase as the tool reaches the center of the part. The excessive speed can throw parts and damage tooling."

Cheers Max

And with this start Gcode for PrusaSlicer the correct heightmap is loaded according to the temperature of the printbed.

{if first_layer_bed_temperature[0] <=40}
G29 S1 P"heightmap_roomtemp.csv"
{elsif first_layer_bed_temperature[0] <=70}
G29 S1 P"heightmap_60°.csv"
{elsif first_layer_bed_temperature[0] <=90}
G29 S1 P"heightmap_80°.csv"
{elsif first_layer_bed_temperature[0] <=110}
G29 S1 P"heightmap_100°.csv"
{endif}

Thanks everyone for your ideas and feedback. This is by far more elegant than my original idea.

@dc42 Thank you for your response.

Yes, I am running RRF 3.4.4 (Sorry, I forgot to mention that!)
With RRF 3.5beta1 on the EXP1HCL, the Y-axis motors now keep their position when closed loop mode is activated.

Hey @bruce

Thank you so much for developing and sharing your post processor! I use it with the HSM-Works plugin directly in SolidWorks for my duet based CNC Mill.

Any chance to also include a profile for turning as well? I am in the process of converting a Lathe to CNC using a Duet3 6HC board. With lathe support, it would really be the "one post processor to rule them all"

Cheers Max

@martin7404 said in IDEX motor jitter:

@maxgyver stil.I would like to see your belt arrangment, please
Thank you

I am working from home right now. I will gladly provide you with some CAD-Screenshots of my belt arrangement later this week.

@fcwilt said in IDEX motor jitter:

But why does just the inactive axis vibrate? You mentioned that you can print with one axis without problem - correct?
Have you experimented with changing belt tension?
Frederick

Yes, I have tried every tension from loose to guitar string high.

The big drawback with CORE XY, H-Belt, Markforged e.t.c is that you create a kinematic system where multiple axis are codependent. Meaning that every little tolerance, vibration and over swing, will translate into the other axis. From what I have learned until now, the reduced moving mass is not worth having much longer belts.

@alankilian

I followed your suggestion and a lookup table to pick the initial potentiometer position and then fine tune the spindle RPM with a loop.
This worked well enough for some initial tests. But for me, it was no satisfying permanent solution.

After taking some voltage measurements, I figured that the motor controller simply needs a 0-5V Control Signal.

So I used a PWM to analog converter to provide the control signal and to galvanically separate the inverter from the Duet Board.

I am using a multifix toolpost to quickly change between tools. In order to avoid manually calibrating a new tool, I wrote a macro that can automatically set the offsets for a given tool using a touch probe. Since the multifix toolpost is very repeatable, the offsets do not need to be recalibrated after a toolchange.

I am very happy how this project turned out. The Duet3HC is a formidable controller for small CNC-Maschines.

Video: Paulimot CNC-converion test.mp4

Cheers
Max

@comediantf2

Just installed your UDL, thank you so much for your work!
-Max

@bearer @Phaedrux

I have solved the issue by installing the unstable version (DSF Version: 2.1.3) of Duet Software Framework on Raspberry Pi. and also reverting back to RC11

The guide links to the stable version of the DSF and latest version of the reprap firmware which, at least in my case is not compatible and will lead to the "DCS is unavailable" Error.

cheers Max

I would like to give this thread a little push.

Yesterday I had another crash because of this issue. Although I was aware of the issue this time, it still slipped my mind to add a new tpost.g in RRF when I was configuring new tools in my CAM software. I have about 30 tools in my library right now, and I would really like to avoid adding 50 tpost.g to my system folder just to be safe...

@chrishamm

Thank you for your reply. My screen is connected via HDMI, on my other machine with a RPI display that is connected via the RPI display port the reset button is displayed correctly.

@dc42 Thank you for your response.

Yes, I am running RRF 3.4.4 (Sorry, I forgot to mention that!)
With RRF 3.5beta1 on the EXP1HCL, the Y-axis motors now keep their position when closed loop mode is activated.

In my homing sequence for the Y-Gantry I first home Y in open loop mode as usual, lower the motor currents for both Y-steppers and then slowly drive the Y axis in physical enstops, positioned on both ends of the gantry until the motors loose some steps on each side.
By doing this, the Y-Axis is perfectly perpendicular to the X-Axis. I reset the motor currents for both Y-motors and proceed with the usual closed loop calibration sequence. My problem is that when closed loop mode is turned on, the motors do a small jump. Unfortunately, this movement is seemingly not equal in both motors, making the Y-Axis skewed again. @dc42 I am wondering what causes this jump and if there is any way to avoid it.

Here is my Y-Homing sequence. Any suggestions for improvements would be much apreciated.

;''' Home Y at the low end of the axis'''

;pre-homing check
if move.axes[2].homed=false ;check if Z is homed. If not, home Z first.
 echo "Z-Axis not homed, homing Z-Axis first"
 M98 P"homez.g"
else

if move.axes[2].machinePosition <=10 ;check if bed is within 10mm of the nozzle
 G91 ;relative positioning
 G0 Z5 ;move bed down
 G90 ; absolute positioning
else

;Home Y at the high end of the axis
G91	;relative positioning
M569 P125.0 D2 ;open loop mode Y1
M569 P126.0 D2 ;open loop mode Y2
G1 Y325 H1 F6000 ;coarse home Y

;Y-gantry squaring
M564 S0 ;allow movement outside boundaries
G1 Y-323 6000 ;move to Ymax
M906 Y800 ;Set motor currents (mA) and motor idle factor in per cent
G1 Y-5 F250 ;run Y axis into physical stop
G4 S2
M906 Y2000 ;Set motor currents (mA) and motor idle factor in per cent
G1 Y325 H1 F6000 ;coarse home Y
G1 Y-2 ;go back a few mm
G1 Y3 H1 F600 ;fine home Y
M564 S1 ;limit movement within axis boundarie

;Closed loop calibration
if global.closedloop=true ;check if closed loop is on
 G1 Y-10 F6000 ;move to a safe position
 M400 ;wait for the move to complete
 G4 P500 ;wait for the motor to settle
 M569 P125.0 D4 ;turn closed loop on Y-Motors
 M569.6 P125.0 V1 ;perform a tuning maneuver on Y1
 M400 ;wait for the move to complete
 G4 P500 ;wait for the motor to settle
 M569 P126.0 D4 ;turn closed loop on Y-Motors
 M569.6 P126.0 V1 ;prform a tuning maneuver on Y2
 G1 Y+30 F6000 ;move to Ymax

G90 ;absolute positioning

@T3P3Tony

Sry for my late reply.

Yes, the object model shows different values when a tool is loaded

echo move.axes[0].machinePosition
78
echo move.axes[0].userPosition
65.9

But the DWC does not show the correct machine Position.

@OwenD said in Stop program if no tpost.g for called tool has not been defined:

I guess CNC users must assume a certain level of responsibility that they're operating dangerous equipment.

On this I absolutely agree. I have been the witness and cause of more than one CNC-related mishap on industrial and hobbyist equipment. But shit happens...

I have never had the case where a Toolchange in the Gcode did not trigger any response on the controller side.

Most Cam software I have worked with automatically number the tools in the library. With other CNC-Controllers this is not a problem.
On our router with a industrial controller for example it is impossible to change a tool without having the according offsets defined or a toolsetting/ probing routine in place. This is absolut standard procedure for every CNC-machine I have worked with so far.

@infiniteloop

An empty tpost1.g would still do nothing. And an empty tpost1.g is already present after a fresh install if I recall correctly.

I just had a nasty crash on my CNC-Lathe because I forgot to renumber my tools, correctly.
I have defined the tool change behavior to stop the spindle and prompt the user to load the next tool before continuing with the program. This is defined in the toolchange macros from tpost1.g to tpost5.g. But in my case, the tool number was T8 and since there was no tpost.8.g macro, the program just continued and rammed the old tool into the workpiece.

I would expect the program to stop/cancel and an error message if a tool is called and no tool change macro has been defined for that tool.

With the CNC- Version of DWC 3.5.0-b1 the tool position and machine coordinate are always the same.

When a tool is selected, the machine coordinates are updated as well as the tool position. The same goes for the "Set-Z" buttons that update the machine position as well as the Tool position.

The issue is solved by downgrading to DWC version 3.4.5

@dc42

I'm running in SBC mode.