BLtouch och koden i Marlin?

[EPG]

Jag har lite prylar som står i kö för att printas ut, skickade G-koden till en av dessa nu.

En tanke som slog mig var om jag hade satt min Z-offset för BLtouch fel så att den motverkar sig själv fast eftersom att allt är mjukvara och exekveras kronologiskt så känns det ju inte så troligt. Annat hade ju varit om en rörelse hade kommit i konflikt med ett hårdtrådat gränsläge eller liknande.

[CPMS]

Det här var inte det lättaste att felsöka men jag tror jag hittat nästa grej att testa.
Det är detta jag tror händer:

När munstycket har flyttat sig till den nionde probpunkten och G29-probningen genomförs, sker följande sekvens i praktiken:
Proben fälls ut och Z går ned tills proben triggar.
Detta är själva mätögonblicket där Marlin fastställer den logiska Z-nollan (med hänsyn till probe-offset).

Proben fälls in och Z går upp till ett säkert höjdläge (”safe Z”).
Detta läge kan vara 10–20 mm ovanför byggplattan beroende på Marlin-inställningar.

Efter avslutad G29 sker en absolut Z-positionering, till exempel:
G1 Z5 F300
Detta betyder gå till den absoluta Z-koordinaten Z = 5.00 mm
Om munstycket just då står exempelvis 20 mm ovanför plattan, innebär detta alltså en nedåtgående Z-rörelse på ca 15 mm i ett enda steg.

Vad som styr hastighet respektive acceleration i detta läge
För just denna rörelse gäller följande uppdelning:
Hastighet (feedrate)
Styrs av G-koden:
F300 → 5 mm/s

Detta är en låg och i sig helt rimlig hastighet för Z-axeln.

Acceleration
Styrs inte av slicerns travel-inställningar i detta läge, utan av:
Marlins aktiva max-acceleration för Z (M201 Z…)
antingen från firmware-default eller EEPROM

Det betyder att även om hastigheten är låg, kan startaccelerationen vara mycket hög.
Om Z-accelerationen exempelvis ligger på 300–500 mm/s², försöker Marlin nå 5 mm/s mycket snabbt, vilket ger ett kraftigt initialt vridmoment.

Varför detta orsakar problem just här
I den här maskinen finns två Z-motorer på samma driver. Det gör systemet extra känsligt för:
höga accelerationspulser i starten av en rörelse
mekanisk torsion mellan de två Z-skruvarna

Om stegmotorerna tappar steg redan i början av rörelsen, så:
tappar Marlin positionsreferensen direkt
rörelsen fortsätter men från fel fasläge
det uppstår skorrande ljud och gungning i gantryn
munstycket hamnar inte där Marlin tror att det är

Detta förklarar varför problemet uppstår just efter sista probningen, trots att själva G29-mätningen fungerar korrekt och lugnt.

Nästa logiska test: hård gräns i firmware

Nästa rimliga steg är därför att lägga ett absolut tak på Z-acceleration i Marlins firmware, så att ingen G-kod eller slicerinställning kan begära mer än vad mekaniken klarar.
Detta görs med M201 och M500 via terminal:
M201 Z50
M500

Detta innebär:
Max Z-acceleration = 50 mm/s²
Spara max acc i Eeprom

Ett värde runt 50 mm/s² är ofta en bra start för dubbla Z-skruvar på samma driver.
Om det behövs kan man senare testa exempelvis 75 eller 100 mm/s², men poängen här är att först eliminera accelerationsstall som felkälla.

Om detta eliminerar gungandet/knastret och utskriften startar på rätt höjd, vet vi att orsaken är för aggressiv Z-acceleration.
Då är nästa steg att låsa detta permanent i Marlins firmware-konfiguration.

[EPG]

Nästan bra!

Nu kör den hela sekvensen perfekt ända till det absolut sista steget, det när den står 5mm över bädd och väntar på att munstycket ska komma upp i temperatur (eventuellt får jag finjustera mina PID-parametrar här btw. för den tar en evig tid på sig innan den är nöjd och svänger rätt mycket över/under innan den når måltemperaturen men det är ett annat problem...)

