Clearpath Servos with 1XD Expansion
-
@jballard86 your layer shifts look interesting...
One remarkable detail is that the shift is of the kind if it shifts, left and right shift to the same direction. So the shift is not due to a lower print distance.
One reason for layer shifts are print bed shifts, but when you get less shifts with lower speed, so this is unprobable. Can you exclude this possibility? (how good is your Z movement system?)
The next possible reason is that the nozzle touches the object while layer change and moves it. There is something called Z-hop in the slicer to take the nozzle away.
One possible reason, not probably not in your case but I want to mention it, is that something is in the way for the actuators, like cables, which disturb the movement.
One intersting detail in your image is that there are multiple layers shifting into one direction, then multiple layers shifting into the other direction, but different number of shifts for every direction. There must be a reason for this. If we found the reason, we know the solution!
It would be interesting to make a test at layer change, whether the coordinates are still correct, but testing the values at the endstops.
-
Z axis is remarkably stiff, z rails, kinematic mounts, all aluminum, mounted to 1"x2: aluminum bar for increased rigidity.
Never had good luck with zhop in the 10+ years ive used 3d printers. so Zhop is disabled.
Nothing is disturbing movement, besides the clearpath software would give me an error if there was an over torque situation, which would indicate that there was a collision of some sort in this type of scenario.
but you are right, the shifts are interesting. Ive taken everything out of the question that is unnecessary for a print to print (albeit ugly), Ive verified that the servos are not missing steps, ive modified accelerations, jerks, speeds, etc with no change.
I know that for some reason there is a pause on the 1XD boards when there is a layer change where the servos actually go into an idle mode.
ive deactivated the bed heater (110v) encase it is causing interference, ive checked that all cables are not ran next to a cable that would cause issues with interference.
This problem is firmware, hardware, or interference related.
-
-
I have tested after a series of layer shifts:
After Homing
Duet (0,0)
Servos ( 3574, -426)After a few layer shifts
Duet (0,0)
Servos (3500, -417)The servos know where they are and the Duet thinks it knows where it is, but it has had something happen in communication or elsewhere that causes it to loose its actual location (im thinking it has to do with the 1XD boards)
-
@jballard86 I have thought about why the direction of the layer shifts is different. Maybe it is because the fast movement to the begin of the new layer is from left to right or right to left. Did you check that the steps/mm are all correct? And if layer changes, is there something special in the G-Code like using G0 instead of G1, different speeds or something other special?
You can insert a macro at layer change to verify if the coordinate system is still correct, testing the positions at the endstops. There is a thread somewhere in the forum to test endstop at every layer.
=> our posts crossed again
Our thoughts are in the same direction, that the coordinates change at the layers. -
@JoergS5
Its a core xy setting steps/mm is irrelevant, you use the Mcode to scale the x and yTesting at later change could give some interesting results but I'm using hard stops, so not viable if the shifts are in the wrong direction. And as I can't log both servos count position at the same time and have to swap cables it could take an afternoon or longer to run and rerun tests.
Do you think the servos are loosing position or the duet? Im 100% confidant that it's the duet as I've already shown that.
-
@JoergS5 Post crossing is happening often
-
@JoergS5 I'm adding a g4 s.5 on layer change, I predict it may stop the shift, but is also not an acceptable solution. Results in a few min.
-
@jballard86 M400 before layer change would be a test also. Maybe XY throws a movement away when Z move starts.
-
-
@JoergS5
still shifting with m400 and g4 s.5 -
@jballard86 at the moment I don't have additional ideas. I will think about and tell you when I have a new one.
-
This is interesting, it had shifts mid layer on the skirt
I'm out of ideas as well, maybe @dc42 can give some more input.
-
@jballard86 slip through of the belt to the pulley is a possibiltiy also, but you would hear it. But I don't know how to verify it.
-
@JoergS5 an I am unfortunately aware of that noise from when I was setting up hard stop homing
-
Hi. This may be long-shot, but...have you check that all ClearPath motor has the exact same RAS setting, and that the motor are not set to "Auto RAS"? Keep the RAS setting fairly low, like no more then 25mS (mine only let me set maximum 16mS which work OK fine for me. But make sure the RAS values match exactly the same. Good luck with print machine!
-
I had the same exact problems on my JMC servo,
I guess you are not using the duet expansion breakout board? That fixes it.
You need the 5V logic for the steps to arrive properly, the 3.3v logic from the mainboard is enough to trigger some steps to run normally but not all of them.So yes you need the expansion breakout board. here is my thread on it
https://forum.duet3d.com/topic/8948/3-3v-logic-for-5v-servomotor-optocouplers -
@NitroFreak the 1XD produces 5V level signals so i don't think its that.
@jballard86 Can you do a simpler test to try and reproduce the missed steps (if it is that that is causing the shifts). Do the servos have an interface where you can see the ticks received, or work those out from movement received? try just a movement of a set distance back and forth between two points (without printing).
-
@tae-wimju Both have the same RAS setting, I actually turned it to none on both servos to rule out RAS early on.
-
@T3P3Tony 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.
Im pretty sure that the issue has to do with communication between the duet 3 and the 1xd boards.
Ive thrown some steppers in place of the servos temporarily.
Any other good tests I could do? to help narrow the issue down?
