@gloomyandy

also i am try to simulate same Gcode with RRF 3.5.0 rc4 in that only one gcode give the bad command error (2 time simulated and giving two different error which is attached in image)

also attached Gcode SS

Hey,

I am using Duet 2 wifi with RRF 3.5.0 rc3.

sudden change in jerk and acceleration after resume APF, it's set random value which is not in config and not in gcode.

gcode in which jerk is 300 mm/sec & acceleration 500 mm/s2, when i run the power failure sequence and after resume the print there is sudden vibration in X Y axis, so i am rum M204 to check it's acceleration and the result of it is 50000 mm/s2 and jerk is 600mm/s but gcode generated on jerk 300mm/s and acceleration 500 mm/s2.

so give me solution what should i do?
@dc42 @Phaedrux

Hey,
I am trying to disable wifi of Duet2 Wifi by following below on YAT terminal.
M552
M552 S-1
M552
M552 S0

But it's not stop and whenever power up it display Error: Wifi module reported: network scan failed.

Any Suggestions.

When I am printing anything I found 12V under-voltage event (9.5V)after 1 layer complete.
Error comes up when 2nd layer start printing.
This error repeat every time while printing.
If I left machine ON with extruder heater and bed heater ON, then I didn't get any error.

I am using Duet Main Board 6HC with 24V Meanwell SMPS and it's output is 24V I have verified.
Changed my extruder heater.
Checked all wiring and no lose connection.

Can you please give me advice how can I find root cause for this under voltage event?
@dc42 @Phaedrux @T3P3Tony Is there any way to troubleshoot this problem?

@dc42 hey,

After upgrading to the latest firmware version 3.5.0rc4, we observed improvement in print acceleration settings. However, the travel acceleration is taking random value: while print acceleration seems to be functioning correctly, travel acceleration values are fluctuating unexpectedly.

@droftarts Thanks Yesterday i am trying using paneldue but missed M588 s"*" so it's not working. Thank you once again.

@droftarts
David seems to be absolutely right. Thank you both of you!
When I set skew factor 0, this problem doesn't appear.

now my question is , if skew is enabled , after some printing or moves, Y position changes. On HOMEY, I see Y position as -0.6 or so. How do I set it to 0 on Yhome?

Ideally, on Homing, position should be 0, right? Please revert on this.
(note: atimes this negative value is -0.0, -0.6, -1.9 etc, on homing Y)

Thanks & Regards,
R006

@jay_s_uk
i am waiting for your reply

@dc42 said in warning: received malformed responses:

@R006 which version of PanelDueFirmware are you using? RRF 3.6 requires version 3.5.1. The "malformed responses" messages may occur because you are using an older version.

Panel version is 3.4.1, but this warning appears after resume APF only, in normal printing this warning is not appears.

@dc42 said in warning: received malformed responses:

@R006 :

1. Where are the "malformed responses" warnings coming from? DWC, or something else?

On panel

2. Are you running the Duet in standalone or SBC mode?

standalone mode

3. Please upgrade to firmware 3.6.0-rc.3.

Okay, but could you please clarify why this warning appears?
Is it possibly related to cabling, signal integrity, or something else?
I’ve read "https://forum.duet3d.com/topic/32837/malformed-responses-warnings-on-paneldue-7i?_=1746789074093", and it seems to describe the same issue I’m experiencing — so I suspect it might be related.
Any insights would be appreciated.

Hi,

I’m using a Duet 3 MB6HC running RepRapFirmware 3.6.0-rc2, and I’m encountering a "malformed responses" warning after repeatedly using the Resume After Power Failure (APF) function.
Under normal conditions, the warning does not appear. However, after resuming from APF multiple times, the warning is consistently displayed — though it does not appear to affect any functionality.

Could you please advise on what might be causing this issue?

Any suggestions would be greatly appreciated.
@dc42 @Phaedrux

Thanks,

@droftarts said in Stall Detection on Duet 2 WiFi and Duet 3 MB6HC:

Have you set up the sys/driver-stall.g macro? Even without this, you should get a message in the console, though motion will continue. If you don't get a stall warning message, adjust the sensitivity; see https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection#stall-detection-sensitivity-m915-s-f-and-h-parameters

Yes, the driver-stall.g macro is present in my sys folder. I’ve tried setting the sensitivity value from -10 to +64, but stall detection still isn’t working.

Recently, I tried testing stall detection for a stepper motor on a tabletop setup using RRF version 3.6.0-rc1. Both daemon.g and driver-stall.g macros are present in my sys folder.
Here’s what I did:

1. I homed the Z motor using the G92 command.
2. Then I moved the Z-axis with the command: G1 Z300 F6000.
3. While the motor was moving, I manually held the shaft to simulate a stall.
   However, no stall was detected — neither daemon.g nor driver-stall.g was triggered.

@droftarts said in Stall Detection on Duet 2 WiFi and Duet 3 MB6HC:

Change your M915 R parameter to R2 to trigger the event. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m915-configure-motor-stall-detection

i have try to generating trigger but it's not run while motor is stall.

For servos, I assume you have 6HC with CAN-connected 1XD, connected to the external drivers for the servos. The external drivers usually have an error or alarm pin. See the 'Alarm' section of the configuration examples here https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Expansion_1XD#configuration-examples to set up an IO pin and triggers to detect the alarm.

Thanks. i am just conform with.

@Phaedrux said in Stall Detection on Duet 2 WiFi and Duet 3 MB6HC:

The old unsupported 3.5 rc2 or the new in testing 3.6 rc2?

i am testing with this RRF too.

Hi,

I’m using a Duet 2 WiFi board running RepRapFirmware 3.5.0-rc2. My setup includes six stepper motors: three on the Z-axis, two on the Y-axis, and one on the X-axis.
I’m trying to implement stall detection and would appreciate some guidance on where to start. I’ve followed the documentation at:
" https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection "
I set up a table-top test, but stall detection doesn’t appear to be working as expected.
Here is my current configuration:

daemon.g

; Monitor for X stall
if move.axes[0].stalled
  M291 P"X Axis Stall Detected!" R"Warning" S1 T3
  M18 X ; Disable X motor

config.g

M569 P0 S1 D2         ; Configure driver 0 with stall detection enabled (mode D2)
M584 X0 Y1 Z2:3:4 E5  ; Axis mapping
M915 P0 S3 F0 R0      ; Stall detection for driver 0, sensitivity 3, no filtering, no action

Questions:

1. Is there anything incorrect or missing in this configuration?
2. Is there a recommended way to test stall detection in a controlled manner?
3. Should the daemon check be done differently in firmware 3.5.0?

Additionally, I want to implement stall detection on a Duet 3 MB6HC board. This setup uses:
-Three stepper motors for Z,
-Two servos for Y,
-One servo for X.
Can stall detection be applied in a similar way for servos, or would I need a different approach?

Any help would be greatly appreciated. @dc42 @Phaedrux

Hey,

I would like to inquire about using the SZP sensor for bed auto-levelling, similar to how the BL-Touch operates.
Is it possible to use only the SZP sensor for both bed auto-levelling and mesh bed levelling?

I would appreciate any suggestions or guidance you could provide on this.

@dc42 @Phaedrux @fcwilt @gloomyandy @oliof

@dc42
Thank you for your response.

If I want to change the pin number to light up LEDs, where should I modify the firmware code?

hey,

I am using a Duet 3 MB6HC (version 1.02) with a custom build of RRF 3.4.0beta3. Upon powering up the board, I have observed that the STATE and ACT LEDs on the mainboard do not illuminate, while the LEDs on the 1XD expansion board are functioning correctly.

Due to project constraints, I am unable to update the firmware. I would appreciate any insights or recommendations on troubleshooting this issue.

@dc42 @Phaedrux