Däremot när den känner att den har uppnått rätt temperatur så är det precis som att den försöker att göra en sån distinkt förflyttning från 5 till 0mm (eller 5,15 till 0,15 för att vara exakt). Den missar alltså och börjar köra nån millimeter över bädden. Före senaste ändringen så var den typ 15mm över.

Det märkliga är ju bara att den här förflyttningen har ju printern gjort 100-tals gånger tidigare innan jag hade nån BLtouch och då vill jag minnas att det gick lugnt och fint.

[EPG]

Stegmotordrivarna har ju en liten potentiometer på sig där man ställer gain (har jag för mig). Denna borde ju inte ha ändrat sig sen jag ställde in det där men om vi ändå leker med tanken att den skulle stå lite fel... Hur skulle det då påverka steppermotorerna?

[CPMS]

Det viktiga är att stallningen är borta – det bevisar att accelerationsproblemet var orsaken.

Den sista rörelsen från Z5 till första lagerhöjd är en normal repositionering som nu bara blir väldigt synlig eftersom den sker direkt efter temperaturväntan.
Så länge den inte skorrar eller tappar steg är det inget fel, bara ett lite tydligare rörelsemönster än tidigare.

Prova att köra skrivaren ett litet tag och om den verkar fungera som den ska så återkom så kan vi ställa in slicern och Marlin riktigt.
Du kan också fundera på om det kan vara värt att byta ut kortet i skrivaren till ett med separata drivsteg för varje Z-motor.

Med två Z-motorer på samma driver finns det ingen möjlighet för Marlin att automatiskt justera eller räta upp Z-skruvarna mot varandra. All synkning bygger då helt på mekaniken, och små skillnader kan byggas upp över tid.
Med ett kort som har en egen driver per Z-motor kan Marlin använda den inbyggda automatiken för Z-justering. Då kan skrivaren själv räta upp Z-axeln vid homing och hålla gantryn parallell mot bädden, vilket gör systemet betydligt mer förlåtande.

Det öppnar också för att:
köra på sparad mesh istället för att köra G29 vid varje utskrift.

Det är absolut inget måste, särskilt om skrivaren nu fungerar stabilt, men det kan vara värt att ha i bakhuvudet om du vill göra systemet mer robust på sikt.

Potentiometern ställer bara maxströmmen till motorn.
Om den stod fel hade problemet visat sig hela tiden, inte bara i ett specifikt moment efter G29.
Eftersom stallningen försvann direkt när accelerationen sänktes, utan att vi rört drivern, så vet vi att ströminställningen i sig är tillräcklig.

Däremot, om motorer eller drivare blir onormalt varma kan det absolut vara värt att kontrollera och justera strömmen, antingen med multimeter eller via mjukvara om kortet/driver stöder det.

[EPG]

Alltså, den tappar nog fortfarande steg bara inte lika katastrofalt mycket som innan eftersom att då kunde den börja köra printsekvensen 15mm upp i luften. Nu är det "bara" 1mm.

Det hade ju varit bra med separata drivkretsar för stegmotorerna, just nu är det 5st DRV8825. X, Y, Z, E0, E1 men E1 används inte.
Absolut bästa hade ju varit om man kunde ha haft separata ändlägesbrytare på Z0 respektive Z1 också så den kan justera tillbaka sig själv automatiskt genom ett enkelt val i menyerna i displayen ifall man skulle råka ut för "snedvagga". Detta kräver ju dock att man verkligen shimsar in gränslägesbrytarna på vänster respektive höger sida exakt lika.

Jag valde styrkortet till den här 3D-skrivaren (MKS GEN V1.3) eftersom att det fanns STL-filer på kapslingar till dessa på orginaltillverkarens hemsida just eftersom att de tydligen hade en del garantiärenden på orginalstyrkortet i dem. Denna kapsling med lock och alla fästen passar rakt ner i orginalfästpunkterna så det nästan ser OEM ut.

[CPMS]

Om felet är konsekvent, alltså att munstycket alltid hamnar ungefär 1 mm för högt efter homing/G29, så talar det inte för tappade steg. Stegförlust är normalt sett slumpmässig och varierar från gång till gång.

