Clearpath Servos with 1XD Expansion

[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:

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

2. 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?

[dc42]

@jballard86 said in Clearpath Servos with 1XD Expansion:

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

Possibly, however I hope to fix the pause issue soon, then I can give you new firmware to try.

[jballard86]

@dc42 copy that

[dc42]

I've fixed the pause issue. It turned out that it was only an issue when pausing a move involving drivers on CAN-connected expansion boards.

I've put new main board and EXP1XD firmware at https://www.dropbox.com/sh/9mgsgbbklx09u99/AAAbXwF80zNEtnlIl1jBwV5ca?dl=0. With these binaries, the number of steps reported sent to the drivers is exactly the correct number, after running your complete example print file.

Please can you install these binaries, then:

• Home the printer
• Send G1 X0 Y0
• Run M122, M122 B40 and M122 B41 and save the results
• Temporarily remove all homing (G28) commands from the print file, start.g, stop.g and cancel.g
• Run part your test print
• If it appears to be shifting, pause it, then send G1 X0 Y0, then (after movement has stopped) run M122, M122 B40 and M122 B41 again

[jballard86]

@dc42
Absolutely:
I removed Homing from the gcode file, but I dont have a start,stop, or cancel.g

here is the console text, there was one instance where I didnt do a G1 X0 Y0, but you will probably see that. It looks to me that the 1XD boards are receiving and sending commands correctly. please verify my observation. console.txt

Here are the current ratings of the clearpaths:
5 VDC - Min 8 mA
12 VDC - Min 9 mA
24 VDC- Min 12 m

All of the pins are rated at 10ma/Pin, what is the max of the 5v common?

If that sink current is limited by a resistor its very possible that we could be under 8ma@5v if using a 5% @ tolerance resistor @ 10ma Max per pin.

@Teknic_Servo any info you can add to this?

[dc42]

Thanks for the info. It looks to me that board 40 and 41 report drive positions 1000 and -123388 respectively both at the start and at the end, which is what I expect if the commanded start and end positions are the same and there have been no homing moves in between that could reset the origin.

If the Clearpath drivers draw 8mA at 5V, that's similar to a resistive load of 620 ohms. I'll verify the 1XD output voltage with 620R load resistors. In theory the step and direction outputs should provide minimum 4V typical 4.5V with a 20mA load.

[dc42]

I've checked the outputs from the 1XD board with 620 ohm load resistors, using your configuration (M569 P40.0 S0 R0 T2.7:2.7:2.7:2.7):

• The signal amplitude is 4.8V
• The step pulse width ls never less than 4.1us
• The smallest interval between step pulses I saw was more than 100us
• The end-of-step-to-direction-change hold time looks consistent at 8us, however direction changes are not very frequent so it's hard to be certain that there are no shorter ones
• The direction-to-step setup time appears to be very long indeed

Here's an example of a step with a direction change afterwards. The 'scope is looking at the STEP- (yellow) and DIR- (blue) output pins of the 1XD, with the 620 ohm load resistors connected between those outputs and the common +5V output.

PS:

1. The voltage across the 620 ohm resistor connected between Enable- and +5V is a little lower, 4.78V. This is expected, because that pin is not driven by a high current drive pin of the microcontroller. But it should still be enough, because few device providing 5V output signals would provide more than that.

2. Please confirm that you have connected the ClearPath A+/B+/Enable+ inputs to the common +5V pin on the 1XD board, and the ClearPath A-/B-/Enable- inputs to the individual output pins.