Duet 3 Hangs, Nema23 issues

T3P3Tony

If you connect using DWC then when you send M122 you will see the whole output.

You mention being able to get higher speeds using external drivers. What drivers at what settings?

70mm/s at 800 steps/mm is a step rate of 56KHz which should be ok on the 1XD running RRF 3.3 beta with the default timing of "fast". Its marginal with T=1 and too high step rate with T=2.5 or higher. This can be confirmed by sending

M122 Bnnn

where "nnn" is the address of the 1XD board. Send this once the print has been running for a while to confirm there are no hiccups.

For the 6HC mainboard that step rate is not an issue unless you have a huge number of very tiny moves in the file, once again use M122 to report any issues on the mainboard.

Please post your M122 output in full, config.g and an example gcode file.

JayT

@T3P3Tony : Thanks Tony. I shall try that. For the current print, i saw hiccups as non zero(>100 value) for both the axis. What do hiccups mean ? What action can be taken to reduce hiccups?
I will send config, M122 info and sample print by tomorrow.

dc42

@JayT, you should be able to achieve the same speeds with the Duet internal drivers as with the external drivers if the driver VIN voltage, load, speed, acceleration etc. is the same in both cases. If the external drivers run at a higher VIN voltage than the Duet accepts (e.g. 48V), then they will support higher speeds than the Duet does.

One possible difference is how the current is set. The M906 command in RRF sets the peak current. The switches on your external drivers may set RMS current - check the documentation for details. When microstepping, peak = 1.414 * rms.

JayT

@dc42 : VIN is same 32V (with or without external driver), load conditions are same too. External drivers run as 2.03 RMS (2.84 Peak). micro stepping 1/8, so 400steps permm.Also it ran well for 2 hours @ 50mm/s, 200 mm/s2, vi 5mm/s
a) Based on reply, Keeping all things same, With onboard MB driver, 2400/2800mA on MB 6HC, the motor makes noise and hangs/skips. it runs this motor with only 800mA (tried with diff current settings) upto certain speed and acc . it's a motion king motor 23H2A2430. (6.8mH).

b) Used impulse double stack with lower impedance of upto 3.6mH. The onboard driver still hangs or skips with higher current.

c) Impulse motor(3.6mH) run well with external driver, since it has lower torque, i provided 3.3 peak current from external driver. I am running a print since 50 mins, so far no hanging issues with speed of 60mm/s, with acceleration of 300mm/s2 , vi =5. Since its smaller, with low impedance, with lower back emf, it is able to pull for higher acceleration unlike bigger motor with 6.8mH impedance , right?

Any suggestions why conditions a & B occur with onboard drivers. ?

Note: No hiccups. seen with external drivers at 1/8 microstepping. at 1/16 there were few.

JayT

a) With Onboard Drivers, @24-32V supply, the motors hang with current >1A. Even if the low impedance motor is connected, it does not go beyond 40mm/s and hang if current set via 906 is >1-1.5A.

b) With external drivers, the same motors can run upto speed of 70mm/s and acceleration 100-500mm/s2. If motors are provided 48V(instead of 32V), the motors run well upto 80+ speed @300mm/s2. Few prints passed since then.

How to debug onboard driver issue here?
the least I think I should be able to set is >1A current with onboard and it shouldn't cause more skipping, hanging for long run.

P.S, : Motors show no hiccups with onboard/external dirvers @1/8 microstepping.

onboard motor & config details @32V:
motor in use: IM57HS76-2804-62
Config:
M569 P0 S1 ; physical drive 0 goes forwards
M569 P1 S1 ; physical drive 1 goes forwards
M569 P2 S1 ; physical drive 2 goes forwards
M569 P3 S1 ; physical drive 3 goes forwards
M584 X0 Y1 Z2 E3 ; set drive mapping
M350 X8 Y8 Z16 E16
M92 X400 Y400 Z800.00 E415.00 ; set steps per mm
M566 X180.00 Y180.00 Z120.00 E120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X3000.00 Y3000.00 Z1800.00 E1200.00 ; set maximum speeds (mm/min)
M201 X100.00 Y100.00 Z55.00 E250.00 ; set accelerations (mm/s^2)
M906 X1000 Y1000 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
gcode: up_heart_70mm.gcode

dc42

@JayT said in Duet 3 Hangs, Nema23 issues:

a) With Onboard Drivers, @24-32V supply, the motors hang with current >1A. Even if the low impedance motor is connected, it does not go beyond 40mm/s and hang if current set via 906 is >1-1.5A.

In what way do the motors hang? Do they just stop, or squeal, or something else?

JayT

@dc42 said in Duet 3 Hangs, Nema23 issues:

something else?

Motor skips steps, makes noise. And the moment we reduce current to 800mA , it runs ok at lower speed . So its like we can feel the motor is trying to rotate but stuck, with the noise.

dc42

@JayT said in Duet 3 Hangs, Nema23 issues:

@dc42 said in Duet 3 Hangs, Nema23 issues:

something else?

Motor skips steps, makes noise. And the moment we reduce current to 800mA , it runs ok at lower speed . So its like we can feel the motor is trying to rotate but stuck, with the noise.

Have you tried using a different driver output, in case there is a fault in the one you are using?

JayT

@dc42 :
Yes.
Following is what I tried:

I tried switching the driver output.
Tried to replace the board with a new Duet 3 in spare. and checked. Then Phaedrux suggested to upgrade so I went to 3.2 version. Upgraded that too.
I also tried to give 2000mA, and ran the motor in free mod, It runs. Problem comes when I attach it to the axes.
I also tried to give 24 V then 32 V supply.

Same load with same motor runs well with external driver. Is it possible that the onboard TMC driver is not compatible with the motor in use?

dc42

When you run the motor and it stalls, if you then run M122 what lowest VIN voltage does it report? The fact that it runs better at low current suggests that the driver supply voltage could be drooping at higher currents.

Can you confirm that when it was running with external drivers, you were using the same PSU to power both the drivers and the Duet (except when you tried 48V)?

dc42

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.

JayT

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

JayT

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

dc42

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

JayT

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

deckingman

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.

dc42

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

JayT

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

dc42

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.

JayT

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=0

Can you please check if the fix is not ported in RRF 3.3beta1 & other releases ?
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3beta1

P.S. : Reported , to aid integration of the fix in subsequent releases.