Topics created by Piet

@chrishamm That worked, thanks.

It sounds like your browser might have needed a hard refresh? Or clear the cache.

If you're using the SBC and still have access to SSH I suggest you use these steps to roll back to the stable branch, which should get you the newly released 3.4 final firmware.

https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#downgrading-to-stable-packages

When using the SBC you should only use the apt get commands to move between versions. Uploading firmware and DWC files directly is not likely to give good results.

@Piet
there is not currently a way to echo it directly to a file however the logging function can be used, e.g.:

M929 P{"M122_Log"^{state.upTime}^".txt"} S3 M122 M929 S0

If you put that in a macro then everytime you run it a new log file will be created with the output of M122.

Note this wont work if you are already logging to another file

For future reference, this works.
The probe file can be adjusted to allow for different types of probing.

if !exists(param.X) || !exists(param.Y) ;if parameter X and Y are given echo "Make sure parameter X and Y are given (C and S optional). Aborting probe move." ;notify user G1 X{param.X} Y{param.Y} Z{sensors.probes[0].diveHeight} F6000 ;move to given X and Y coordinates and predefined diveheight M400 ;wait for moves to finish M98 P"waitForHeaters.g" H01 M568 P0 A0 ;turn the extruder heater off (interference changes sensor reading) G4 S1 ;wait 1 second M98 P"preprobe.g" ;call macro to determine triggervalue and see if it is okay to proceed probing ;M291 R"Probing." P" " S1 if global.proceedProbe = true ;if its okay to proceed probing if exists(param.C) ;if parameter C is given if exists(param.S) ;if parameter S is given G30 X{param.X} Y{param.Y} P{param.C} S{param.S} Z-9999 ;probe move else ;otherwise G30 X{param.X} Y{param.Y} P{param.C} Z-9999 ;probe move elif exists(param.S) ;if parameter S is given G30 X{param.X} Y{param.Y} S{param.S} Z-9999 ;probe move else ;otherwise G30 X{param.X} Y{param.Y} Z-9999 ;probe move elif (global.proceedProbe = false) ;if it isnt okay to proceed probing echo "Aborting probe move" ;notify user ;M292 M568 P0 A1 ;set the extruder heater to standby if global.bedLeveled == 0 G32 M98 P"probe.g" X525 Y250 echo >"heightmap.csv" "Height map file generated at", state.time echo >>"heightmap.csv" "xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum" echo >>"heightmap.csv" global.xMin,",",global.xMax,",",global.yMin,",",global.yMax, ", -1 ,",global.xSpacing,",",global.ySpacing,",",global.xNum,",",global.yNum var y = global.yMin var i = 0 G90 while var.i < global.yNum var x = global.xMin var j = 0 while var.j < global.xNum M98 P"probe.g" X{var.x} Y{var.y} S-1 M400 if var.j == 0 set global.meshLine = sensors.probes[0].lastStopHeight - sensors.probes[0].triggerHeight else set global.meshLine = global.meshLine ^ "," ^ sensors.probes[0].lastStopHeight - sensors.probes[0].triggerHeight set var.x = var.x + global.xSpacing set var.j = var.j + 1 echo >>"heightmap.csv" global.meshLine set var.y = var.y + global.ySpacing set var.i = var.i + 1

@piet to rule out a physical problem with the toolboard please do the following test:

Set the heater fault timeout to longer than it took the hotend to heat to 300 when plugged directly into the power supply, also allow a larger window. M570 H1 Pnnnn T30 where nnnn is time in seconds. Set the max temperature allowed to 310 to allow you to test all the way to 300: M143 H1 S310

Command the heater to 300 and measure the current drawn. At least until the temperature gets close to the setpoint it should be similar to that when plugged in directly.

Note these settings are not intended to be for normal use, just for this test.

There are losses in the system of course, along the wires to the toolboards. the mosfets on the toolboard and the wires to the heater but the system should be able to work with a 80W heater at 24V.

@chrishamm Thanks for reporting back! I actually also had the problem of another chromium window opening over DWC, that is fixed. Will check if the config loading is fixed too.