Ett konstant fel på runt 1 mm pekar istället väldigt tydligt på att Z-offseten inte är korrekt kalibrerad. I så fall är det firmware-offseten som behöver justeras, inte drivare, motorström eller mekanik.

Enklast är att mäta och justera Z-offset enligt valfri guide (t.ex. på YouTube) och sedan spara värdet direkt i Marlin. I nuläget står offseten på -2.80 mm. Om du efter mätning exempelvis kommer fram till -1.85 mm kan du sätta det via terminalen:

M851 Z-1.85
M500

Detta sparar värdet i EEPROM, så ingen omkompilering eller flashning av firmware behövs.

[CPMS]

Lite lustigt är det faktiskt – ta det inte fel – men om man kokar ner det du beskriver så är det i princip:

”Det vore bra med separata Z-drivers”
”Det vore bra med automatisk gantry-alignment”
”Det vore bra om det gick att göra via firmware/meny”

Och grejen är att du redan har allt det där på plats.

Du har:
ett ledigt steg (E1)
fullt stöd i Marlin för:
Z_DUAL_STEPPER_DRIVERS
Z_STEPPER_AUTO_ALIGN
en BLTouch, som är den bästa möjliga referensen för Z-alignment utan ändlägesbrytare

Det enda som eventuellt saknas rent praktiskt är:
en extra driver (om den inte redan sitter där)
en extra motorkabel

I övrigt är allt redan förberett i både hårdvara och firmware – det handlar bara om att aktivera och konfigurera funktionerna i Marlin.

Med det upplägget kan du till exempel:
köra automatisk gantry-justering före varje utskrift
skapa en mesh en gång, spara den i Marlin och använda den för kompensation av en ojämn byggplatta

Men detta kan vi ta senare, nu ska vi först få den att öht fungera som skrivare.

[EPG]

Det rör sig i allra högsta grad fortfarande om tappade steg även om de är färre.

Jag visste om det eftersom att ljudet är likadant fortfarande (bara det kortare) men bara för att bevisa min hypotes så gjorde jag som du sa och testade 3 gånger på raken.

Jag mäter med bladmått och efter första gången så får jag mellan 1,4mm men 1,5mm klämmer.
Efter andra gången funkar 1,5mm men 1,6mm klämmer.
Sista gången så funkar 1,6mm men 1,7mm klämmer.

Sedan mätte jag även hur högt över ramen som vänstra respektive högra Z-bommen befann sig efter 3 gånger och det är cirka 39mm på vänster och 36mm på höger sida. Före testet så ställde jag båda lika med hjälp av en passbit och skruvade ned dem till de precis går fritt utan kläm.

[EPG]

Du har:
ett ledigt steg (E1)
fullt stöd i Marlin för:
Z_DUAL_STEPPER_DRIVERS
Z_STEPPER_AUTO_ALIGN
en BLTouch, som är den bästa möjliga referensen för Z-alignment utan ändlägesbrytare

Det enda som eventuellt saknas rent praktiskt är:
en extra driver (om den inte redan sitter där)
en extra motorkabel

I övrigt är allt redan förberett i både hårdvara och firmware – det handlar bara om att aktivera och konfigurera funktionerna i Marlin.

Med det upplägget kan du till exempel:
köra automatisk gantry-justering före varje utskrift
skapa en mesh en gång, spara den i Marlin och använda den för kompensation av en ojämn byggplatta

Men detta kan vi ta senare, nu ska vi först få den att öht fungera som skrivare.

En extra drivare sitter där redan och kablarna till stegmotorerna delar upp sig redan nere vid styrkortet så i så fall så har jag redan allt som krävs, jag förstår bara inte hur jag skulle få det att funka med en BLtouch?
Den mäter ju bara mot bädden och håller reda på var den befinner sig och skulle jag kalibrera mot den så får jag ju bara ett referensvärde utifrån denna, det jag behöver är ju ett absolutvärde gentemot ramen på 3D-skrivaren, något som jag enbart kan få genom att sätta en optisk gränslägesbrytare på varje Z-skruv.

[CPMS]

Ok, jag får lusläsa dina konfig-filer och inställningar en gång till då och se vad det kan vara
Skicka dom senaste Configuration.h och Configuration_adv.h som du använt senast vid flashning och
svaret du får efter du kört M503 i terminalen.



