› ›

Movement on Ender 3 Pro

cropdustercropduster
in Bug Reports
Hi there,

it happens regularly, that after a print when I use the move buttons directly after the print, the printer either
- moves in the opposite direction (z axis) - which caused a crash into the bed on my side. The next movehowever is the correct direction
- moves more than set, like 25 mm was set, but it moves all the way to the endstop.

It sometimes happens that when I press the move up by 25 mm button, the z axis moves up until it crashes into the top, like it crashes into the bed.

What might be the cause for this? It is strange as the 2nd press of the move button is correct from direction and length settings.Might this be a buffering issue? It does not happen on my Prusa mk3.

Thanks,

Michael

Comments

  • RepetierRepetier
    Sounds like a difference between position server thinks you are at and where you really are. New positions are send by server with offset added to last position stored internally. But if you have e.g. a G28 X0 Y0 we assume the coordinates you entered in server as homing position. If these differ the next manual move will be based on these "wrong" coordinates.

    As a test after print go to console and see coordinates written by server and send
    M114
    to query what firmware thinks it is at. If there is a difference that should be the reason. Now question is which command changed firmware position without server knowing where it is.
  • cropdustercropduster
    edited April 2020
    I probably know where this comes from: In my end gcode it was switching to relativ coordinates to move the extruder and bed out of the way, and then switched back to absolute coordinates. I dont have that on the Prusa mk3 end code.

    What is the recommendation here? I have absolute coorfinates set in the start gcode.
  • cropdustercropduster
    There is something weird. I just restarted the printer and did a homing from the Repetier GUI. Then I pressed 1 mm up, but it went 1 mm down. When pressed another time it went up 1 mm.

    In another instance I verified the xyz position on the printer screen and the M114 command, it was fine. When I pressed 1 mm up, I could see the that printer screen showed a z position of 1 which it started to move to.

    This all was without any print job done..... ? what's wrong?
  • cropdustercropduster
    By the way, I am using 0.93.2 !
  • RepetierRepetier
    You should do this in console view and enable send commands. Then you see the commands that get send and compare the move and coordinates and can say if it makes sense or not. You then also can better copy the conversation and make some annotations to shown positions in server. That way I can better see what you do and get. Especially since you self saw that it worked correctly on prusa it seems quite printer dependent.
    So what I mean is
    M114
    ; show output and comment difference to what server shows
    See move commands
    ; Comment move seen
    M114
    ; show output and comment difference to what server shows

    That would be a analysed cycle giving some hints. E.g. also if firmware does do something different.

    Do you go to absolute mode in end script at the end?

  • cropdustercropduster
    Repetier said:

    Do you go to absolute mode in end script at the end?

    I did that after both repetier server and printer have been restarted. I just sent a G90 and then did a homing and I could see the very same.

    I will record the exact sequence of actions and send the output from console.
  • cropdustercropduster
    edited April 2020
    So,

    I started the printer, (standalone) not connected to the Pi. I rebooted the Pi with Repetier Server running, then I connected the printer and the Pi.

    Then I pressed "Home all" on the touchscreen with Repetier running:
    12:28:56.028: N11 G28
    12:29:35.466: echo:busy: processing (19)
    12:29:35.509: X:160.00 Y:114.50 Z:12.20 E:0.00 Count X:12800 Y:9160 Z:4880 // LCD says 160 / 115 / 12.2
    12:29:35.509: ok
    Then I pressed "move up" with "1" selected:
    12:30:15.673: N12 G1 Z1.00 F720 - the extruder moves DOWN from z=12.2 to z=1 
    12:30:15.680: ok

    I pressed the same "Move up" button again.
    12:30:26.672: N13 G1 Z2.00 F720 - extruder moves up by "1" - LCd shows z=2
    12:30:26.674: ok
    12:30:28.261: N14 G1 Z3.00 F720 - again, moves up by 1 and z=3 on the LCD
    12:30:28.266: ok

    So the first command let#s it move to z=1, but then it adds up incrementally. 

    The same sequence shows a correct behaviour on the Prusa mk3 <-- CORRECTION: The nozzle is so low on the Prusa aftert homing, it actually has to move up as it moves to z=0 on the Prusa during homing.
  • cropdustercropduster
    Another thing:

    I pressed "move left 50 mm"  on  the toucscreen, and this happened:
    12:39:37.963: N16 G28
    12:40:02.922: echo:busy: processing (12)
    12:40:03.562: X:160.00 Y:114.50 Z:12.20 E:0.00 Count X:12800 Y:9160 Z:4880
    12:40:03.562: ok
    12:40:16.381: N17 G1 Z10.00 F720
    12:40:16.386: ok
    12:43:03.510: N18 G1 Z60.00 F720
    12:43:03.550: ok
    12:43:13.008: N19 G1 X0.00 F6000 - here I pressed "move left" 50 mm ... an dit goes from X=160 to X=0
    12:43:13.042: ok
  • cropdustercropduster
    Btw, if I send a G91 before executing, then it instantly works, which leads me to the suggestion to have G91 as part of the end gcode, or is this weird?
  • RepetierRepetier
    Ok I think I see your error:12:29:35.509: X:160.00 Y:114.50 Z:12.20 E:0.00 Count X:12800 Y:9160 Z:4880 // LCD says 160 / 115 / 12.2
    12:29:35.509: ok
    Then I pressed "move up" with "1" selected:
    12:30:15.673: N12 G1 Z1.00 F720 - the extruder moves DOWN from z=12.2 to z=1 

    when you say lcd you mean a printer lcd and I meant to check what server gui says as position. I'm sure you have entered as z homing position 0 so server gui shows 0 also printer is in reality at 12.2. So server adds 1 to 1 whcih is pos 1 so from servers view this  is 1mm up and in reality 11.2 down. So go to server printer configurationa nd set homing position to X:160.00 Y:114.50 Z:12.20 and moving after G28 would work correctly.

    The fact that in relative coordinates it moves correctly is not solving the problem. It is just that server then also sends relative moves as well. So form z=0 1 up is absolute 1 which is wrong, but realtive 1 which is correct. But server then still has the wrong coordinate 1 set internally.
  • cropdustercropduster
    You are right... when I home the Repetier Server GUI says 0, 0, 0 while the LCD and console outputs 160, 114.5, 12.20
  • cropdustercropduster
    But why does Repetier not take the values from the printer as home position? When I change my z offset for any reason (I am running bltouch), I have to adjust this in the Repetier settings, right?

    Why is this not a problem for the Prusa, or how do I set the Ender 3 Pro to move to 0,0,0 after homing (G28)?
  • cropdustercropduster
    I have Safe Homing enabled in the firmware, so it moves to bed size /2 position instead of 0, 0, 0. But somehow that should be detected by Repetier server, or?
  • RepetierRepetier
    Server does not know your firmware settings. It can normally also not interpret the xyz outputs. While printing they are already wrong when we receive them. Therefor we need to know.

    You will always get nearly the same position even if it differs maybe 0.1mm for z. So that is close enough to be save. The next absolute move will repair any error that is left. In your end gcode you can for example add a explicit
    G1 X0 Y200 F6000
    move if you stopped with G28 (unnecessary as position is known at end of print). That way when manually homing you are close enough to real position to make no difference and for prints it gets corrected anyway with first move.
Sign In or Register to comment.