@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.

@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:

I homed the Z motor using the G92 command. Then I moved the Z-axis with the command: G1 Z300 F6000. 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.

@martin7404 the M569.1 parameters only affect closed loop and assisted open loop modes, so they should have no effect when performing sensorless homing in open loop mode.

Getting 0.9deg motors working well in closed loop mode can be challenging. In particular, the encoder calibration is more critical and the maximum speed will be lower.

Good news!

I printed 3 more of the same 3D model (22 hour print ~500g of plastic PETG) and I have not had this failure since grounding the casing of only the extruder motor. So it seems that the issue was indeed ESD on the stepper driver causing it to go into a failure mode.

Thank you very much for your time and help!

I think you're on the right track with the G60 command. You don't provide any details of the trigger macros, so the rest of this post is just guessing on my part...

I assume you've read this page on setting up triggers: https://docs.duet3d.com/en/User_manual/Tuning/Triggers, and that you've set up the inputs for the two buttons using M950, and also defined triggers numbered 10 and 11 using M581. Also, you've got these commands in your config.g file so they'll be executed every time you start the machine.

The trigger10.g macro should need only one command.

;trigger10.g G60 S3

When this macro runs it will save the current machine location into slot #3.

The trigger11.g macro should looks something like this:

;trigger11.g G0 R3 X0 Y0 Z0

This commands a fast move to the stored S3 location without any offset in the X,Y,or Z positions stored in S3. If you don't have the X0 Y0 Z0 in your command, those axes won't be moved (it will look like nothing has happened when you push the second button).

An additional thing to consider in your trigger 11.g macro. If your "move to" button is pressed before the "save position" button, the default coordinates stored in slot S3 are 0,0,0 so you'll drive a move you might not want. If you are unlikely to ever save 0,0,0 with your "save location" button, you could write an IF statement into your trigger11.g macro to look at the current values saved in this slot and if they are all 0, you could do something like post a message and not make the move.

To test your trigger10.g macro without the buttons, you can send M98 P"trigger10.g" in the Web control window, then send echo state.restorePoints[3].coords to see the saved coordinates. You can also look at the object model plugin to see if the location has been stored. It will be in state > restorePoints >3

You can similarly test trigger11.g. After running trigger10, move the machine using the Web control then send M98 P"trigger11.g" in the Web control window. Your machine should move back to the stored position.

You can also test the inputs by looking at the inputs section of the object model while you press the buttons.

@Esteban said in Information on the distribution of calculations on Duet cards:

On the other hand, one last question: for very complex machines with a large number of axes, would it be more “efficient” to have a main 6XD and then add 1XDs and another 6XD in daughter mode?

If all the axes and extruders use servomotors then you should start with a 6XD. If there are more than 6 servos to connect then you will need another 6XD or some 1XD boards to drive them. If the additional axes need high step rates then another 6XD would give better performance than 1XDs.

@gsch1803 said in Unresponsive duet 3 6HC board:

@Phaedrux I believe it was purchased from Amazon in October

Who is the amazon seller?

@R006 in firmware 3.6 the code that sets the LED pin numbers correctly depending on the board version is at src/Platform/Platform.cpp starting at line 3489.

@achrn thanks for that info. i will try at 25khz and also the pullup resistor

@dc42 the label on the fan is the right one but someone said that rat ric also had an batch with the wrong label

@R006 What is the bed surface? It needs to be metal on, or near the surface (under a PEI sheet is okay), ie not have glass on top.

Are you setting the M558.2 calibration with the SZP coil around 4mm from the bed?

When you say "the value is fluctuates between 0, 9097, and 999999" are these the only three readings? Or does it give other readings? I'd usually expect to see readings in the range 1500 (Z6) to 15000 (Z0.3). You shouldn't get 0 or 999999 readings.

Random 999999 readings can be caused by:

Interference on the SZP ribbon cable (from SZP to coil). Makes sure to route the SZP ribbon cable away from the coil, ie make sure it doesn't go over the coil Poor ribbon cable contact. Ensure it is FULLY inserted into the tiny connector, at both ends. Try reseating this if you continue to get erratic readings Make sure there is no metal in the 30mm ABOVE the coil, or it will pick this up and give false readings

What firmware version are you running on the 6HC and SZP?

Ian

@axiom only create a bed mesh of the area of the print: https://forum.duet3d.com/topic/37242/mesh-bed-leveling-only-in-printing-area-using-orca-slicer

Ian

@dc42

I just ran into the same thing... 2 of my drivers were complaining about over heating...yikes!
This is on a Duet 3 Mini 5 with 6 active stepper motors.

So, I'm off to print a backing plate with taller stand-offs and a mount for a blower fan. My stepper motors are all fairly cool, but the amperage draw makes sense. My FLIR ONE camera came in handy yet, again! ; )

Cheers!

@axiom 1736183041163-flow.jpg

@stuartofmt Thank you for the answers, everything actually works if I simply copy the IP address from Motion....sadly my new raspberry 5 said goodbye after 1 hour...despite the expensive original fan and expensive power supply

@HugoZM My guess is that you have mis-wired the endstop switch so that when it is triggered, it shorts out the 3.3V rail or the 5V rail. If that's the case then you will see the red 5V or green 3.3V LED go out when you trigger the endstop switch.

@Arkadiusz it sounds like a power supply problem to me. Send M122 a couple of times to reset the record of minimum VIN voltage; then command movements that cause the motor to stall; then send M122 again and look at the current and minimum VIN voltage in the report.

@axiom octoprint can be run on an rpi5 https://community.octoprint.org/t/raspberry-pi-5-octoprint/60487/2

@engikeneer thank you very much, then I will just print a few tests

@jay_s_uk
wow, thank you so much! That was the solution, now I just have to figure out the input shaping....have a nice Sunday, cheers, Don