Clearpath Servos with 1XD Expansion

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.

jballard86

@dc42 Curious, do you think the same issue occurs on the tool board? but is less noticeable due to it driving an extruder?

Also Im trying to think of an easy way to remove all commands from the Gcode except for X/Y movement, as id like to do that same debug test with only the X and Y axis operating. Because earlier testing led me to believe that the issue was occurring during elevated processor usage on the Duet 3.

In my earlier screenshot of the Clearpath "oscilloscope" it looked as if the Servos and the 1XD boards had a slight pause in receiving commands while the Duet was doing something, this pause was between 150 and 250ms. I would notice it during Wipes, Z axis changes, and Part Cooling fan changes.

I have no idea if this is on the right track or helps you at all though.

dc42

@jballard86 said in Clearpath Servos with 1XD Expansion:

@dc42 Curious, do you think the same issue occurs on the tool board? but is less noticeable due to it driving an extruder?

I suspect that is the case.

Also Im trying to think of an easy way to remove all commands from the Gcode except for X/Y movement, as id like to do that same debug test with only the X and Y axis operating. Because earlier testing led me to believe that the issue was occurring during elevated processor usage on the Duet 3.

In my earlier screenshot of the Clearpath "oscilloscope" it looked as if the Servos and the 1XD boards had a slight pause in receiving commands while the Duet was doing something, this pause was between 150 and 250ms. I would notice it during Wipes, Z axis changes, and Part Cooling fan changes.

I would expect there to be a break in X and Y steps during Z movement, and also during extruder retract/reprime moves.

I have no idea if this is on the right track or helps you at all though.

It would certainly help to have a simpler test file that reproduces the problem immediately. I tried a file that does a large number of short X movements, with occasional reverse movements and Y movements. It didn't show the problem, even when X was mapped to a local driver as well as the one on the 1XD.

jballard86

@dc42 increase the speed and micro stepping. It happened significantly faster with higher speeds and step rates.

dc42

@jballard86 said in Clearpath Servos with 1XD Expansion:

@dc42 increase the speed and micro stepping. It happened significantly faster with higher speeds and step rates.

Thanks, I'll try that.

I may or may not have reduced the occurrence of the issue with changes I have already made, but right now my debug is suggesting there is a problem even when not using drivers attached to expansion boards.

EDIT: looks like there are two separate problems:

The problem you reported. I may have fixed that; or it may be a totally separate problem to do with the step pulses sent to your servos drivers not meeting the minimum timing, or the drive current from the 1XD board not being high enough.
The problem I am chasing, which occurs when I pause a print that has a lot of small segments, even if all motors are attached to the main board. I can reproduce this using a file I constructed to try to reproduce your issue. If I let that file run to completion, the shift does not occur.

At this stage I don't know whether I have ever reproduced issue #1, because I have only ever found an issue by pausing the print and then looking for a discrepancy in the number of net steps. I will resolve issue #2 and then make new files available for you to test.

jballard86

@dc42

#2 is interesting.

Would it help if I hook up some external 2209 or 5160 drivers to the 1xd boards and swap in some steppers to see if the results change?