Relative movement moves Y 10mm regardless of command

I have a brand new installation of Repetier server.  I connect to it using Repetier Host, the web interface, and another application I'm writing over HTTP.  Using Repetier Host, I send it a homing sequence using one of the numeric scripts under manual control.  Everything works fine until I home it a second time.  

After the second homing, when I send a relative motion command through any mechanism, it ALWAYS moves in the Y direction by 10mm.  For example, here is a sequence recorded with the web interface:

Send:18:30:10.119: @moveRel X0 Y0 Z1
Send:18:30:10.119: N826 G1 X833.80 Y180.00 F12000
Send:18:30:10.119: N827 G1 Z8.00 F1200
Send:18:30:10.119: @updatePrinterState
Recv:18:30:10.127: ok (2)
Send:18:30:12.703: @moveRel X0 Y0 Z1
Send:18:30:12.703: N831 G1 X833.80 Y190.00 F12000
Send:18:30:12.703: N832 G1 Z9.00 F1200
Send:18:30:12.703: @updatePrinterState
Recv:18:30:12.756: ok (2)
Send:18:30:19.439: @moveRel X0 Y0 Z1
Send:18:30:19.439: N840 G1 X833.80 Y200.00 F12000
Send:18:30:19.439: N841 G1 Z10.00 F1200
Send:18:30:19.439: @updatePrinterState
Recv:18:30:19.450: ok (2)
Send:18:30:20.380: @moveRel X0 Y0 Z1
Send:18:30:20.380: N842 G1 X833.80 Y210.00 F12000
Send:18:30:20.380: N843 G1 Z11.00 F1200
Send:18:30:20.380: @updatePrinterState
Recv:18:30:20.388: ok (2)

You see, after each relative movement to move Z up 1mm, the Y axis is moved 10mm each time.  It moves Y first before moving Z, even though Y wasn't commanded to move.

My homing sequence is:

G90
G28 Z Y X
G92 Z70 Y-10 X910
G0 Z65 Y0 X900 F3000
G28 Z Y X
G92 Z70 Y-10 X910
G0 Y0 X900 F1000
G0 Z0 F1000
G92 X900 Y0 Z0

It does a G28 homing sequence twice, then moves it down and defines a known location of 900,0,0.  This homing sequence is on the extreme forward right of my machine.


Comments

  • Thanks. It is a bug in server. Actually I fixed this bug already for pure x, y or z moves but in the xyz case I did not apply the solution:-( So will be fixed in version 1.4.1 coming today or tomorrow.

    Reason is your G92 Y-10 - the @moveRel does not account the active offset correctly so it gets added every time you move Y axis.

    You can already solve this now by using
    @moveRel Z1
    instead. No need to use X and Y if you do not plan to move them. But in 1.4.1 it will work in any version of course.
  • In that case, I could fix this by moving setting G92 Y0 after moving the gantry to that location.  I don't need a negative offset, I just set it there so that my homing position gives me a 10mm offset from the actual hard stop.

    I'm sending the move command over the API interface, which at least is defined as requiring an x, y, and z data parameter.  Ultimately, I need all 3 so that I can move the head in one motion rather than 3.

    Couldn't you also do the relative moves using G91 rather than calculating the absolute position yourself?  You could then poll the current position with M114 if you needed to do any calculated move.


  • Ok 1.4.1 is out with fix.

    I could use G90/G91 but all solutions have side effects. After all the sense of all commands going through the server is that we know the printer state and that way we can remove these commands. It also can get tricky if you add commands on different channels that change so keeping the preferred and normally active absolute positioning is normally the best solution. Got more problems with the other solutions.
  • I've installed 1.4.1 and haven't noticed any issues.  Looks Good!
Sign In or Register to comment.