@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
Are they displaying correct on the web control?
What exactly are you seeing on the PanelDue? Photo?
Can you describe the heater layout for the printer?
@chrismbp Okay, that sounds more like the 12V regulator has either failed or is being shorted out. I'd try disconnecting everything from the board (in case it's a short) and see if it helps. I'm not sure if the 5V or 3.3V regulators are fed by the 12V regulator, but if could also be one of those has failed.
As to the cause, I'm not sure. Changing to stealthChop, and having V1000 as the changeover speed to spreadCycle, might have caused the clunk when moving to higher speed travel moves. It's possible if this was fast enough, it may cause an overcurrent situation. See https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_tuning#configuring-stealthchop
A jerk occurs when switching at higher velocities, because the back-EMF of the motor (which rises with the velocity) causes a phase shift of up to 90° between motor voltage and motor current. So when switching at higher velocities between voltage PWM and current PWM mode, this jerk will occur with increased intensity. A high jerk may even produce a temporary overcurrent condition (depending on the motor coil resistance). At low velocities (e.g. 1 to a few 10 RPM), it can be completely neglected for most motors. Therefore, consider the switching jerk when choosing TPWMTHRS. Set TPWMTHRS zero if you want to work with StealthChop only.
It's possible this is what happened. @dc42 might know better the effects of this. Let's see if there's any life in the board with everything disconnected, and go from there.
Ian
@luc Like I said, it's better to use:
CS / PIN 1 SPI_CS2 cavo arancione
INT1 / PIN 3 SPI_CS1 cavo verde
If you add a temperature daughterboard in the future, you won't have to change the wiring when you plug the accelerometer in on top of the temperature daughterboard, only the configuration.
Ian
@p8blr if the axis is flagged as not homed then you can't assume anything about the value of that variable. If the machine has just been powered up or rebooted then it's quite likely to have the value zero. If the axis became un-homed because you disabled the Z motor then it could be anything.
One option is to reduce the motor current while you make that move, so that if it tries to go drop the bed lower than the minimum stop, it won't do any damage. Or you could configure that overtravel switch as the axis endstop temporarily, then use H1 instead of H2 for that move.
For a moment, it looked like you were going to mount a second INDX on the back of the front gantry!
Ian
@luc here under the pictures https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_Accelerometer#wiring-schemes it says:
Note: the pictures above show an alternative wiring scheme, using pin 7 for INT1 and pin 9 for CS on the TEMP_DB connector. We now recommend using pin 1 for CS and pin 3 for INT1 on the TEMP_DB connector.
The pins relate to the pins on the TempDB connector, pin 9 is SPI_CS4, pin 7 is SPI_CS3:
If you have already connected it using pins 9 and 7, you'll need
M955 P0 C"spi.cs4+spi.cs3"
The main problem with using pins 9 and 7 is that you then can't stack the accelerometer on top of a temperature daughterboard, as there would be no SPI connection.
Ian
@Eumldeuml try changing the "Activated edge setting" on the driver. There is an error in the manual pages 13/14 so it isn't entirely clear whether SW5 or SW6 selects this (the other one reverses the direction).
M569 setting T2.5:2.5:6:0 should be sufficient for that driver.
@Triet there is a 2-drive daughter board that provided two extra drivers on the Mini5+. https://www.duet3d.com/duet3expansionmini2plus
@davidjryan it appears to me that it might be useful to have a variant of M400 that only waits for the current motion system to stop (and releases axes).