Duet2 wifi - external drivers - deltabot - Z tower delayed issue
-
Hi there. I've got a very large deltabot (5' tall x 3' print radius, E3D volcano hotend) running Duet2 wifi with the most recent firmware. I'm using 3 external integrated stepper/servo motors (Teknic SDSK-2310S-EQN). These are connected directly to the step/en/dir outputs P6, 7 and 8 on the expansion header, and for the 3 drives combined I'm providing them +5v from pin 1 of the expansion header. These motors were a total pain to calibrate (using the Teknic MSP configuration software) so that they didn't jerk like crazy, but I've got them running smooth as butter. All 3 are using the same MSP configuration settings. These motors were working well on Smoothieboard before I converted to Duet. IE; the issue I'm about to describe was not present until I converted to Duet2.
The problem is that although the print job starts out with the bed acceptably level and the two outer perimeters of the print are very consistent in height around the entire perimeter of the print, before the first layer infill is completed the area nearest the Z tower starts getting thinner and thinner, until the hotend is just dragging the bed. But this does not happen near towers X and Y. Only the Z tower.
The issue is repeatable... Other files too. Not the gcode.
Below is the side of the print nearest the X tower. It's obvious that the infill overlap is going deeper across the inner perimeter layer the further it prints.
Next, the side of the print nearest the Z tower. Here you can see that the perimeter layer height is spot-on, it's only after a while that the Z motor goes 'lazy'
Note: I've been building and using deltabot printers since Johann Rocholl released the first Rostock model 7 years ago. During that time I've built over 50 regular-size deltabots and 5 of these Gigante models. I'm very new at using the Duet/RRF combo, but I'm loving it for the most part. This is the first instance I can recall of a printer slowly losing calibration on only one tower during a print. I'm Stumped!
I'm prepared to contact Teknic tech support next, because I'm leaning towards this being a drive failure of some type, but I thought I would hit up the collective brain power here just in case there are some ideas for what might be happening.
Could the Teknic SDSK stepper electronics need a better 5v source than is supplied from the Expansion Header? Each motor draws 7.5mA for electronics.
Here are the relevant config.g settings
M665 L963.798:963.798:963.798 R447.568 H1305.350 B390.0 X-0.498 Y-0.387 Z0.000
M666 X-0.205 Y-0.041 Z-0.247 A0.00 B0.00; Drives
M569 P6 S0 T1.5:1.5:0.25:1
M569 P7 S0 T1.5:1.5:0.25:1
M569 P8 S0 T1.5:1.5:0.25:1M569 P3 S0 ; Physical drive 3 goes backwards
M584 X6 Y7 Z8 E3 ; Apply custom drive mapping
M350 X16 Y16 Z16 E16 I0 ; Configure microstepping without interpolation
M92 X213.33 Y213.33 Z213.33 E496.00 ; Set steps per mm
M566 X4200.00 Y4200.00 Z4200.00 E1200.00 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z18000.00 E1200.00 ; Set maximum speeds (mm/min)
M201 X2200.00 Y2200.00 Z2200.00 E1000.00 ; Set accelerations (mm/s^2)
M906 X300.00 Y300.00 Z300.00 E800.00 ; Set motor currents (mA)
M84 S0 ; Disable motor idle current reductionHopefully the answer is evident to someone. Thanks!
Steve Graber (grabercars)
-
Steve, those images are not showing up for some reason. you can drop images directly into the forum post if thats easier.
Regarding the issue. Possibilities that come to mind:
- The step timing for external drivers can be critical - it could be that the timing you have chosen is marginal for these drivers and the Z one is occasionally missing one - although with the nature of deltas' you would think that could result in very unpredictable errors, rather than a consistent lowering (i.e if it was missing random steps then it could just as easily end up going higher on the Z side rather than lower).
- The driver is failing/does not have enough torque to raise the carriage so its skipping steps on that side.
Would it be worth rotating the drivers to confirm the problem follows that driver? Also possibly worth increasing the step timing to see if that fixes it?
-
T3P3Tony, thanks for your reply. And thank you on behalf of everyone that you help here. I can see you're a busy guy!
I've tried changing step timing to M569 P8 S0 T2.5:2.5:0.5:1 as well as M569 P8 S0 T3.0:3.0:0:0 and it did not make a difference. How far can the timing be taken? FYI the step/dir/enc wiring length to the Z tower is approx 70cm, compared to ~40cm to the X and Y tower motors (due to the location of the electronics.)
Yes, the confusing part is that it always loses Z tower calibration in one direction. Leading me again towards suspecting that motor hardware.
I do need to swap the Enc/Step/Dir wires to see if it follows, and one of the other things I was going to try after that was to physically swap that motor with say, the X tower motor and see if it follows. That will probably tell us a lot.
Finally, it occurred to me last night that I really need to get the Teknic MSP app connected to the back of that motor via USB and review the oscilloscope traces and amp draw of that motor, maybe compared to one of the functional tower motors. The MSP software has a lot of diagnostic capability.
So I have at least a couple of hours of debugging left to go.
Here are those images. My apologies.
This is a closeup of the print nearest the Z Tower. Notice the perimeter layers are fine, but by the time the hotend comes back around to lay down the first layer infill, the nozzle has dropped significantly. (1.6mm is the measured drop by the point the print is cancelled).
This is a closeup of the print nearest the X tower. The infill overlap is becoming more offset towards the X tower.
Last image. The issue is repeatable. Checking the nozzle height at each tower after canceling the print shows the Z tower down by 1.6mm at this phase. X and Y towers nozzle height is still spot-on.
-
I did find an interesting thread with a similar problem here on the Google Deltabot forum which if you read between the lines might point towards this being a step-pulse issue.
For posterity here is the step and direction timings for the Teknic SDSK step-dir motor.
This would seem to indicate M569 T values of: 1uS minimum step pulse, 1uS minimum step interval, 0.025uS DIR setup time and 1.0uS dir hold time?
Maybe I should try M569 P8 S0 T3.0:3.0:1.0:3.0
-
Yes, having direction hold time set too short may result in one step going the wrong way whenever the direction is reversed.
-
Unfortunately that did not resolve the issue. I'll be in front of the machine tomorrow and will swap the motor control wiring first to see if the issue tracks or if it stays on the z tower.
-
Last evening I switched out the motor and endstop wiring (physically moving the tower mapping to X=Z, Z=Y and Y=X) and ran the same print. The error stayed with the original tower even though it is now mapped to believe it's the 'X' tower. I then interfaced with the motor using the Teknic MSP software and using the 'scope function it appears that the motor is actually losing positioning early in the move and never recovers. Because it was getting late and it was not at my shop I didn't delve into the exact number of steps it's losing. It's just strange that it loses that positioning in one direction only.
In any case, I don't think this is a Duet hardware or firmware issue and I'll be contacting Teknic for an RMA.
Regards to all and thanks to you guys for developing such a configurable controller. Overall I'm extremely happy with its performance on my most recent printers, and I've begun retrofitting some older ones too.
-
@grabercars glad you have narrowed it down!
