Try adding a G4 delay command in config.g before the first command that refers to a device on an expansion board. RRF 3.2 running on Duet 3 MB6HC is so fast that it doesn't always allow enough time for expansion boards to start up. If you find that expansion boards lose CAN sync later on, we are aware of certain conditions of high CAN traffic that can provoke this. We have fixed this in the unofficial 3.3beta.

@piglet74 The start code I posted above works with PrusaSlicer 2.3 on a Duet 3 Mini+ 5, and a Duet 3 6HC, both running off a PI4. It starts with a T-1, to deselect T0, which is set in config.g and start.g. When the G10 is sent, my T0 heats up to standby temp of 150C. After the G28 & G32, T0 is selected and the M116 waits for the temp to go to first_layer_temperature. The standby temp, is to make sure any filament dribbles don't affect Z probe homing.

@chrishamm Yes i can Confirm: FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-01-05 Tested with Google Chrome in Windows 10 x64 & on a Android Phone.

Similarly to my previous post 10 days ago, I don't suppose anyone will read this either. But just in case ..... I dusted off my printer because I wanted to print something - just a simply box with lid. Having implemented my "work around" for the firmware bug that has crept in with RRF 3.2 in all my many homing files (the work around being to replace M190 with M116) when I tried to print an object, I got exactly the same homing failed error message. The "pre-print" homeall macro that gets called from the slicer start code does things a bit differently to the "stand alone" homeall macro so it contains some different commands. To be clear, I have changed the M109 that was in this file to M116 so it's some other command in this particular macro that causes the "homing failed" message - just like it was a different command that caused the problem for another user. It's pointless me spending any more time in isolating the exact command that triggers the message because nothing will get done about it. So I've put the dust cover back over the printer and ordered small box from Ebay to use instead of one that I could have printed if I had working firmware.

@ozi Hi. Homing the bed with multiple Z steppers/end stop sensors is a different issue from leveling the bed. You can do both. I think I mentioned that my printer has 3 Z steppers each with it's own end stop sensor. If your end stop sensors are correctly position you can get your bed decently level. To "fine tune" the leveling you use your Z probe and Automatic Build Leveling (ABL - base command G32) Can we get your homing working first? Frederick

@percar Yeah, already found it Unfortunately Raise3D still hasn't found the problem why Ideamaker is not working with my printer.

Needed more top/bottom layers but happy with this part. First layer (0.2) and a calibration cube

@dc42 okay thanks

@Tpmoses said in Failed to Enable Endstops: I am also having an issue with the temp readings on my heaters reading - 273.1 C. Thanks M308 S1 P"bedtemp" Y"thermistor" T100000 B4138 M950 H0 C"bedheat" T0 M308 S0 P"e0temp" Y"thermistor" T100000 B4138 M950 H1 C"e0heat" T1 You have the values of the S parameters swapped - should be S0 in the first, S1 in the second . But I don't think that should cause the -273.1 - that corresponds to a missing thermistor. Frederick

@Reefwarrior Yes, But I don't think changing the PWM frequency is the way to go. Hobby servos like this should have a 50Hz update rate to function properly. When the board resets and the signal value goes HIGH, the servo is going to mistakenly read that as a very long position pulse and will try to go all the way to one end of the travel. Disconnecting toe power to the servo will prevent it from moving. You could also build some external circuitry that blocks the constant-high signal during reboot. (I can describe that in another message if you're interested in going that way.) But I think trying to disconnect the power would get you the results you like.

My first thought is to replace the pump motor (or SSR?) with a simple 1K Ohm resistor and look at the signal on the scope. Fiddle around until you get a signal that makes sense and THEN hook back the pump. That will insure you are presenting a reasonable signal to the pump.

@jdumoulin check the wiring. the cables that come with the bltouch often the cause for problems.

@fcwilt said in My wish : Inputs debouncing: It's hard to believe that the firmware doesn't de-bounce the inputs - it's simple code. Weeeellllll........ Not simple at all in fact. Here are two articles about debouncing: http://www.ganssle.com/debouncing.htm http://www.ganssle.com/debouncing-pt2.htm As @fcwilt says, it's a tradeoff between response-time and repetition rate and how long the bounce lasts. Still, I think it should be possible to implement without using up too much RAM or CPU time. There's some simple debouncing in the filament monitor code, but it's not configurable.

As @deckingman says, we recommend using x16 microstepping with interpolation enabled; except that in some situations (particularly un-geared extruders with low steps/mm), increasing extruder microstepping improves print quality.

@Meltex said in Firmware downgrade: Hello! Recently I have upgraded my Duet 3+RPi4+Toolboard to 3.2 firmware. Now I have issues (they are uder discussion here already) and would like to downgrade to 3.1. I have that old image of DuetPi and obviously can download 3.1 firmaware but I'm not sure how to downgrade the Tooldboard. Is there any instruction how to do it in proper way? What issues are you having? Right now I can't think of any issues present in firmware 3.2 that are not also present in earlier versions.

@JamesM @Phaedrux Thank you to each of you - I will look at this. Wouldn't it be great to get past this hurdle.

Just some little more info: For those who use a SBC: adding this PrintTimeFilters on /opt/dsf/conf/config.jsondo the trick "PrintTimeFilters": [ ... { "Pattern": "Print Time: (?<s>(\\d+\\.?\\d*))", "Options": 17 }, ... ],

@hotrodford said in bltouch center: I what to thank everybody for help me first. Love how easy it is to work with. Now my next question is about bltouch. it probes just fine but it doesnt take the first probe in the middle it is about 3/4 back and over 1/4. how can I get it to probe in the middle. Thanks With the current implementation of G30 you have to first do a normal G1 move to position the probe. G1 Xaaa Ybbb Fccc G30 Both the value aaa and bbb need to take into account the probe X and Y offsets so the probe ends up in the desired location, not the nozzle. The value ccc is whatever you want it to be. Hope that is clear. Frederick

@ozi Edit:

@fcwilt said in G30 S-1 is giving me heart stitches: All right - v3.2 - good job! I'm not so confident anymore, since I have to get used to the new gcodes and parameters. Will have to use the wiki quite often. Printer is currently working, can't get the config or homing files. BTW: I had to make a new PID tuning and write config-override, I'll post that too. Soon.

@Phaedrux Not sure how I can probe on Y with only one motor running without breaking the gantry and without disassembling... I did however simulate M675 by manually using M38.2 and M38.4 commands on all axis (X, Y and Z) and this works like a charm. Is it possible in a macro to access the coordinates after each command and use that to calculate the center of the cavity myself ?

@fcwilt said in stepper precision: For comparison this is the setup I got: https://www.omc-stepperonline.com/closed-loop-stepper-kit/ye-series-1-axis-closed-loop-stepper-cnc-kit-1-2-nm-170oz-in-nema-23-motor-and-driver.html Looks like another leadshine clone

@Swift-Tester not all tweeters can vary their frequency.