X and Y still move to max after emergency stop is executed from repetier server 0.80.0 via browser

I face an issue where the X and Y will move beyond the maximum size set after the emergency stop is executed either from the browser accessing Repetier Server 0.80.0 or from Repetier Host connecting to Repetier Server. This did not happen in 0.75. What is causing this to happen?

Comments

  • By default we only send non moving commands to printer on a restart that gets detected. You might have such commands in your connect script.

    If not please tell exactly how to produce the error. There must be some source for move gcodes.
  • I have also had this happen during random server rests in 80.1 Pro - the y and x axis get driven to their max values - I can not re-create it as it is intermittent - but there is clearly a fault in the code of the server somewhere - running the printer from Host is reliable.

    for 60E and a "full" relaese i'd expect more TBH.....
  • edited November 2016
    I also had it happen to me. Running 0.80.1 Pro.
  • haven't yet needed an E-Stop with 0.80.1 but I can confirm that this has happened to me too with 0.80 and earlier versions, the printer continues to move in <direction that it was going when E-Stop was triggered> until there are "mechanical barriers" and it gets loud ;-)


  • Okay, I hat to STOP my printer right now (a 6x6mm part angled ~70 degrees got wobbly) and I can confirm that after the ESTOP via Web-GUI my printer *did* move (not until it crashed somewhere but still)

    Firmware: 0.92.9
    Server: 0.80.1 on a rasPi 3, fresh install via the new Image for rasPi
    Aux/Misc: RaspiCam, Reprap Discount Full Gaphics Smart Controller
    -> No scripts configured

    I hit the ESTOP-Button, printer stopped "next to immediately", FW reboots (Display goes blank, shows the startup-screen) and the printer moved for about 30mm in X and 15mm in Y, both in +-direction

  • I have added some extra code for next 0.80.2 for emergency stop. It will now first stop print, clear all commands in buffer and then reset/send M112. Currently it is only doing reset/M112 and relies on firmware response. So there might be some moves in queue that should be prevented with new system.

    Also firmware dev version has now a option to only move when the axis was homed. So with that addition even the old behaviour should do no harm as the home would be missing after reset.
  • edited November 2016
    I think that emergency stop should be more accessible. Now, it needs some clicks to trigger it (in the web gui) and the emergency stop in Repetier-Host does nothing when connected via the server.
  • That is for security reasons. Emergency stop is a rare occurance in real printing. Hitting the button by accident happens much more often. In fact printers should have a reset button directly accessible for this instead. That is the only fast and relyable way. If you rely in a 24h print on someone seeing this and being at the computer it is just luck. Normally you just cancel the running print if you see it fail. Emergency is if printer is running amok and that does not happen very often. Normally only with new firmware when some settings are skewed.
  • edited November 2016
    So the button has no use in repetier-host when connected to the server? Why is it there? Could it be optional? My printer has a reset button but I'm not always at the printer (using webcam). 
  • I spoke about the server ui button. If host does not work it is an error I have to check and fix.

  • Repetier said:
    I have added some extra code for next 0.80.2 for emergency stop. It will now first stop print, clear all commands in buffer and then reset/send M112. Currently it is only doing reset/M112 and relies on firmware response. So there might be some moves in queue that should be prevented with new system.
    doesn't seem to have made it into 0.80.2, I just ESTOPed my printer (see https://forum.repetier.com/discussion/2819/v0-80-2-temperature-overshoots-printer-doesnt-start-if-preheated-via-web) and still had X "running away", no crash but it was close this time.


  • Does your printer reset on connect?

    The problem is that we can not undo commands that are already send. We make sure we send no more commands but send is send.

    Also what firmware are you using (source, version). Newer Marlin versions have a out of order execution for some commands like emergency stop. Don't know how that would play in this situation.
Sign In or Register to comment.