@lazy_mosquito as @Phaedrux suggests, please start a new thread. Please connect via USB, send M122, and post the response. Also see the troubleshooting guide here, and post the responses to the commands found there: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues

Ian

@dc42 thank you for your answer helpfull as usual
Can you suggest me a fully compatible driver just in case?
Thank you
Andrea

@Esteban stalling a motor does not damage the driver.

if the motor just vibrates when you try to move it then the likely causes are:

Bad connection in one of the motor wires. In this case, if the motor current is set to more than 500mA by M906 then you will usually see a message such as "Driver [N] phase A[P] may be disconnected" in Duet Web Control, where N is the driver number and P s the motor phase (A or B). Blown stepper driver. Again, you may see a message in DWC. Blown stepper motor. This is rare. Again, you may see a message like "Driver n phase A may be disconnected" in Duet Web Control.

You can also run M122 and look at the Driver Status reports.

@Alva RRF actually interprets those error bits already. On the pre warning for overtemp you get a warning on the console, and the fake driver thermistor will report 100C s you could setup a thermostatically controlled fan using that value.

In addition, driver errors generate events, which you can handle in your own macros. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events#events

@MrAwesome987 Unfortunately I havent seen any mount to go direct from E3D PZ coldside kit to Roto. For me Im using the PZ disk on its own and then making my own adaptor mount

@TobiAsis I will reply via email as some questions are rather specific to your application

@droftarts I think I found why it left out so much. Bed size is not correct. Fixing it now in the mesh.g. The M557 line should read M557 X19:188 Y15:210 P10 . The info you asked for is below. Is this how we fix the height map warning?

M557 X25:175 Y25:175 P10 ; Define grid for mesh bed compensation, origin in bed centre G29 S2 ; Disable mesh bed compensation G28 Z ; Home Z G1 Z6 ; To avoid backlash move to point higher than start of calibration M558.1 K1 S2 ; Calibrate probe G1 Z6 G29 S0 K1

Screenshot 2024-12-02 201831.jpg

@dc42

please log a feature request for these on Github Issues.

Understood! Ill get on that later today.

I'm mostly using the tacho output as a method of error checking and its going to be the start of a process of per print documentation for part validation. It is quite nice to see the tacho output in the DWC and great at determining overall airflow from its output, but, its not actually that important for end customers to see, other than it looking quite cool.

The main reason for the 4 wire 12032 fans is actually for the quality of the fans outshines that of the standard 2 wire fans. The ones I have on hand even have stall detection and speed/load control which are noticeably quieter and start up smother with less of an amperage spike from a partially stalled stator when the initial power up cycle begins.

@mikeabuilder Thanks, I have heard nothing but great things about Duet3d

It's taking the bed size from M208 from the object model.

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Object_Model

@droftarts I have two identical 3D printers (in hardware and electronics), and I have switched to a new toolhead for both printers. At first I have configured PT1000 thermistors on both printers like this:

M308 S1 P"121.temp1" Y"PT1000" T100000 B4725 C7.060000e-8 A"Hotend"

In other words, I just changed Y"thermistor" to Y"PT1000". One printer does not have any problems, another one randomly gets heater fault because of the wrong temp readings, but those wrong temp reading occurred only after I paused the printer to change the filament, not once during the printing process or heat-up. But today I could not start the print because of these heater faults, it says that temperature raises too slow (photo below):
Screenshot 2024-12-02 141431.png
So I double checked the configuration for PT1000 and I have noticed that I left T, B and C parameters. I have deleted them, PID tuned the hotend again, and successfully started the print. Will see how it goes.

@CCS86 @dc42 made a build of 3.6.0-beta.2 for Maestro for internal testing, to see how bad it would be. I tried it on my Maestro-equipped delta printer. This was printing at 100mm/s, bed mesh but no IS or PA, and had a large number of hiccups, totalling almost 12 seconds of time in a simple 15-minute print (which is a lot)

=== Move === Segments created 88, maxWait 138992ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0/133392 (11888.88ms), max steps late 0, ebfmin 0.00, ebfmax 0.00

While visibly the print looked okay, the lack of FPU on the Maestro means it just can't handle the code complexity. If it was this bad with this simple example, it would just get worse with anything more complicated.

I also tested the same print on 3.5.4. No hiccups, but one Underrun, which is less of an issue than actual hiccups (for some reason I did it without mesh enabled, though)

=== Move === DMs created 84, segments created 47, maxWait 10279136ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00 no step interrupt scheduled Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0 === DDARing 0 === Scheduled moves 207302, completed 207302, hiccups 457, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1

As a 'cheap' version of the Duet 2 WiFi/Ethernet, the Maestro has had a good run. Duet3D EOL'd it June 2020, and I think the design is nearly 7 years old, back when the RRF 1.x was current. It still works, it just hasn't got the power to support the firmware developments made in that time.

Ian