Clearpath Servos with 1XD Expansion

dc42

The max step rate reduces as you increase the step pulse width and interval. So set the M569 T parameters to the minimum values given on the datasheet for the drivers.

8000 pulses per rev is equivalent to 8000/200 = x40 microstepping. So reducing pulses per rev may be advisable.

Use M122 to report the number of hiccups on the expansion board. High values indicate that the 1XD cannot maintain the requested step rate.

jballard86

@dc42 towards the end of my testing with the servos I had dropped down to 3600/rev and hiccups were in the single digits usually 1 or 2

pulses were setup at 2.7:2.7:2.7:2.7

still had shifting

jballard86

@dc42 Know of any other users running step/dir servos using the 1xd with no issues?

dc42

Please check for hiccups in the M122 report for the 1XD board as I requested before.

jballard86

@dc42

I did, it would read 0-2 hiccups yet it still shifted consistently. Hiccups went down as I reduced the the resolution of the servos, and still I had layer shifts. I did a M122 dozens of times with the same results

Or are you asking for something else in particular? After this hurricane hits tomorrow night I plan on putting the Servos back in for some more testing, and ill do another M122 that will result in 0-2 hiccups again.

@jballard86 said in Clearpath Servos with 1XD Expansion:

@JoergS5

at low speeds, no retractions, no fan the hiccups are minimal: 0-2.

Ive also reduced the servos to an 18x microstepping equivalent (3600 counts/rev), with no change.

Ill also have to say that even at low speeds im still getting a shift on every layer its just significantly less pronounced.

Ive also tested without the bed heater on, no change. I thought there may be interference.

JoergS5

@jballard86 I would try to isolate the problem. eg it seems that only one axis or diagonal ( in both cases it could be one stepper if its corexy) is the reason. So only one 1xd if its the board. So to verify you could exchange the two boards and check whether the axis changes also. If not, it could be a different reason. Did you check hiccups of both boards? I don't know the 1xd boards, but is there something special to do for the CAN termination?

You could use P3 for a normal stepper for x or y and check whether one of the two 1xd is faulty and whether it is a problem which only occurs with two 1xd boards. I know, this is some work, but isolating the problem is Imho the way to have a chance.

dc42

I am working again after a short holiday and I have time to look into this today. What is the simplest way you know of to reproduce the problem? I don't have any servos, but I have two 1XD boards and external stepper drivers.

You said:

The problem is not reproducible while other steppers are not operating. I made a simple gcode file with about 50 moves, many of them with 1mm oscillations and then return to home. After running the code dozens of times no change in origin for the duet or servos was noticed.

If you run a test file that does small oscillations on two drives at the same time, does the problem occur?

Perhaps a test file that does a complete number of circles would reproduce this, i.e. the servos should end up at the same position as when they started, but don't? If you don't have a suitable file, the one attached may help.

circleHighDef-2mm.gcode

jballard86

@dc42 in my experience yes

jballard86

@dc42 im at work and can't look at that gcode file, but if it does t use steppers attached to the main duet 3 as well it wouldn't reproduce the problem.

I did extensive tests of just the x and y axis with no other actions from the duet with and could not recreate the problem. The file I used was about a min long with a high feed rate. It included circles, squares, zip zags, and even a 1mm oscillation. Id run it dozens of times with no errors or hiccups.

But after this hurricane hits us in the Carolinas, im going to put the servos back in and ill do any and every test you want me too, even if I've already done it so that we can figure it out.

Thanks!

dc42

@jballard86, thanks. My test system currently has a Duet 3 main board, 3x 3HC expansion boards, one tool board, and two 1XD boards. So a config and test file that can reproduce the problem on that setup would be very helpful.

jballard86

@dc42 when I get off later ill send the config file I was using with the servos, and the test print i created that consistently produced the failure.

jballard86

@dc42

config.g This is the config used with the servos.

Short move stress test.stl I designed this simple tower/gear type object to have constant changing directions. It gave me consistent issues with the servos.

I was running at an equivalent 18x microstepping in the later tests and 40x in the first tests.

jballard86

This post is deleted!

jballard86

@dc42

here is a more up to date config, that is actually printing right now (with shifting) config (1).g

and here is a the console output after running a few M122 commands for the 1XD boards and the main Duet console.txt

This was while printing the standard Benchy model. no hiccups at all. But plenty of shifting, there are no skipping/slipping belts.

dc42

Thanks, I am about to see if I can reproduce the problem using your files.

dc42

I have added some additional diagnostics to the firmware. When I run your test file, then pause the print and command movement to the origin, the motor position reported by the EXP1XD board is not as expected. I suspect that some movement commands are being lost in transmission from the main board to the expansion board. I have not yet identified how or where they are being lost. I will continue this investigation tomorrow.

jballard86

@dc42 im glad that im not crazy lol. Ive got full faith in you figuring it out!

thanks!

dc42

@jballard86, you might like to try installing the 1XD firmware binary at https://www.dropbox.com/s/eyc4sktkpysoo4g/Duet3Firmware_EXP1XD.bin?dl=0. In this build, the M122 report for the expansion board includes the absolute motor position (number of steps from the original position) calculated by accumulating all the movements done. That reported motor position should bear a fixed relationship to the XY coordinates, until you execute a homing (G1 H1) move.

What I do is:

Send G92 X0 Y0 Z0 to pretend-home the test rig
Check that M122 B40 and M122 B41 report the motor position as 0. If you do real homing, then the positions won't be 0.
Execute a few simple moves; then do G1 X0 Y0. The positions reported by M122 B40 and M122 B41 should then be the same as when the printer was previously at X0 Y0 (both 0 in my case).
Start printing your file
Pause the print, then send G1 X0 Y0 again.
Send M122 B40 and M122 B41 again. Your tool XY offsets are zero, so the motor positions should be zero again (in my case); but unless I pause the print very close to the start, they are not.

jballard86

@dc42 I had done a similar test by compairing the reading from the servo encoders. However I have installed the firmware and here are my results:
B40 9999 10040 10040 9855 10024
B41 -53195 -116286 -116286 -116087 -116257

definitely collaborating your results.

dc42

Just to let you know that I am still looking into it. I already identified several possible causes, but each time I added debug to check whether that was the problem, the debug indicated that it wasn't.