@gabinnan said in Short-to-ground reported by driver 1 2:

It says the same error even the is no motor connected

It would seem likely that you have 2 failed drivers.

Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

Sorry for the inconvenience.

No.

My deployprobe.g ; deployprobe.g ; called to deploy a physical Z probe ; ; generated by RepRapFirmware Configuration Tool v3.2.3 on Tue Jul 06 2021 14:27:02 GMT+0300 (GMT+03:00) M280 P7 S10 ; deploy BLTouch my retractprobe.g ; retractprobe.g ; called to retract a physical Z probe ; ; generated by RepRapFirmware Configuration Tool v3.2.3 on Tue Jul 06 2021 14:27:02 GMT+0300 (GMT+03:00) M280 P7 S90 ; retract BLTouch

Change P7 to P0

@phaedrux sure, i will post it as a new thread, Thanks .. . .

@phaedrux
https://share.icloud.com/photos/0KhsV-vT1zNMIi8HbYeDvEJZg
Before reading the above documentation I made it to this point.
Thanks for putting me back on track!!!

@giusciccone If you can connect via Duet Web Control (DWC), then yes, you can disconnect USB and continue with your wiring/commissioning.

Ian

@savethepetko said in Stall detected on driver(s) 0 1:

Sometimes going home okay when i start the printer and sometimes when i turn on the printer the bltouch wont light red and when i run homeall its go in the middle and stop with this error.

Sounds like your pin might be getting stuck on the self-test?

At the start of your homeall and at the end of config.g try adding these commands to clear any errors on the bltouch and ensure the pin is retracted.

M280 P0 S160 ; Alarm Release and Push-Pin UP just in case it's in alarm and deployed G4 S1 M402 ; Retract probe just in case it's down

Hi, had the same question at some point where i was using swithes instead of the stallguard homing.

My approach was to use some kind of IR-Probe style switches witch would spit out an analog signal and would slow down the axis like in the z-Probing movement with davids IR-Probe but only for X and Y.

Dont know i that is possible though.

@loris it's only needed for calibration.

@donpedro said in Accurate dimensions:

I don't think it helps me because this difference is not constant, I could adjust it from the slicer if it was like that, but it doesn't work
I have for example the following values on one axis, as the others differ
24.68
19.78
14.82
9.95
5.06

It looks to me that you have a scaling error of -2% plus an excess extrusion width of 0.75mm on each side. That would give actual sizes of 24.65, 19.75, 14.85, 9.95 and 5.05 which are very close to what you measured.

@phaedrux said in G32 and SBC mode.:

@fcwilt said in G32 and SBC mode.:

M291

@fcwilt said in G32 and SBC mode.:

Warning M91: Command is not supported

Did you miss a 2 maybe?

You nailed it.

I had the M291 P and R parameters backwards in several places and I did some quick editing - too quick it seems - and thus in the process turned M291 into M91.

It would be nice if error messages could reference the file and the line number - but perhaps that information is not available.

G32 now works and bed.g is executed.

More testing tomorrow.

Thanks for catching that.

Frederick

@alankilian
I really hope so, this one was a cliffhanger. I could print ABS with no problems at all but PETG was on the edge to work or not = mostly not after a while, could print several layers and then.....

Thanks for the heads up.

In device manager, can you go to View > Show Hidden Devices and see if anything shows up in the listing?

@peter247 Yes, just checked again and they all are all the way in. But even with all the 4 motors not connected to the board I still have the same issue.

@dc42 said in HangMower for alpine meadows?:

@o_lampe you would need to write a new kinematics class, however it would be quite a simple one.

It's the compiling, I'm afraid off and I never had to figure out inverse kinematics before. There also needs to be a correction for the changing spool diameter. (rope winding up in layers)

@kingofthegeeks this should be possible using firmware 3.3 but not with earlier versions. Prior to probing using tool 1 you will need to execute a new M557 command using U in place of X, e.g.:

M557 U0:420 Y25:410 S47 ; define mesh grid

Adjust the U coordinate range so that it is reachable by the tool on the U axis. This command tells RRF that you require a height map for the UY plane not the XY plane.

@mrehorstdmd said in Bed Origin and axis Limit:

@fcwilt The OP is worried about losing 20mm of motion, but based on the last picture he posted, all he has to do is cut the X flag 20mm shorter. I'm not sure why you'd want or need to use long flags. Once an axis has been homed, its endstop is ignored, so it doesn't matter if the flag is still in the endstop or not. Why would you want to trigger the endstop 20-30 mm before the end of the axis?

I didn't want it to trigger there but that was where I could mount the endstop sensor.

And it does matter if the flag remains in the sensor on my printer.

If the flag was able to clear the sensor when near or at 0 then homing would not work correctly since the 1st move would be to move toward 0 but it would already be past the sensor and thus the sensor could never be triggered on the 1st move.

With the flag remaining in the sensor from the first trigger position (20-30) all the way to 0 the first move either moves toward the sensor OR does not occur since the sensor is already trigger.

In either case the 2nd and 3rd moves occur normally.

Good morning @phaedrux @dc42 @owend @oozebot

When I deleted the double quotes it didn't give me an error, but it generated a blank file, I realised it was because I was trying to run M916 but it didn't exist yet, so I solved it this way.

M911 S22 R23 P "M913 X0 Y0 Z0 E0 M28""0:/sys/runonce.g"" M98 P""run1.g"" M29"

in run1.g I typed M916 and this did work as expected

only that runonce.g is not deleted, something that is good for me because I thought that if I had two blackouts in a row without having recovered this would be deleted and would not work as I wanted, when I finish printing is not deleted either, only to restart again, this makes some errors appear, so I added to my final script and my cancel.g a M30 to delete it.

This was my solution and it works fine so far:

config.g I added:

M911 S22 R23 P "M913 X0 Y0 Z0 E0 M28""0:/sys/runonce.g"" M98 P""run1.g"" M29" ; Global Variables global delete = 0

run1.g contains:

set global.delete = 1 M916

resurrect-prologue.g contains:

var temp = heat.heaters[1].active M116 ; wait for temperatures G28 XY ; house X and Y, hope Z hasn't moved G10 P0 S0 M291 R "Recovery" P "Want to recover the part" S2 T0 G10 P0 S{var.temp} M116 P0

final script I added: (resurrect.g if automatically deleted)

if global.delete = 1 M30 "/sys/runonce.g" set global.delete = 0

cancel.g I added:

if global.delete = 1 M471 S"/sys/resurrect.g" T{"/sys/resurrect1.g"} D1 ; I rename it in case I want to use it later on. M30 "/sys/runonce.g" set global.delete = 0

I hope you find this solution useful and if you think of any improvement I will be happy to hear it.

Best regards and thanks for your support.

@chrishamm said in [3.3.0] strange behavior after fresh start printer:

You seem to have two devices connected over HTTP to the Duet, is it possible that one client isn't DWC and doesn't query rr_reply frequently? That could lead to buffer starvation.

After this error messages in the console, i have started Firefox as second DCW client to watch if it is a browser Problem, the first instance was the Chrome Browser