› ›

Wird bed crashing issue in v1.0.0

cropdustercropduster
in Bug Reports
Hey,

since my upgrade I had serious issues with my nozzle crashing into the bed. I run homing without an issue, but once the printing starts, the nozzle crashes into the bed and I have no idea why. here is a new warning about a connection issue. I may check again, but my textured plate is already damaged and I am very reluctant to break my x gantry and everything because of that.

I am assuming it has something to do with the upgrade because I changed nothing else.

Btw, is there still no option to upload screenshots..... 

Comments

  • RAyWBRAyWB
    same here , printed exactly the same gcode before  on 0.94.3 without issues   now total crash during print,
    seems z-axis went down around 10mm without reason.
    i´ll revert to 94.3
  • cropdustercropduster
    There seems to be a buffer issue. I get my issues always when cancel a print. This seems to lead to the nozzle slamming into the bed. Last time, I cancelled a print because after some spaghetti disaster. When I started another print, the nozzle ran into the bed while homing.
  • cropdustercropduster
    So you just installed the previous version over with no issues?
  • cropdustercropduster
    did you check on the console what happened? This does not happen every time, and it seems like my two printers produce more failed prints since the upgrade... Layer shifts... that‘s why I though there might be a communication / buffering issue.
  • RAyWBRAyWB
    edited December 2020
    on console i just got lot of checksum errors
    unfortunately i didn´t activate logging.
    as it was massive mechanical crash (ripped out a complete linear rail including 16 M3 screws) i just fixed my printer .

    to go back to 094.3 just connect via putty
    and send :


    wget http://download1.repetier.com/files/server/debian-armhf/Repetier-Server-0.94.3-Linux.deb

    sudo dpkg -i Repetier-Server-0.94.3-Linux.deb

    rm Repetier-Server-0.94.3-Linux.deb



    for me that worked without issue. i managed to print that gcode again without any communication or checksum errors
    as before


  • cropdustercropduster
    I see from the change log that some communication timeout and resend optimzation might have contributed to my issues when I needed to stop the printer by power switch.
  • RAyWBRAyWB
    didn´t have any communication timeout , just checksum errors.
    Communication on my setup is stable , around 5 errors /2 million lines
  • cropdustercropduster
    wow, that‘s bad.... I just have a punctured textured steelsheet. but not sure what cracks I got on my x ends .. they were severly bending.

    After similar issues I use to perform sone bltouch homing tests above the bed to make sure nothing is broken there, but it seems like a few other issues might have been introduced by the optimizations.
  • cropdustercropduster
    my ender seems to be better off... I run a SKR 1.4 on it, and in my crashed Bear the turbo version. I didn‘t get that severe issue son my Ender.
  • RAyWBRAyWB
    well , my printer is to strong to bend ;-)  i prefer the classical dial gauge method with mechanical adjusting.
    (15mm aluminum heatbed)
  • RepetierRepetier
    First you can e.g. use https://imgur.com/ to upload images and post the urls here.

    We had printed several 100 hours without problems and apart from you 2 had no similar messages, so questions is what it takes to create a crash and how it is possible at all. I mean firmware knows where z min/max is and should prevent moves outside normally on it's own.

    So what is happening exactly - any logs would be helpful here.

    What is new is that we now interpret position reports from firmware. If that is wrong it is possible that you can send moves to illegal positions but that also means printer moves without homing first and reports wrong positions then and has no protection. That is I think the easiest way - to have no homing and then move. In most configurations this is allowed and you can exceed limits with that. Is that something that could have happened? Maybe combined with a reconnect that caused the firmware to reset and loose homing informations?

  • cropdustercropduster
    I went back to 0.94.3, but on one of my printer, a Bear SKR printer, I have the issue, that ftare a successful print, a new print leads to the nozzle crashing into the bed. When sending M119 via the console, the pint deploys from stowed mode and the status is shown as open. In normal operations, the pin stays stowed and shows triggered after issuing M119, when I deploy the probe, M119 shows open. 
    Now, I had this today as well, and after a while, with some poer on/off of the printer and some restarts of Repetier server, it finally went away, but I have no clue why this happens after a successful print. The same end gcode is with SuperSlicer on my Ender3 printer that does not have the issue.
  • RepetierRepetier
    Is this meant to happen with that firmware? I mean M119 should show status of pin but not stow/deploy a pin. At least that is how we do it in repetier firmware. Have no marlin with that. We only deploy when we want to measure. Apart from this M119 should always signal untriggered. bltouch only holds high signal for 10ms. Except in alarm mode where it keeps being triggered.
  • cropdustercropduster
    Repetier said:
    Is this meant to happen with that firmware? I mean M119 should show status of pin but not stow/deploy a pin. At least that is how we do it in repetier firmware. Have no marlin with that. We only deploy when we want to measure. Apart from this M119 should always signal untriggered. bltouch only holds high signal for 10ms. Except in alarm mode where it keeps being triggered.
    Yeah, that is the theory, but in fact I ran the command a couple of times and also during the issue I had. The symptom is pretty clear:
    - If everything is fine and bltouch works (for homing), then M119 shows "triggered" when stowed and "open" when deployed.
    - If I send the M119 to the bltouch in stowed mode and it deploys, then I know there is an issue. I did a G28 then and it always failed to trigger the probe.  

    It happened n ow a few times when a print finished successfully, that then a G28 led to a crash into bed, even though the print just before went fine with the G28 in the startup gcode. Somehow something happens after the print. 
  • cropdustercropduster
    Repetier said:
    Is this meant to happen with that firmware? I mean M119 should show status of pin but not stow/deploy a pin. 
    That is correct in marlin and it just works when everything is fine. However, when I experience "my issue", the M119 actually deploys the probe. That is strange indeed.
  • RepetierRepetier
    Server is just sending gcodes. So that sounds more like a firmware issue than a server problem. Except if you see in console extra commands like deploy being send. Enable commands in console to see what gets actually really send.

    What you describe seems like M119 is not just querying but also runs deploys/stows under some condition. Here the experts for your firmware are in question I'd say. 
  • cropdustercropduster
    I had it running well on 0.94.3, retried 1.0.1. and had already an issue with screen resolution, connectivity and strangely enough UBL bed probing. That should not be connected with UBL, but I am puzzled, just after the upgrade my printer behaves strange.... I don't want to blame the upgrade for all that misery, but since I initiually upgraded to 1.0.0 I got a whole lot of issues I am trying to rectify... maybe just a coincicence
  • RAyWBRAyWB
    On 1.0.1 my printer works as expected , solved for now.
    checksum errors disappeared after reducing buffers from 255 to 127.
    You can check for the best setting in Printer Settings-> Communication
    there´s a button "Test multiple configs" so there you can check and select the best

    My printer uses 255 by autodetect , but checking shows errors so i reduced to 127 and problems disappeared
  • cropdustercropduster
    edited December 2020
    Repetier said:
    Server is just sending gcodes. So that sounds more like a firmware issue than a server problem. Except if you see in console extra commands like deploy being send. Enable commands in console to see what gets actually really send.

    What you describe seems like M119 is not just querying but also runs deploys/stows under some condition. Here the experts for your firmware are in question I'd say. 
    The explanation to the M119 behaviour is, that I have the Bltouch not connected to the probe pin, but the z endstop pin, so it behaves as the physical endstop. I still have issues with the Bltouch, but that seems to be only related to one printer, the Bear SKR, the Ender SKR behaves normally without issues. The board is almost the same (SKR 1.4 vs. 1.4 Turbo), but connections are the same.
  • cropdustercropduster
    So it really seems to be related to my Bear SKR printer. This has a BLtouch issue. The Ender 3 SKR with a Hemera and Bltouch works fine. Not sure where this Bltouch issue on my Bear comes from :-/  
  • cropdustercropduster
    So, I have solved my issues: The root cause for my inconsisent bltouch behaviour was a loose signal cable connection :-/ no software issue. Strange how some occurrences coincident.
  • RepetierRepetier
    Yes I know. And it always makes me wonder what I have done when someone says I only changed your software:-) But with so many users there is always such a case as well.
    Anyhow, great it works again.
Sign In or Register to comment.