@dc42 Ah thanks for clearing that up!

@piet moved to firmware wishlist because I am not aware of a way to confirm if M291 has been acknowledged or timed out.

@piet this issue is triggered by the M291 S2 command in your homeall.g file. I have fixed it in the source code, so the fix will be in RRF 3.4.0 stable.

@dc42 Alright, thanks for the help!

Yep.
I got the position wrong where it stores a tool change position.
I will edit the above post

@Phaedrux Thanks for the help. This thread has got me thinking and for the production run I'll most likely use a different solution (less constrained so motors can do its thing). For the prototype I will see if it is helpfull if necessary at all.

Right now I have it working with 4 adjustment points using the following script:

M561 ; clear any bed transform

M98 P"homexyu.g" ; home the x, y and u axis

T0 P0 ; select tool 0
G1 X51.3 Y75 F5000 ; move to first probe coordinates
G91 ; relative positioning
G30 K0 Z-9999 ; probe bed with tool 0 and set Z=0

G90 ; absolute positioning
T1 P0 ; select tool 1
G1 X51.3 Y75 Z12.5 U-7.5 F2000; ; move the bed 7.5mm, and the U axis 15mm down
G91 ; relative positioning
G38.2 Z-9999 P1 ; probe bed with tool 1 and stay at Z=0
M400
G10 L1 P1 X0 Y0 Z{-move.axes[2].machinePosition} ; set Z-offset
M500 P10 ; save offset
M400
G1 Z5 ; move the bed 5mm down
G90 ; absolute positioning
M400
M117 "Z offset for tool 1 is set and saved"

T0 ; select tool 0

G30 P0 K0 X51.3 Y75 Z-9999 ; probe above leadscrew
G30 P1 K0 X400 Y448.7 Z-9999 ; probe above leadscrew
G30 P2 K0 X748.7 Y75 Z-9999 S3 ; probe above leadscrew and run compensation

@veti @deonholt @Phaedrux

I got it working now, i read on the gcode webpage that you can't have multiple analog sensors? Im assuming it has to do with the filtering.

This is what the page stated:

*"Restrictions on defining more than one Z probe (K parameter) as at RRF 3.01:

G29 and G30 commands always used probe 0 and there is no facility to select a different probe
Only one Z probe can be type 1,2,3,5 or 9. But you can have multiple type 8 Z probes.
All Z probes use the same deployprobe.g and retractprobe.g files"*

I changed it to the following in my config.g:

; Z-Probe
M558 K0 P3 C"io6.in" H5 F120 T6000 ; set Z probe type to switch and the dive height + speeds
G31 K0 P600 X-103.6 Y0 Z0 ; set Z probe trigger value, offset and trigger height
M558 K1 P8 C"io7.in" H5 F120 T6000 ; set Z probe type to switch and the dive height + speeds
G31 K1 P600 X0 Y0 Z0 ; set Z probe trigger value, offset and trigger height

I'd still prefer if there was a different way to do it but for now it works.

I do however have another question. Like i said my tool 1 moves up and down. Now when i change tools i want my bed to move down before my tool goes down because otherwise it will crash into the bed. The problem is is that i use a G10 command to set the tool offset which is measured with the FSR. This offset only applies after running all the tool change scripts. So from what i can tell there is no way to move the bed first because it will only run after the tool change scripts which would the command to move the U axis.

Currently my code for measuring and setting the offset:

M561 ; clear any bed transform
M98 P"homeu.g" ; Home U axis
G90
T0 P0 ; Select tool 0
G1 X120 Y44
G91
G30 K0 Z-9999 ; Probe bed with tool 0 and set Z=0

G90
T1 P0
G1 X120 Y44 Z7.5 U-7.5 F800; ; Move the bed 20mm, and the U axis 15mm down
G91
G38.2 Z0 P1
M400
G10 L1 P1 Z{move.axes[2].machinePosition}
M500 P10
M400
G91
G1 Z+5
G90
M400
M117 "Z offset for tool 1 is set and saved"

T0

Maybe it is a possibility to set the U offset too so it changes it together?

I'd like any input 🙂