@oliof Belatedly, I've added this advice to the Pressure advance page, and to M572. I also added the note about high extruder jerk to M566.

Ian

@chrismbp I asked @dc42, he says:

Yes most likely the mosfet failed and it took out the driver chip too. Also possible that the driver chip failed and took out the other components.

I was wondering if this might be related to the failure of your 1HCL https://forum.duet3d.com/topic/37666/duet-3-1hcl-can-connection-timeout-after-config-changes ? The only linking factors I can think of is a failing/spiking PSU, or static discharge into the VIN or GND side of the boards.

Ian

@tcamguil said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

;Kliky L
M558 P8 C"10.io0.in" H2:0.25 F1200:120 T18000 K1 R0.0 A15 S0.005 ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X42.00 Y0.00 Z-25.000 K1 ; set Z probe trigger value, offset and trigger height
...
;Kliky R
M558 P8 C"11.io0,in" H2:0.25 F1200:120 T18000 K1 R0.0 A15 S0.005 ; set Z probe type to bltouch and the dive height + speeds

Do you have one Klicky probe, or two? You seem to be defining two, on different IO inputs. Or is it the same Klicky, but it depends which tool head picks it up?

You have K1 set as the probe number for both probes, so most likely only one of them is actually being configured; the second effectively overwrites the first, so when the 1st toolhead (using the CAN '10' board) picks it up, it's looking on the wrong input for the probe response. Same for G31. Send M558 K# to check what probes are defined. Use a different K number for each probe. I don't know which probe number you are using in your 'pickupprobe.g' etc macros, but you could pass a parameter to the macro based on the tool number.

As far as I'm aware, the mesh should be applied to both tools. Please post your full config.g, maybe it's a config issue.

There is an issue running mesh probing on the U axis, it has been reported before, and your third issue sounds similar to this: https://forum.duet3d.com/topic/37165/issue-with-szp-on-secondary-idex-toolhead

Ian

@davidjryan If your 2nd motion system commands start getting longer, you may need to include M606 S1 to enable the job/macro file to be read by the motion systems separately. Without this, the two motion systems share the primary queue, so one motion system may be starved of commands until the other motion system has processed commands. From the 3.5.1 update notes https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-351-stable-changes-since-346 :

[Duet 3] When processing job files, commands for both motion systems are now processed by the primary file stream by default. The secondary file stream is only activated if the M606 command is used, which can be done in the job file or in the start.g.file. When the job completes the secondary file stream is closed and commands in the stop.g file for both motion systems are executed by the primary stream.
[Duet 3] New M606 command supported to fork the input stream when running a job from SD card. This command must be used in the job file if you want the second input stream to execute commands for the second movement system; otherwise commands for both movement system are executed by the primary file stream.

Ian

@steezebe It's the "TC_roto_coil_mount.step" file, here: https://github.com/Duet3D/Duet3-RotoToolboard/blob/master/mechanical/TC_roto_coil_mount.step

Ian

@chrismbp I can see some other burnt components just under the red arrow, R204 and D45. These are both on the B+/B- phase of the stepper motor, but after the MOSFET H-Bridge. I'll have to check what might have caused this with @dc42.

Ian

@f-riccardo Please post your config.g and homeall.g files. This will help us understand how your endstops are currently set up. Also please send M122 in the console and post the response.

The origin (X0 Y0 Z0) should be in the bottom left corner. If your prints are coming out mirrored, most likely your X and Y axes are switched. Check the motors move the axes in the correct direction, see https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_testing

Ian

@Eumldeuml said in Gradual layer shifts with integrated JMC stepper servos:

If I understand correctly, this means there won't be any direct connection from STEP+ on the driver/motor to STEP+ on the EBB? But the signals will still be differential?

That's correct. Drivers most commonly have opto isolated 5V inputs, which don't require differential drive. A few have RS422-compatible differential inputs; 3V drive is sufficient for those.

@Dlock34 said in dual motor z axis bed leveling not probing by lead screws:

M574 'z1 S2

The DWC message is provoked by that line because there is no 'z axis.

@chrismbp Okay, we're happy to offer you a warranty replacement on this 1HCL. When and where did you buy the board? Assuming it's from one of our resellers (@elmoret from Filastuder maybe?), 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.

Ian