Duet 3 Hangs, Nema23 issues
-
PS one other possibility I can think of is that the external drivers you are using are quite smart, and they reduce the acceleration or advance the current when they detect from the motor back EMF that the motor isn't keeping up. Some drivers use DSPs to monitor the back EMF.
If that's the case, then you would need to reduce acceleration when using the drivers on the Duet.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 : I guess the external drivers are smart. As with 32V i was able to run till 70mm/s with 100mm/s2-150mm/s2 acceleration (with upto 100 mm/s2 less fails). So when you had mentioned of different voltage to external driver, I connected 48V. Now it ran 3 prints at v=85mm/s, a= 300mm/s2 config. Gcode generated with CURA used the option of proportional speeds for different infills.
-
@dc42 : Yes PSU was same for duet and external drivers : 32V when motor stalled. Even with onboard driver same PSU was used & axes stalled with >800mA current.
For M122 report, I will try onboard again and send you the lowest VIN that Duet reports.
-
@JayT, I think I know what the problem is. The code speed increase in RRF 3.2 on the MB6HC compared to previous released means that the step pulse width required by the TMC5160 is not always met when the step rate is high. I already fixed this in the 3.3beta firmware, and I have just back-ported this fix to RRF 3.2.1. The 3.2.1 release is currently undergoing testing.
You may wish to try using the internal drivers with those motors running RRF 3.1.1. Alternatively, if you are feeling brave, you can try the candidate 3.2.1 binaries at https://www.dropbox.com/sh/1lwimb98k6hzz3z/AAApVr_P6roUjnya4riDbGAba?dl=0. The release notes are at https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.
-
@dc42 : All these reportings are w.r.t RRF v 3.2 and also RRf 3.3 beta. I had upgraded to 3.3 beta while using expansion boards , and found same observation when tried internal drivers before initiating discussion with you .
Can you cross check in 3.3 beta once if the fix is pulled in this version?What I can confirm is the below:
a) the setup is able to pull speed upto 70mm/s with 300-350mm/s acceleration , with Expansion board and external driver when given 32V and can pull upto 85mm/s if 48V is provided to external motor drivers .b) However, with internal drivers, I am not able to drive > 40mm/s , the motor hangs or skips with noise. I am not able to give more current either to increase torque. >1A current stalls the motor too.
Both cases firmware version is RRF 3.3beta.
-
Just as a data point. My CoreXYUVAB uses Nema 17s for X&Y which are set to 1.8Amps and are connected to an expansion board. The UV gantry uses Nema 23s set to 2.4Amps and these are connected to the 6HC main board. The AB gantry uses Nema 17s set to 1.8 Amps and connected to the main board. Supply voltage is 27V and all motors use internal drivers.
I have done very little printing with RRF3.2 because of other issues. But I have managed a few prints and not observed any of the problems that the OP is reporting. The prints were done at 80mm/sec with non print moves at 350 mm/sec. Acceleration is set to 2000 mm/sec^2. -
@JayT said in Duet 3 Hangs, Nema23 issues:
@dc42 : All these reportings are w.r.t RRF v 3.2 and also RRf 3.3 beta. I had upgraded to 3.3 beta while using expansion boards , and found same observation when tried internal drivers before initiating discussion with you .
Can you cross check in 3.3 beta once if the fix is pulled in this version?What I can confirm is the below:
a) the setup is able to pull speed upto 70mm/s with 300-350mm/s acceleration , with Expansion board and external driver when given 32V and can pull upto 85mm/s if 48V is provided to external motor drivers .b) However, with internal drivers, I am not able to drive > 40mm/s , the motor hangs or skips with noise. I am not able to give more current either to increase torque. >1A current stalls the motor too.
Both cases firmware version is RRF 3.3beta.
@JayT, there have been many unofficial 3.3beta builds made available. Not all of them included this fix. So please check with the current unofficial 3.3beta, the one in https://www.dropbox.com/sh/qr98k8fbkj5ue0k/AABPawUF99QVzDrheBQBDSxia?dl=0 dated 1 February. The fix is also in the candidate RRF 3.2.1 at https://www.dropbox.com/sh/1lwimb98k6hzz3z/AAApVr_P6roUjnya4riDbGAba?dl=0.
-
@dc42 : Hi David. I have verified , the binaries are indeed different. I compared them in a tool. Shall try with 3.3 beta from 1Feb and confirm results in a week.
However, can you tell me what is the maximum pulse frequency generated by Duet MB6HC with Duet 1XD with 3 axes running ? I am able to achieve upto 70mm/s - PRINT speed with stepper/servo. I need to understand if that's the limitation of my setup or the board pulse frequency that limits this?
information: pitch 4mm, microstepping 1/8, 400 steps/mm, driven by external drivers. M203 sets 85mm/s speed for XY axis. If i run single axis at 95-100, it achieves that speed. With both axes in movement, it only goes till 70. I verify this by setting fix travel length of say 250 -300 and run both axis/single. -
There will be two limits when using 1XD boards to drive the axes. The first is the maximum step rate of the 1XD. The figures for firmware 3.2 at at https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY. The unofficial 3.3beta firmware is significantly better than the 3.2 firmware in this respect, especially when using extended step pulse timings.
The second limit is the maximum rate at which CAN packets can be sent. This is only a concern when using a long sequence of very short moves, such that several thousand CAN messages would need to be sent every second. Again, firmware 3.3beta is better than 3.2, because it uses shorter CAN packets.
The main board does not generate the step pulses in this scenario, just the CAN packets.
-
Hi David (@dc42 ) :
When I upgraded to RRF 3.3 beta1,*** The prints were shifting
. However, with RRF 3.3 Beta (Feb1) release , the print layers didn't shift with 1XD boards in use. On reverting to this firmware, the system works all ok.Feb1- RRF 3.3 beta
https://www.dropbox.com/sh/qr98k8fbkj5ue0k/AABPawUF99QVzDrheBQBDSxia?dl=0Can you please check if the fix is not ported in RRF 3.3beta1 & other releases ?
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3beta1P.S. : Reported , to aid integration of the fix in subsequent releases.
-
@JayT, try extending the timings a little. The later 3.3beta builds of the 1XD firmware are faster than the earlier ones, so timings that worked with the earlier beta may not work with the later one. In particular, the step pulse width is no longer rounded up to the next multiple of 1.33us but instead to a multiple of (AFAIR) 83ns.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 :
Thank you for the support so far.
we were able to run impulse motors with 1XD boards & run upto 100mm/s travel speed. No issues with the print after upgrade to the firmware as suggested. As observed: the earlier nema 23 motors were working better with external drivers than with the on-board drivers. I believe its because of the smart drivers that compensate for the back emf.(hope so).This thread can be closed as Resolved.
