Core XY movement issues

[JoergS5]

@fxxtoo maybe your problem reappears when you change to 1/64 stepping, because this was your original setting.

[Phaedrux]

Yes I would be interested to see if you can now recreate the problem to verify the fix.

[FxxToo]

@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

[JoergS5]

@fxxtoo you mean, when you use 1/64, the fix does not work?
work?

[FxxToo]

@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

[JoergS5]

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

[deckingman]

@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.
rj

That'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.

[deckingman]

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

[JoergS5]

@deckingman

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.

[deckingman]

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

[FxxToo]

@deckingman
So your tried this and couldn't replicate the movement? Here is my modded config file, with some notes. Maybe I have messed something else up as well..and just waiting to bite me.
; General preferences
M111 S0 ;DEBUGGING OFF
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P2 ; Set firmware compatibility to look like MARLIN
M667 S1 ; Select CoreXY mode

; Network
M550 PRJPRINT ; Set machine name
;M552 S1 ; Enable network
M552 S1 P192.168.1.99 ;SET IP ADDRESS
M553 P255.255.255.0 ;SET SUBNET MASK
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

; Axis Limits
M208 X325 Y415 Z0 S0 ; Set axis maxima
M208 X0 Y0 Z-600 S1 ; Set axis minima

; Drives M569: Set motor driver direction, enable polarity and step pulse timing Parameters
;M584 X1 Y0 ; test for Ian Swapping the A & B connectors test
M569 P0 S1 ; Drive 0 goes FORWARDS Rnnn Driver enable polarity: 0 = active low, 1 = active high (default 0)
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes forwards
; If I put the M350 command here and comment out the existing M350 (2 lines down)
M92 X80 Y80 Z80 E420 ; Set steps per mm @ 1/16 step rate
M350 x128 y128 Z128 ; Configure microstepping with interpolation
;M92 Y320 Y320 Z1400 E420 ;mod to test 64 micro stepping <----this one will cause the movement on Y while moving x
;M92 X320 Y319 z1400 E420 ; to test to see if it corrects the speed <----This one stops the Y movement while moving x
M566 X600 Y600 Z100 E120 ; Set maximum instantaneous speed changes (mm/min)
M203 X6000 Y6000 Z4000 E1200 ; Set maximum speeds (mm/min) CHANGED FROM 6000 TO 600 Z NO CHG
M201 X500 Y500 Z250 E250 ; Set accelerations (mm/s^2)
M906 X1500 Y1500 Z1500 E800 I40 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Endstops
M574 Z1 S0 ; Set active low endstops
M574 X1 Y1 Z2 S0
;M574 X1 Y1 S3 ; Set endstops controlled by motor load detection

; Z-Probe
;M558 P0 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds
;G31 P600 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height

;M557 X15:327.9 Y15:391 S20 ; Define mesh grid

; Heaters
M140 H1 ; Remap heated bed to heater 1
M301 H1 P-1 ; Set heater 1 to bang-bang mode
M305 P0 X200 ; Configure thermocouple for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 X201 ; Configure thermocouple for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C

; Fans
M106 P0 S1 I0 F500 H1 T45 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P2 S1 I0 F500 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on

; Tools
M563 P0 D0 H0 ; Define tool 0
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

; Automatic power saving
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; Set voltage thresholds and actions to run on power loss

; Custom settings are not configured

[JoergS5]

@deckingman did you try the firmware version FxxToo uses? There was a bugfix in 1.21 for M350, maybe this or another change has an effect.

[deckingman]

@joergs5 said in Core XY movement issues:

@deckingman did you try the firmware version FxxToo uses? There was a bugfix in 1.21 for M350, maybe this or another change has an effect.

Read my earlier post - 18th July 11:44

[JoergS5]

@deckingman

Ok, I will try to understand and compare the different firmware versions and verify whether there are errors in it. My guess is, that processing M92-M350 produces different rounding errors than M350-M92.

You said that a lot of people are using the code and an error would be detected. But if the rounding error is small enough for most settings, nobody will mention, but push it to mechanical deficiencies.

[dc42]

@joergs5 said in Core XY movement issues:

@deckingman

Ok, I will try to understand and compare the different firmware versions and verify whether there are errors in it. My guess is, that processing M92-M350 produces different rounding errors than M350-M92.

You said that a lot of people are using the code and an error would be detected. But if the rounding error is small enough for most settings, nobody will mention, but push it to mechanical deficiencies.

Any rounding errors would be far too small to have this much effect, and when using the same microstepping and steps/mm on the X and Y motors, they would affect both motors equally anyway.

Can you confirm that if you swap the order of the M350 and M92 commands back to your original order, and adjust the M92 values as needed, the problem returns?

[FxxToo]

@dc42
Yes I can. I posted that result here : https://forum.duet3d.com/post/55484
I had found a post that you had done about putting the M92 Xxx Yxx, with the steps set for 1/16 step rate before the M350 command. I changed that and my issue with the Y moving with the X and vice versa, Stopped. I was asked if I could replicate it. I tried and I could. I thought maybe I had something else that could effect it in my config file, so I posted it after I had changed it, leaving the original statements marked in it, obviously commented out.

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later
Firmware Version: 1.21 (2018-03-21)
Web Interface Version: 1.21Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later
Firmware Version: 1.21 (2018-03-21)
Web Interface Version: 1.21
RJ

[JoergS5]

@dc42 how about enable logging M929 (or more) and printing a simple line, this should give information whether the second stepper moves unexpectedly.

According to:
https://duet3d.dozuki.com/Wiki/Logging

I believe you that the rounding errors are not applicable, but it's maybe another reason in the code.

[JoergS5]

@fxxtoo said in Core XY movement issues:

; Endstops
M574 Z1 S0 ; Set active low endstops
M574 X1 Y1 Z2 S0

I think it has nothing to do with the thread problem, but I am confused by a config setting: why are there two Z endstops, one for Z1 and one for Z2, low end and high end?
(If the second is a Z-probe, I thought you need to set it as S2 instead of as Z2)

[FxxToo]

@joergs5

I was going to try it with the end stop on either end the of the Z. So I had done that before my issue was discovered. I haven't gotten to those tweaks or others, like the accelerations, jerk factor and lots of others. Still learning about a lot of this. I do appreciate the input.
RJ

[dc42]

@fxxtoo said in Core XY movement issues:

@dc42
Yes I can. I posted that result here : https://forum.duet3d.com/post/55484
I had found a post that you had done about putting the M92 Xxx Yxx, with the steps set for 1/16 step rate before the M350 command. I changed that and my issue with the Y moving with the X and vice versa, Stopped. I was asked if I could replicate it. I tried and I could. I thought maybe I had something else that could effect it in my config file, so I posted it after I had changed it, leaving the original statements marked in it, obviously commented out.

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later
Firmware Version: 1.21 (2018-03-21)
Web Interface Version: 1.21Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later
Firmware Version: 1.21 (2018-03-21)
Web Interface Version: 1.21
RJ

Thanks. I'd like to get to the bottom of this, so please can you:

1. Using your existing config.g, send M92 and check it reports the correct steps/mm. X and Y should be reported as 320 because the M350 command will have adjusted them.

2. Also send M667 and verify that the axis factors reported are all 1.0.

3. Change config.g to the version that gives problems. Verify that the problem still exists. Then run M92 and M667 again and check what steps/mm and axis factors are reported.

4. After that, try deleting and re-typing the M92 X320... line in case it contains any non-printing characters, and see if the problem is still present.

Thanks - David