Wird bed crashing issue in v1.0.0

cropduster

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

RAyWB

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

cropduster

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.

cropduster

So you just installed the previous version over with no issues?

cropduster

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.

RAyWB

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

cropduster

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.

RAyWB

didn´t have any communication timeout , just checksum errors.

Communication on my setup is stable , around 5 errors /2 million lines

cropduster

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.

cropduster

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.

RAyWB

well , my printer is to strong to bend ;-) i prefer the classical dial gauge method with mechanical adjusting.

(15mm aluminum heatbed)

Repetier

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?

cropduster

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.

Repetier

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.

cropduster

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.

cropduster

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.

Repetier

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.

cropduster

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

RAyWB

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

cropduster

Repetier wrote
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.