Core XY movement issues
-
@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.
-
@joergs5 Yes I know that. The link you gave has the same information as the link I supplied.
-
Independent of this thread, isn't it a problem if the two sides of the X axis are not connected stiff? If the tensions of the belts are not equal, there will be torsion forces in my understanding, which could lead to the 3 mm movements.
-
@joergs5 Nope. The belts and motors define the motion. As long as the tensions are set to keep the X axis perpendicular to the Y axis, it will operate smoothly and will not cause any extraneous motion.
If the x axis guide rail weren't there, the motion would still work as it is supposed to.
-
@mrehorstdmd Thanks a lot, this was new to me! This gives me new innovative ideas to build a new printer!
I am thinking about a Corexy with wires, so the hotend needs only the z direction fixed.
-
@joergs5 As @mrehorstdmd said. If the tensions aren't equal then the axes may not be at right angles and the printed parts might no be square. But commanding 100mm of X movement should not make the Y carriage move.
-
@deckingman Thanks Ian. To balance tension, I will try a seesaw, e.g. between the motors.
(after balancing I will fix it) -
@obeliks
In all honesty, I started out with the config.g file from the configurator. In the beginning I wasn't keeping notes, on changes, problems, etc. I didn't notice the issue right away. I discovered it while getting the homing worked out.
So I could have put the M350 before the M92 statement when I started playing with micro stepping. So I would have to go back and use the configurator to find out if that is true or not.
RJ -
@joergs5 Thanks! If it can help someone else to Not do what I did ans save some frustration..Perfect! rj
-
@ everyone
I just found a post that might clarify this subject!! Hope this helps clear it up
Quoted from dc42
Which way round do you have the M350 and M92 commands in config.g?If you have the M92 command before the M350 command, you need to set the steps/mm as they would be for x16 microstepping. When the M350 command is processed, the steps/mm will automatically be adjusted for the new microstepping.
If you have the M92 command after the M350 command, then the values need to be correct for the microstepping you declare in M350.
link to it
https://forum.duet3d.com/topic/2396/calibration/7 -
@fxxtoo I don't understand why order is a problem, because 0 movement of the second stepper is 0, no matter how the microstepping setting is, whether correct or not.
I looked into the source, there are many variables like if it's a smart driver, if there is an additional extruder (bugfix), or whether one motor is stalled (homing).
-
@joergs5 said in Core XY movement issues:
@fxxtoo I don't understand why order is a problem, because 0 movement of the second stepper is 0, no matter how the microstepping setting is, whether correct or not.
.................Exactly! That's why I said something is seriously amiss. The "fix" doesn't make sense (even though it appears to have cured the OP's problem).
-
@joergs5
II haven't looked at the source code, so can't comment on that. I think that the M350 uses the info from the M92 statement as the start of the calcs for the micro stepping. If a M92 comes after the M350 it might not clear something or miss something that the m350 set. Might be a question for dc42 or Tony. -RJ -
@deckingman
Maybe dc42 or Tony can explain this. I just know that my issue went away when I put the M92 for the proper setting for x16 microstepping and then set microstepping with M350, as per the post I read from dc42. Still have a lot to learn about this. -rj -
@fxxtoo maybe your problem reappears when you change to 1/64 stepping, because this was your original setting.
-
Yes I would be interested to see if you can now recreate the problem to verify the fix.
-
@phaedrux , @joergs5
I just tried this in my config.g
M92 X80 Y80 Z80 E420 ; Set steps per mm x80 y80 z175 z80 z85
M350 x64 y64 Z128 ; Configure microstepping with interpolation
;M92 Y320 Y320 Z1400 E420 ;mod to test 64 micro stepping This resulted in the normal movement.
changed to this:
;M92 X80 Y80 Z80 E420 ; Set steps per mm x80 y80 z175 z80 z85
M350 x64 y64 Z128 ; Configure microstepping with interpolation
M92 Y320 Y320 Z1400 E420 ;mod to test this resulted in movement on the Y while doing a G1 x100
So the answer is , Yes I can duplicate it.
Other than my reply earlier, I have no clue why this is happening. I just know that I can move forward now..
RJ -
@fxxtoo you mean, when you use 1/64, the fix does
not work?
work? -
@joergs5 I am not sure what you are asking me.
the first example puts the step rate at 1/16 M92 X80 Y80 followed by the M350 changing the step rate to 1/64 (letting the firmware adjust the steps per mm). This works correctly.
The second example puts the step rate at 1/64 (M350 X64 Y64) followed by the M92 command, which gives the same thing, but spells out the steps per mm. This does not work correctly. Maybe doing it this way causes the firmware to miss a variable or miscalculate the steps due to the order it gets the settings. I am thinking of posting this question to dc42. He might have some knowledge why this happens.
rj -
@fxxtoo thank you for explanation, this was the information I wanted.
So the configuration tool and the two documentations are wrong in this respect. It should be wrong for cartesian printers also.