Angående ombyggnad, här har jag höjt vänstra sidan en centimeter och sen kör jag Z_STEPPER_AUTO_ALIGN
Den gör först en X Y Homing i nedre vänsta hörnet, går till mitten och gör en Y Homing och sen Z_STEPPER_AUTO_ALIGN
Jag kör med dubbel probning vid Homing men titta vad som händer runt 42 sekunder in i filmen med högra sidan av plattan.
Det är första grovjusteringen och sen fortsätter den mäta/justera till den är nöjd (max 6st försök) När den är klar står plattan oftast i våg inom 0,02mm
Och när jag säger "i våg" menar jag parallellt med gantryn.




Sen kan du även lägga in positionen på dom undre justerskruvarna och automatiskt köra proben till dom lägena och mäta av höjden med proben.
Vill du ha film på det också så säg till.

[EPG]

Såhär:

SENDING:M503
echo:; Linear Units:
echo: G21 ; (mm)
echo:; Temperature Units:
echo: M149 C ; Units in Celsius
echo:; Filament settings (Disabled):
echo: M200 S0 D1.75
echo:; Steps per unit:
echo: M92 X90.43 Y90.43 Z3160.00 E839.00
echo:; Max feedrates (units/s):
echo: M203 X300.00 Y300.00 Z5.00 E25.00
echo:; Max Acceleration (units/s2):
echo: M201 X500.00 Y500.00 Z50.00 E10000.00
echo:; Acceleration (units/s2) (P<print-accel> R<retract-accel> T<travel-accel>):
echo: M204 P3000.00 R3000.00 T3000.00
echo:; Advanced (B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>):
echo: M205 B20000.00 S0.00 T0.00 J0.01
echo:; Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:; Auto Bed Leveling:
echo: M420 S0 Z10.00 ; Leveling OFF
echo:; Material heatup parameters:
echo: M145 S0 H180.00 B70.00 F0
echo: M145 S1 H240.00 B110.00 F0
echo:; Hotend PID:
echo: M301 P27.50 I2.40 D78.86
echo:; Z-Probe Offset:
echo: M851 X26.50 Y-1.00 Z-2.80 ; (mm)

I configuration_adv.h är det inget ändrat sedan sist och i configuration.h så är det ju bara "DEFAULT_MAX_ACCELERATION" som är ändrat till 50 för Z sedan sist.
Eller jo föresten, scrollhjulet på displayen är reverserat sedan sist också eftersom att det gick åt andra hållet på denna.

[CPMS]

OK, nu tror jag att jag har det (igen).

Starta Prusa Slicer
Ställ in Expert-Läge
Gå till Printers Settings → Machine limits
Ändra How to apply limits till Use for time estimate
Ändra inget annat
Slica något och prova igen

Nu ska den inte rusa och tappa steg under förflyttningen Z5 till Z0.350 längre.

Funkar detta så tittar jag över alla limitar och föreslår nya inställningar.

Bifogar skärmdump på inställningen du ska ändra.

apply.jpg

[EPG]

Jag hade en äldre version av Prusaslic3r där alternativet "How to apply limits" inte fanns med. Den har frågat ganska länge nu om att det finns en nyare version och om jag vill ladda ner den och jag har tryckt på "ja" ibland men det brukar hänga sig/komma en massa felmeddelanden så då har man bara skitit i det och kört vidare med den befintliga versionen. Men jag gick in på hemsidan nu och laddade ned den nyaste istället och installerade.

Men alternativet "Use for time estimate" är redan förvalt så den kanske redan är den den använder men jag kan pröva i alla fall.

[CPMS]

Jag såg att du hade en äldre version och jag felaktigt förutsatte att det alternativet fanns och var felvalt, mitt fel att förutsätta något innan jag fått bekräftelse.
Men jag ser tydligt i dina filer att slicern försöker ställa om firmware och det är där jag misstänker felet uppstår så se till att "Marlin 2" är valt, att "Use for time estimate" är valt
och övriga parametrar stämmer. Du kan importera den config-bundel du skickade så får du tillbaka dom flesta inställningar men du bör ändå kolla igenom allt.