Core XY movement issues
-
@t3p3tony
Hi Tony, Thanks for posting. I would like to be sure about what you are asking me to do.
At this time I have done the testing as per the docs.
G91 G1 S2 X100 F3000 ; MOVES X+ AND Y+ , as it should
G91 G1 S2 Y100 F3000 ; MOVES X+ AND Y- .
Doing a G90 G1 X100 causes Y to move about 3 mm in the + dir
Doing a G90 G1 Y100 causes X to move about 3 mm in the + dir
After changing * and still at M92 X320 Y319 doing the above,
the X only moves when the same command is sent, same as when the Y command is sent.
I have physically swapped the A and B motors, And with the M92 X320 Y319, it behaves normally. With M92 320 Y320, it reverts to Y moving a bit when moving X and vice versa. But the new A motor went to the A connector. So that is where my question comes in.
I can tell you what it will do, with the connectors in the correct places, a G90 G1 X100 command will cause X to move 100 to the plus and the Y to move ~3mm to the plus. The same with a G1 Y100.
If I swap the connectors and run it twon't that change the directions of the motors? Will I have to change those settings as well?
Should I set the steps back to M92 X320 Y320 first? Then run G1 X100 and then G1 Y100. Then swap the connectors on the board and then run the same commands, to see what it does before and after? Sorry if I seem a bit flustered, as I am.
RJ -
@fxxtoo I think what you'll need to do to accomplish what Tony is asking is to swap the motor connectors, then re-map the drives. So you'll need to add this to the start of your drive section in config.g
M584 X1 Y0
Make sure you put it at the start of the drive section. Your motor directions are all the same so they should not be affected.
So you'll physically swap the stepper connectors on the board so that what was X is now connected to Y and what was Y is now connected to X. Then by adding that line, it'll swap the drivers so you should end up with exactly the same movement. If you get a different result, then it would indicate a faulty driver.
So to be sure, set the steps per mm the same for both axes. Do the long x move first and note any Y movement, then swap the cables and re-map the drives, then repeat.
-
@deckingman
Thanks. I think we are getting closer.. Should I go back to M92 X320 Y320 for this test? -
@fxxtoo
After Checking Ians points, another idea:The pulleys, do they grind anywhere at each other? This would explain X movement when you move Y and vice versa. They must be separated by washers each and may not effect each other.
-
@fxxtoo said in Core XY movement issues:
@deckingman
Thanks. I think we are getting closer.. Should I go back to M92 X320 Y320 for this test?Yes please
-
@joergs5
No, there are shims to space them all out the same distances to keep them aligned for the belts.
thanks,
RJ -
@t3p3tony , @deckingman
So I got to do the swap test of A & B connectors. I set M92 X320 Y320 and with the cables in the correct position, homed and then did G1 X200, Y moved along with X moving about 3mm. Powered down, swapped the cables , M92 the same and tried the G1 X200 and got the same results. Just for giggles I did M92 X320 Y319 and Did not get the movement in the Y axis when X was moving. It appears to move about 3mm per 100mm move on the opposite axis. I remapped using M584 X1 Y0.
I contacted Filastruder about this and said they were forwarding it to Duet.
What is the verdict?
thanks,
RJ -
If you're swapping the cables and the results are identical, that indicates to me that it isn't the Duet controller, but rather something physical about your printer (belt paths, pulley diameter, etc).
-
@elmoret
It reproduces the error I had from the beginning. When I move X only, using G90 G1 X100, Y moves in the same direction about 3mm per 100mm movement of the X axis. It does that with the cables swapped and remapped as well. The Only time it moves correctly is when I change the steps per mm, ie M92 X320 Y 319. Then the movement in the other axis, stops.
I have already taken it apart and redone everything. I am pretty sure this is not a mechanical issue.
thanks for the reply
RJ -
@fxxtoo
What happens if you do 1/16 stepping? Just wonder if you get the same difference or another distance. Sure all the pulleys are the same? Might also be something with one motor of course. Have you tried mapping the other drivers to the xy? -
Would it be possible to try both extruder drivers on xy. Then run G1 E0100 E1-100 to see what happens then? Just thinking out loud..
-
@fxxtoo said in Core XY movement issues:
It does that with the cables swapped and remapped as well.
Right - which is why I'm saying it isn't a controller issue. Behaving identically when swapping stepper motor drivers tells me it isn't the stepper drivers or the pulse trains driving the stepper motor drivers (the microcontroller).
But Tony and dc42 are more knowledgeable than I at this.
-
@t3p3tony, @pro3d , @deckingman
Well I think I might have discovered the problem. I had a M350 command in my config.g file, before my M92 command. Reading some things that dc42 had said about microstepping and pr3d said about trying lower microstepping rates. So I moved the M92 X80 Y80 ahead of the M350 and started playing with that. It appears that might have caused my problems. I will play and post the results... I hope that is all it is..
rj -
PROBLEM SOLVED....
To all that have tried to help me, I want to say thank you to all of you. Turns out that I made a silly mistake in my config.g. dc42 posted , you should put the M92 command before and the firmware will take care of the M350 when it sees it based on your M92 settings. If this can help someone else from making this mistake or helps some one figure out whats wrong, then the past month of frustration will be worth it. Thanks again for the support...and the patience for a noob.I made a choice between one of two boards for my printer. I most definitely choose the right one.
thanks,
RJ -
@mrehorstdmd , @JoergS5
The spacer is milled to the thickness of what the factory specs said for the distance from the rail to the top of the bearing surface. So Its in the same plane all the way across. The piece on the outside is the Y adjuster for the home switch.
RJ -
@fxxtoo That's good news, congratulations! One advantage of all this effort is that you know your printer very well now. Now relax and enjoy printing.
The finding is valuable information and will help others in the future.
And respect, that you had the patience to fight through it!
-
@fxxtoo Hm, you get M350 before M92 if you use configurator. So that is also a problem with it.
-
@fxxtoo said in Core XY movement issues:
PROBLEM SOLVED....
To all that have tried to help me, I want to say thank you to all of you. Turns out that I made a silly mistake in my config.g. dc42 posted , you should put the M92 command before and the firmware will take care of the M350 when it sees it based on your M92 settings. If this can help someone else from making this mistake or helps some one figure out whats wrong, then the past month of frustration will be worth it. Thanks again for the support...and the patience for a noob.I made a choice between one of two boards for my printer. I most definitely choose the right one.
thanks,
RJErr, well I glad you've solved your problem but something is very amiss. Whether M350 comes before or after M92 should result in the same thing providing the steps per mm match the micro-stepping setting - see here https://duet3d.dozuki.com/Wiki/GCode#Section_M350_Set_microstepping_mode
Just for the hell of it, I tried both ways on my CoreXY and in both cases I get no Y movement when I ask for an X movement. I'm still on a earlier version of firmware (1.20.1 RC2) so maybe you've found a bug in later firmware???
-
This post is deleted! -
@deckingman there is a comment in the cartesian type docu:
The M92 commands to set steps/mm should either come after any M350 command to set microstepping, or else the M92 parameters should be correct for the default x16 microstepping. This is because when you change microstepping, the steps/mm are automatically adjusted to take account of the change in microstepping.
https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter
Maybe the information helps. But the original config setting would be ok after this description.