@dc42 perfect, thanks a lot! I think the topic can be closed then.

Latest posts made by StefanSch
-
RE: Duet 3 Magnetic Encoder Usage
-
RE: Duet 3 Magnetic Encoder Usage
@dc42 thanks a lot! That's exactly what I needed. Maybe it would be worthwhile to add this to the objectmodel documentation directly?
Do you know if there is a current development to provide additional data? That might be useful for reasearch centered applications as well.EDIT: Does "RMS" stand for the root mean square of the motor error? Or is there Another meaning in this context?
-
RE: Duet 3 Magnetic Encoder Usage
@jay_s_uk jeah thats where I looked first, but the documentation is really just the name of the variables, which makes it kinda hard to understand for me what the meaning of those really is.
Thanks for the reply! -
RE: Duet 3 Magnetic Encoder Usage
@droftarts ok, thank you so far, even if that's a little pitty
I will try to figure around with the M569.5 a little then. Nevertheless, is there some additional information in regards to the object model entries available? -
Duet 3 Magnetic Encoder Usage
Dear all,
we recently installed our first magnetic encoder from duet together with the 1HCL extension boards.
Our mainboard is a Duet3 6HC board together with an RasPi.
Everything went quite smoothly, including the calibration and manual tuning.However, I have a more general question about the capabilites of the generated encoder data, with the aim to evaluate different printing settings in hindsight. In the bestcase I would prefer to either capture the data directly into an .csv file or to set a global variable with the respective values, e.g. the current error.
So far I found the following approaches (with some questions attached):
M569.5: Closed loop data collection - Can I use this command for a "long time" data capture? The variables are all documented, however I did not fully understand if that can be implemented to supervise a full printing process. Am I supposed to just leave out the "T" and "V"?
Object model:
I could find 7 different entries in the object model that refer to the "closed loop" section for the extension boards (see below). However, I did not really find any explanation in the Documentation what those actually refer to. I think the "Position Error" might be the best indicator for me? Does this refer to the "Current Error" that is plotted in the Duet Plugin for the PID Tuning?Thanks for the help and any further suggestions!
boards[].drivers[].closedLoop
Closed-loop settings (if applicable)boards[].drivers[].closedLoop.currentFraction
Current fractionboards[].drivers[].closedLoop.currentFraction.avg
Average fractionboards[].drivers[].closedLoop.currentFraction.max
Maximum fractionboards[].drivers[].closedLoop.positionError
Position errorboards[].drivers[].closedLoop.positionError.max
Maximum position errorboards[].drivers[].closedLoop.positionError.rms
RMS of the position error -
RE: Duet3D StealthChop triggers non existing Sensorless homing
@gloomyandy
You are totally right! I will rewire them for further testing.
However, do you see any reason why stealthChop should force such a behaviour?
So why does this never happen when stealthChop is not configured anymore ? -
RE: Duet3D StealthChop triggers non existing Sensorless homing
So when starting to home the axis move some centimeters before triggering the phantom-endstop.
There is no error message or sth like this and the system just treats the axis as homed.The endstops are wired exactly as written in that guide (between the IN and GND pin). I also did think about some kind of interference, however somehow the axis and endstops work perfectly when no StealthChop is defined.
I have the same approach for the Y-Axis where none of this behaviour occurs...
Probably I should replace that axis for further tests over the weekend (even though I don't see any reason how a phantom endstop can be set up and get triggered)
Thanks for your thoughts so far!
-
RE: Duet3D StealthChop triggers non existing Sensorless homing
@gloomyandy
That was my attempt to maneuver around that behaviour
I tried to set the max value for stall detection, so it never gets.
I tried the setup without that line as well, but the behaviour stays the same.If I set up the axis without StealthChop it works perfectly fine (but too loud for my application)
-
Duet3D StealthChop triggers non existing Sensorless homing
Dear all,
some time ago we started setting up our 3D system (Dual Z and Dual Y) with the Duet 3 6HC mainboard. This one is equipped with the TMC2160 motor drivers.
Our system is equipped with endstopps at every axis. However, when I set StealthChop mode for the X-Axis, the homing of the X-Axis gets triggered without hitting the endstop, resulting in a wrong position of our printbed. The X-Axis is set up in a way to always work in StealthChop.My motor config and homing protocoll looks as follows:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; General Purpose Input Output (GPIO) Pins ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; M950 P10 C"out4" M42 P10 S0 ; 1V M950 P11 C"out5" M42 P11 S0 ; 1V ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Expansion boards ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; set current for expansion boards M950 P4 C"out1" ; Exp0 M42 P4 S1 ; set current Exp0 100% (24V) M950 P5 C"out2" ; Exp1 M42 P5 S1 ; set current Exp0 100% (24V) G4 P2000 ; wait 2s for power ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Drive configuration ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; axes M569 P0.0 S1 D3 V10 ; X backwards to adjust to coord system M915 P0.0 S2 F0 R2 M569 P0.1 S1 D3 V1 ; Y_l forwards M569 P0.2 S0 D3 V1 ; Y_r forwards (somehow one axis got another direction) M569 P121.0 S0 D3 V10 ; Z_l forwards M569 P122.0 S1 D3 V10 ; Z_r forwards (somehow one axis got another direction) ; extruder M569 P0.3 S0 ; E0 + U M569 P0.4 S0 ; E1 + V ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Axes/Extruder configuration ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; mapping M584 X0.0 Y0.1:0.2 Z121.0:122.0 E0.3:0.4 U0.3 V0.4 ; set drive mapping + UVW driver for Extruder Homing ; config M350 X16 Y16 Z16 E16:16 U16 V16 ; configure microstepping with interpolation M92 X160 Y160 Z400 E6400:6400 U6400 V6400 ; set steps per mm M566 X1000 Y1000 Z200 E100:100 U100 V100 ; set maximum instantaneous speed changes (mm/min) M203 X1200 Y1200 Z400 E200:200 U200 V200 ; set maximum speeds (mm/min) M203 I0.000001 ; set minimum overall movement speed to practically zero M201 X1000 Y1000 Z1000 E100:100 U100 V100 ; set max accelerations (mm/s^2) M906 X1400 Y1400 Z1400 E300:300 U300 V300 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; limits M208 X0 Y0 Z0 U0 V0 S1 ; minima M208 X165 Y108 Z130 U80.3 V80.3 S0 ; maxima ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Endstops ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; mechanical M574 X2 S1 P"!io5.in" ; configure mechanical endstop for X on the high end M574 Y1 S1 P"!io6.in" ; configure mechanical endstop for Y on the low end io7.in not working on this setup M574 Z2 S1 P"!io3.in" ; configure mechanical endstop for Z on the high end + second endstop should be added in future update round M574 U1 S1 P"!io8.in" ; configure endstop for left extruder on io8 M574 V1 S1 P"!io2.in" ; configure endstop for right extruder on io2
The homing protocoll looks as follows:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; X Axis Homing Script ; ; 0:/sys/homex.g ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; make sure it is safe to home x axis if !move.axes[1].homed: M291 S3 P"Homing of Y-Axis required" M98 P"homey.g" ; make sure it is safe to home x axis if !move.axes[2].homed: M291 S3 P"Homing of Z-Axis required" M98 P"homez.g" ; move Z to a save print bed distance if move.axes[2].machinePosition < 30: G1 Z30 M291 S3 P"Please remove any additional equipment." J1 M913 X80 ; drop motor current to 80% G91 ; relative positioning G1 H1 X-300 F600 ; move quickly to X axis endstops and stop there (first pass) G1 H2 X5 F600 ; go back a few mm M400 G1 H1 X-10 F250 ; move slowly to X axis endstops once more (second pass) G1 H2 X5 F250 G90 ; absolute positioning G92 X0 G1 X105 F1000 M913 X100 ; increase motor current back to 100%
If any further Information is required to fix this issue I am more than happy to provide this!
Bests,
Stefan -
RE: M42 seemingly not working on my Duet 6HC Mainboard
@achrn
Perfect, thank you for the detailed explanation! Really helped me to fix my issue.