Core XY movement issues
-
@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.
-
@fxxtoo said in Core XY movement issues:
@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.
rjThat's what's puzzling us all because it works fine for me (and everyone else). The configuration tool is correct and the documentation is correct. If it wasn't there would hundreds if not thousands (depending on how many boards have been sold) of disgruntled users and complaints.
-
@joergs5 said in Core XY movement issues:
@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.
No. The configuration tool is correct and so is the documentation.
-
just my 2ct:
maybe only an effect in Corexy, because only there in CoreXYKinematics.cpp is a CartesianToMotorSteps and MotorStepsToCartesian where rounding errors could occur between int motorPos and the other floats. If you calculate with first, then second function, result will not be 0 as should be with inverted functions.Thesis: In Move.cpp those functions are called for every segment, so more microsteps will sum up rounding errors faster.
-
@joergs5 Well OK but as I said in an earlier post, just for the hell of it, I tried configuring my CoreXY both ways and can't replicate the OPs problem.
