Jag har precis installerat en BLtouch och gjort inställningar i firmware enligt konstens alla regler och tänkte därför testa att göra en första utskrift nu.
Skrivaren kör nivåmätningssekvensen och tar ut sina nio mätpunkter (3x3) precis som det är tänkt att den ska göra men problemet uppstår när den är klar med mätningen och ska finjustera i enlighet med vad den precis har mätt upp. För istället för att köra Z så vibrerar hela skrivaren i strax under en sekund. Jag misstänker att den försöker att köra Z-axeln allderles för fort vilket får stegmotorerna att gå ur synk. Z är ju en snäckväxel och rent mekaniskt så går ju helt klart en sån tyngre än där det är remdrift så det går ju helt enkelt inte att gasa hur mycket som helst.
Är det någon som har koll på var i Marlin man ställer in begränsningar för dessa?
Jag har nämligen nyligen bytt firmware från 1.1.8 till 2.1.2 och i samband med det så lät jag allt vara på default bara. Jag har nämligen varit inne och justerat både lite här och lite där tidigare och har helt glömt bort mig vad jag har gjort och många gånger har det visat sig att jag har försökt att kompensera för något helt annat fel exempelvis att något har gått tungt rent mekaniskt.
Är det möjligen så att det finns vissa värden som tillverkaren rekommenderar att man använder sig av i Marlin? Alltså att tillverkaren har kännedom exakt hur mycket friktion och liknande det normalt är på X, Y och Z-axlarna så de har testat sig fram om vad som fungerar bäst? Bara det att jag har missat (eller glömt bort) detta?
BLtouch och koden i Marlin?
Re: BLtouch och koden i Marlin?
När du går från 1.1.8 till 2.1.2 och låter allt stå på default händer två saker:
Marlin 2.x har generiska standardvärden
De är inte anpassade för snäck-/trapetsdriven Z-axel
Det finns flera ställen där detta styrs
Var du ska titta i Marlin
De relevanta parametrarna är:
I Configuration.h
DEFAULT_MAX_FEEDRATE (Z är ofta för högt default)
DEFAULT_MAX_ACCELERATION (Z är nästan alltid för högt default)
För en snäckväxel är typiska riktvärden snarare:
Z max feedrate: ca 2–3 mm/s
Z acceleration: ca 20–50 mm/s²
Defaultvärdena i Marlin är ofta satta som om Z vore remdriven, vilket fungerar dåligt ihop med mesh-kompensering som gör snabba, små Z-justeringar under rörelse.
Snabb verifiering utan omkompilering
Innan du ändrar källkoden kan du verifiera detta direkt via terminal:
M503
Titta specifikt på:
Max feedrate för Z
Max acceleration för Z
Du kan även testa att tillfälligt sänka dem:
M203 Z2
M201 Z30
M500
M203 = hur fort Z får gå
M201 = hur snabbt Z får accelerera
M500 = gör ändringen beständig
Om vibrationerna försvinner har du hittat rätt orsak.
Angående “tillverkarens rekommenderade värden”
Nej – Marlin har ingen kännedom om din mekanik.
Om tillverkaren inte har levererat:
färdig Marlin-konfiguration
eller dokumenterade rörelsevärden
…så är defaults bara exempelvärden.
I många fall var de manuellt nedjusterade i äldre firmware vilket gör att problemet först dyker upp nu när du byter till 2.1.2.
Att sänka Z-hastighet och acceleration med M203 och M201 innebär att du sätter ett tak för hur fort Marlin får köra Z-axeln.
Detta skyddar mekaniken oavsett vad som händer senare.
Men det är inte samma sak som att styra hur Z faktiskt körs i start-G-koden.
Eftersom problemet uppstår direkt efter mesh-mätningen är det också viktigt att titta på start-G-koden:
Det kan finnas ett explicit Z-kommando (t.ex. G1 Z…) med för hög feedrate.
Eller ett Z-kommando utan någon angiven hastighet, vilket gör att det körs med senast använda feedrate (ofta satt för X/Y-rörelser och alldeles för hög för Z).
Exempel:
G1 Z5
Kör Z med den feedrate som råkade vara aktiv senast, vilket ofta är helt fel för en snäckväxel.
Så:
Start-G-koden bestämmer vad som beordras
M203/M201 bestämmer vad som är tillåtet
Båda behöver vara rimliga.
Firmware-begränsningarna gör systemet robust, men start-G-koden bör ändå ses över så att den inte i sig försöker köra Z för aggressivt.
Plus att slicerinställningar kan också begränsa hastigheter om man har den så inställd, annars brukar slicern använda sina inställningar i uträkningen av ex printtid.
Marlin 2.x har generiska standardvärden
De är inte anpassade för snäck-/trapetsdriven Z-axel
Det finns flera ställen där detta styrs
Var du ska titta i Marlin
De relevanta parametrarna är:
I Configuration.h
DEFAULT_MAX_FEEDRATE (Z är ofta för högt default)
DEFAULT_MAX_ACCELERATION (Z är nästan alltid för högt default)
För en snäckväxel är typiska riktvärden snarare:
Z max feedrate: ca 2–3 mm/s
Z acceleration: ca 20–50 mm/s²
Defaultvärdena i Marlin är ofta satta som om Z vore remdriven, vilket fungerar dåligt ihop med mesh-kompensering som gör snabba, små Z-justeringar under rörelse.
Snabb verifiering utan omkompilering
Innan du ändrar källkoden kan du verifiera detta direkt via terminal:
M503
Titta specifikt på:
Max feedrate för Z
Max acceleration för Z
Du kan även testa att tillfälligt sänka dem:
M203 Z2
M201 Z30
M500
M203 = hur fort Z får gå
M201 = hur snabbt Z får accelerera
M500 = gör ändringen beständig
Om vibrationerna försvinner har du hittat rätt orsak.
Angående “tillverkarens rekommenderade värden”
Nej – Marlin har ingen kännedom om din mekanik.
Om tillverkaren inte har levererat:
färdig Marlin-konfiguration
eller dokumenterade rörelsevärden
…så är defaults bara exempelvärden.
I många fall var de manuellt nedjusterade i äldre firmware vilket gör att problemet först dyker upp nu när du byter till 2.1.2.
Att sänka Z-hastighet och acceleration med M203 och M201 innebär att du sätter ett tak för hur fort Marlin får köra Z-axeln.
Detta skyddar mekaniken oavsett vad som händer senare.
Men det är inte samma sak som att styra hur Z faktiskt körs i start-G-koden.
Eftersom problemet uppstår direkt efter mesh-mätningen är det också viktigt att titta på start-G-koden:
Det kan finnas ett explicit Z-kommando (t.ex. G1 Z…) med för hög feedrate.
Eller ett Z-kommando utan någon angiven hastighet, vilket gör att det körs med senast använda feedrate (ofta satt för X/Y-rörelser och alldeles för hög för Z).
Exempel:
G1 Z5
Kör Z med den feedrate som råkade vara aktiv senast, vilket ofta är helt fel för en snäckväxel.
Så:
Start-G-koden bestämmer vad som beordras
M203/M201 bestämmer vad som är tillåtet
Båda behöver vara rimliga.
Firmware-begränsningarna gör systemet robust, men start-G-koden bör ändå ses över så att den inte i sig försöker köra Z för aggressivt.
Plus att slicerinställningar kan också begränsa hastigheter om man har den så inställd, annars brukar slicern använda sina inställningar i uträkningen av ex printtid.
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Jag har luskat lite i det där, de värden som tillverkaren anger är:
max_velocity: 300
max_z_velocity: 14
max_accel: 500
maz_z_accel: 100
Inställningarna i Marlin (jag hade visst fört över dessa värden från gamla Marlinversionen):
DEFAULT_MAX_FEEDRATE { 500, 500, 5, 25 } (X, Y, Z, E0)
DEFAULT_MAX_ACCELERATION { 600, 600, 100, 10000 } (X, Y, Z, E0)
Så jag ändrade till:
DEFAULT_MAX_FEEDRATE {300, 300, 5, 25 } (X, Y, Z, E0)
DEFAULT_MAX_ACCELERATION { 500, 500, 100, 10000 } (X, Y, Z, E0)
Hastigheten är med andra ord inställd på 5 fast den borde klara ända upp till 14 så rimligtvis är det inte detta som är felet utan jag borde kunna ställa upp den på 14 och sen fortsätta att felsöka någon annanstanns (var?) däremot så ligger accelerationen redan bra.
Bör jag ändå kolla M201, M203, M500 och M503?
max_velocity: 300
max_z_velocity: 14
max_accel: 500
maz_z_accel: 100
Inställningarna i Marlin (jag hade visst fört över dessa värden från gamla Marlinversionen):
DEFAULT_MAX_FEEDRATE { 500, 500, 5, 25 } (X, Y, Z, E0)
DEFAULT_MAX_ACCELERATION { 600, 600, 100, 10000 } (X, Y, Z, E0)
Så jag ändrade till:
DEFAULT_MAX_FEEDRATE {300, 300, 5, 25 } (X, Y, Z, E0)
DEFAULT_MAX_ACCELERATION { 500, 500, 100, 10000 } (X, Y, Z, E0)
Hastigheten är med andra ord inställd på 5 fast den borde klara ända upp till 14 så rimligtvis är det inte detta som är felet utan jag borde kunna ställa upp den på 14 och sen fortsätta att felsöka någon annanstanns (var?) däremot så ligger accelerationen redan bra.
Bör jag ändå kolla M201, M203, M500 och M503?
Re: BLtouch och koden i Marlin?
Med den information du har tagit fram nu, och efter att du verifierat vilka maxhastigheter och accelerationer som faktiskt gäller i din firmware,
tycker jag att vi ganska tryggt kan släppa start-G-koden som huvudorsak.
Om:
vanliga G0/G1-rörelser fungerar normalt
Z-hastighet och acceleration är rimligt begränsade i firmware
och problemet uppstår direkt efter sista probpunkten, innan någon utskrift eller primning börjar
…då är det väldigt osannolikt att det är de ordinarie rörelseparametrarna som spökar.
Det pekar istället på att beteendet uppstår inne i själva G29-sekvensen.
Vad Marlin gör precis efter sista probpunkten
Efter att sista punkten i G29 är uppmätt gör Marlin några interna rörelser som inte styrs av start-G-kod och inte är vanliga G1/G0-moves:
proben dras in (stow)
Z flyttas för att skapa frigång (Z-retract / Z-clearance)
ibland sker även en kort förflyttning bort från mätpunkten
De här rörelserna styrs av probb- och leveling-specifika inställningar, inte av DEFAULT_MAX_FEEDRATE på det sätt man först kan tro.
I Configuration.h / Configuration_adv.h är det främst dessa som är relevanta:
Z_PROBE_FEEDRATE_FAST
Hastighet för snabba Z-rörelser i samband med probing (mm/min).
Z_PROBE_FEEDRATE_SLOW
Hastighet för själva mätningen, oftast redan låg och snäll.
Z_CLEARANCE_DEPLOY_PROBE
Hur mycket och hur Z flyttas när proben fälls ut.
Z_CLEARANCE_RETRACT_PROBE
Mycket intressant i ditt fall – Z-rörelsen direkt efter att proben dragits in, alltså exakt efter sista mätpunkten.
Kolla dessa parametrar och se om någon hastighet är hög, särskilt den första. Är det inte det får vi fortsätta att fundera.
tycker jag att vi ganska tryggt kan släppa start-G-koden som huvudorsak.
Om:
vanliga G0/G1-rörelser fungerar normalt
Z-hastighet och acceleration är rimligt begränsade i firmware
och problemet uppstår direkt efter sista probpunkten, innan någon utskrift eller primning börjar
…då är det väldigt osannolikt att det är de ordinarie rörelseparametrarna som spökar.
Det pekar istället på att beteendet uppstår inne i själva G29-sekvensen.
Vad Marlin gör precis efter sista probpunkten
Efter att sista punkten i G29 är uppmätt gör Marlin några interna rörelser som inte styrs av start-G-kod och inte är vanliga G1/G0-moves:
proben dras in (stow)
Z flyttas för att skapa frigång (Z-retract / Z-clearance)
ibland sker även en kort förflyttning bort från mätpunkten
De här rörelserna styrs av probb- och leveling-specifika inställningar, inte av DEFAULT_MAX_FEEDRATE på det sätt man först kan tro.
I Configuration.h / Configuration_adv.h är det främst dessa som är relevanta:
Z_PROBE_FEEDRATE_FAST
Hastighet för snabba Z-rörelser i samband med probing (mm/min).
Z_PROBE_FEEDRATE_SLOW
Hastighet för själva mätningen, oftast redan låg och snäll.
Z_CLEARANCE_DEPLOY_PROBE
Hur mycket och hur Z flyttas när proben fälls ut.
Z_CLEARANCE_RETRACT_PROBE
Mycket intressant i ditt fall – Z-rörelsen direkt efter att proben dragits in, alltså exakt efter sista mätpunkten.
Kolla dessa parametrar och se om någon hastighet är hög, särskilt den första. Är det inte det får vi fortsätta att fundera.
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Jag kopierar direkt från "configuration.h":
#define Z_PROBE_FEEDRATE_FAST (4 * 60)
#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)
#define Z_CLEARANCE_DEPLOY_PROBE 10
Z_CLEARANCE_RETRACT_PROBE hittar jag varken i "configuration.h" eller i "configuration_adv.h".
#define Z_PROBE_FEEDRATE_FAST (4 * 60)
#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)
#define Z_CLEARANCE_DEPLOY_PROBE 10
Z_CLEARANCE_RETRACT_PROBE hittar jag varken i "configuration.h" eller i "configuration_adv.h".
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Jag har aldrig laddat upp nåt på Tiktok innan men nu testade jag i alla fall att lägga upp två st, dock lyckas jag inte öppna dem i datorn men uppenbarligen har jag fått visningar i alla fall.
https://vm.tiktok.com/ZNRYWjRDp/
https://vm.tiktok.com/ZNRYW1ssw/
Där är dem i alla fall ni vill se hur skrivaren beter sig.
Jag tycker det känns som att stegmotorerna i Z-axeln går i osynk med varandra.
https://vm.tiktok.com/ZNRYWjRDp/
https://vm.tiktok.com/ZNRYW1ssw/
Där är dem i alla fall ni vill se hur skrivaren beter sig.
Jag tycker det känns som att stegmotorerna i Z-axeln går i osynk med varandra.
Re: BLtouch och koden i Marlin?
Beklagar att den här felsökningen går lite fram och tillbaka men det är ju inte det lättaste att felsöka via ett forum. 
Efter att ha tittat på filmerna några gånger tycker jag att beteendet blir tydligare.
Själva probningen (G29) ser lugn och korrekt ut:
Z går ner kontrollerat
proben triggar som den ska
Z går upp igen utan att låta ansträngd
inga tecken på att något går för fort under själva mätningen
och det bekräftas ju också av inställningen i Marlin
Problemet verkar istället uppstå precis efter att G29 är klar, när skrivaren:
har gått upp till ett slags ”parkeringsläge”
och därefter går ner igen innan utskriften börjar
Det är i den nedrörelsen som Z-motorerna börjar gå i otakt och det där skrapande/knastrande ljudet uppstår, vilket starkt liknar när Z försöker röra sig för snabbt eller med för lite moment.
Vid den tidpunkten är G29-sekvensen klar, och kontrollen har lämnats tillbaka till G-koden från slicern. Därför misstänker jag nu att det är något Z-kommando i startsekvensen som:
kör Z ner en bit med för hög hastighet eller utan angiven feedrate (så den ärver en för hög tidigare hastighet)
Det kommandot kan nog bara komma endera ifrån Start-Gcode eller så är det slicern själv som skapar det (någon typ av höjdinställning vid start av utskrift).
För att komma vidare vore det väldigt hjälpsamt om du kan posta:
de första ~50 raderna av G-koden från en slicad utskrift (direkt från filen, orörd)
Där bör det gå att se exakt:
vilket Z-kommando som sker direkt efter G29
vilken höjd den går till
och med vilken feedrate
Posta gärna din Start-Gcode från slicerns inställningar också
Som en snabb kontroll kan det också vara värt att kika i slicern att den är inställd på Marlin / Marlin 2 som firmware-typ,
så att inga äldre antaganden om Z-hantering eller startsekvens för Marlin 1 ligger kvar i profilen (om den inställningen finns i din slicer)
Med G-koden framför oss borde det gå att säga väldigt exakt vad som triggar den där rörelsen – just nu pekar filmerna tydligt på att det sker efter probningen, inte under den.
Efter att ha tittat på filmerna några gånger tycker jag att beteendet blir tydligare.
Själva probningen (G29) ser lugn och korrekt ut:
Z går ner kontrollerat
proben triggar som den ska
Z går upp igen utan att låta ansträngd
inga tecken på att något går för fort under själva mätningen
och det bekräftas ju också av inställningen i Marlin
Problemet verkar istället uppstå precis efter att G29 är klar, när skrivaren:
har gått upp till ett slags ”parkeringsläge”
och därefter går ner igen innan utskriften börjar
Det är i den nedrörelsen som Z-motorerna börjar gå i otakt och det där skrapande/knastrande ljudet uppstår, vilket starkt liknar när Z försöker röra sig för snabbt eller med för lite moment.
Vid den tidpunkten är G29-sekvensen klar, och kontrollen har lämnats tillbaka till G-koden från slicern. Därför misstänker jag nu att det är något Z-kommando i startsekvensen som:
kör Z ner en bit med för hög hastighet eller utan angiven feedrate (så den ärver en för hög tidigare hastighet)
Det kommandot kan nog bara komma endera ifrån Start-Gcode eller så är det slicern själv som skapar det (någon typ av höjdinställning vid start av utskrift).
För att komma vidare vore det väldigt hjälpsamt om du kan posta:
de första ~50 raderna av G-koden från en slicad utskrift (direkt från filen, orörd)
Där bör det gå att se exakt:
vilket Z-kommando som sker direkt efter G29
vilken höjd den går till
och med vilken feedrate
Posta gärna din Start-Gcode från slicerns inställningar också
Som en snabb kontroll kan det också vara värt att kika i slicern att den är inställd på Marlin / Marlin 2 som firmware-typ,
så att inga äldre antaganden om Z-hantering eller startsekvens för Marlin 1 ligger kvar i profilen (om den inställningen finns i din slicer)
Med G-koden framför oss borde det gå att säga väldigt exakt vad som triggar den där rörelsen – just nu pekar filmerna tydligt på att det sker efter probningen, inte under den.
Re: BLtouch och koden i Marlin?
Efter att ha funderat lite till misstänker jag att problemet kan annars vara relaterat till en felkonfigurering av Z-endstoppen i samband med att BLTouch installerades.
Om firmware är konfigurerad så att både BLTouch-proben och en fysisk Z-endstop (eller någon annan oavsiktlig endstop-källa) är aktiverade samtidigt, finns det en risk att en endstop triggas tidigare än avsett under G28-homingsekvensen. Även om själva probningen slutförs korrekt kan en intern endstop-flagga ändå bli satt.
I ett sådant läge kan Marlin senare reagera på detta genom att ändra rörelsebeteende, avbryta moment eller köra oväntade rörelser, beroende på hur endstop-hantering och säkerhetsfunktioner är konfigurerade.
För att kunna utesluta detta på ett korrekt sätt vore det bra att få se båda:
Configuration.h
Configuration_adv.h
Då kan man verifiera att:
Endast avsedd Z-endstop (BLTouch-proben) är aktiverad
Inga gamla eller oanvända Z-endstop-definitioner ligger kvar
Endstop-beteendet under homing och probning stämmer med den faktiska hårdvaran
En probe kan användas antingen som en ren probe, eller som både probe och Z-endstop. Det är viktigt att veta hur du vill att det ska fungera och hur proben är kopplad till kortet.
Min mailadress är cpms@bahnhof.se om du vill skicka filer för nu börjar dom bli lite för stora att klistra in i forumet.
Om firmware är konfigurerad så att både BLTouch-proben och en fysisk Z-endstop (eller någon annan oavsiktlig endstop-källa) är aktiverade samtidigt, finns det en risk att en endstop triggas tidigare än avsett under G28-homingsekvensen. Även om själva probningen slutförs korrekt kan en intern endstop-flagga ändå bli satt.
I ett sådant läge kan Marlin senare reagera på detta genom att ändra rörelsebeteende, avbryta moment eller köra oväntade rörelser, beroende på hur endstop-hantering och säkerhetsfunktioner är konfigurerade.
För att kunna utesluta detta på ett korrekt sätt vore det bra att få se båda:
Configuration.h
Configuration_adv.h
Då kan man verifiera att:
Endast avsedd Z-endstop (BLTouch-proben) är aktiverad
Inga gamla eller oanvända Z-endstop-definitioner ligger kvar
Endstop-beteendet under homing och probning stämmer med den faktiska hårdvaran
En probe kan användas antingen som en ren probe, eller som både probe och Z-endstop. Det är viktigt att veta hur du vill att det ska fungera och hur proben är kopplad till kortet.
Min mailadress är cpms@bahnhof.se om du vill skicka filer för nu börjar dom bli lite för stora att klistra in i forumet.
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Okej, här är första raderna i G-koden till att börja med, det verkar som att G29 körs flera gånger vilket faktiskt är det som händer också i alla fall två gånger.
; generated by PrusaSlicer 2.2.0+win64 on 2025-12-18 at 13:05:22 UTC
;
; external perimeters extrusion width = 0.45mm
; perimeters extrusion width = 0.45mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; support material extrusion width = 0.35mm
; first layer extrusion width = 0.42mm
M201 X1000 Y1000 Z500 E5000 ; sets maximum accelerations, mm/sec^2
M203 X200 Y200 Z12 E120 ; sets maximum feedrates, mm/sec
M204 P1250 R1250 T1250 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X5.00 Y5.00 Z0.40 E1.50 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec
M190 S60 ; set bed temperature and wait for it to be reached
M104 S245 ; set temperature
G28 ; home all axes
G29 ; BLtouch
G1 Z5 F20000 ; lift nozzle
M109 S245 ; set temperature and wait for it to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G28 ; Hem
G29 ; BLtouch
; Filament gcode
M106 S89.25
G1 Z0.350 F13800.000
G1 E-2.00000 F2400.00000
G92 E0
Jag mailar även över konfigurationsfilerna för Marlin strax.
; generated by PrusaSlicer 2.2.0+win64 on 2025-12-18 at 13:05:22 UTC
;
; external perimeters extrusion width = 0.45mm
; perimeters extrusion width = 0.45mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; support material extrusion width = 0.35mm
; first layer extrusion width = 0.42mm
M201 X1000 Y1000 Z500 E5000 ; sets maximum accelerations, mm/sec^2
M203 X200 Y200 Z12 E120 ; sets maximum feedrates, mm/sec
M204 P1250 R1250 T1250 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X5.00 Y5.00 Z0.40 E1.50 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec
M190 S60 ; set bed temperature and wait for it to be reached
M104 S245 ; set temperature
G28 ; home all axes
G29 ; BLtouch
G1 Z5 F20000 ; lift nozzle
M109 S245 ; set temperature and wait for it to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G28 ; Hem
G29 ; BLtouch
; Filament gcode
M106 S89.25
G1 Z0.350 F13800.000
G1 E-2.00000 F2400.00000
G92 E0
Jag mailar även över konfigurationsfilerna för Marlin strax.
Re: BLtouch och koden i Marlin?
Efter att ha tittat på filmerna flera gånger till blir bilden nu ännu tydligare.
När startsekvensen kör raden:
G1 Z5 F20000
så betyder det i praktiken:
Z5 = gå till absolut Z = 5 mm
F20000 = 20 000 mm/min, alltså cirka 333 mm/s
F-värdet är den begärda hastigheten för rörelsen.
Marlin försöker då accelerera Z-axeln upp mot denna hastighet, men begränsas av två andra saker:
Maxhastighet (M203)
I din slicade G-kod sätts den till:
M203 Z12
alltså 12 mm/s – högt, men inte extremt.
Acceleration (M201 / M204)
Samma G-kod sätter:
M201 Z500
alltså 500 mm/s² för Z, vilket är mycket högt för en snäck- eller trapetsdriven Z-axel.
Det är här problemet uppstår.
Även om Z rent teoretiskt kan röra sig i 10–12 mm/s, så kräver det att den accelereras dit lugnt.
Med en acceleration på 500 mm/s² försöker Marlin bygga upp hastigheten extremt snabbt, och Z-motorn hinner helt enkelt inte utveckla tillräckligt med moment. Resultatet blir att den stallar nästan direkt och tappar steg.
Det är därför:
det skrapande/knastrande ljudet uppstår just vid den här rörelsen
Z aldrig faktiskt når ner till Z5 pga stallning/tappade steg
skrivaren därefter börjar skriva ut alldeles för högt ovanför plattan
Det viktiga här är alltså samspelet mellan:
en extremt hög begärd hastighet (F20000)
en relativt hög tillåten maxhastighet (M203 Z12)
och framför allt en orimligt hög acceleration på Z (M201 Z500)
Med en rimlig Z-acceleration (t.ex. 20–50 mm/s²) hade Z-axeln sannolikt klarat att röra sig ner mot 12 mm/s utan att tappa steg – trots att F-värdet är helt orimligt.
Det är alltså accelerationen som fäller det här redan i första nedrörelsen.
För att kunna peka ut exakt vilka rader som måste bort eller ändras behöver jag hela start-G-koden, exakt som den ser ut i slicern.
Jag ska kolla igenom konfig-filena men jag är ganska säker på att allt beror på Start-G-koden.
När startsekvensen kör raden:
G1 Z5 F20000
så betyder det i praktiken:
Z5 = gå till absolut Z = 5 mm
F20000 = 20 000 mm/min, alltså cirka 333 mm/s
F-värdet är den begärda hastigheten för rörelsen.
Marlin försöker då accelerera Z-axeln upp mot denna hastighet, men begränsas av två andra saker:
Maxhastighet (M203)
I din slicade G-kod sätts den till:
M203 Z12
alltså 12 mm/s – högt, men inte extremt.
Acceleration (M201 / M204)
Samma G-kod sätter:
M201 Z500
alltså 500 mm/s² för Z, vilket är mycket högt för en snäck- eller trapetsdriven Z-axel.
Det är här problemet uppstår.
Även om Z rent teoretiskt kan röra sig i 10–12 mm/s, så kräver det att den accelereras dit lugnt.
Med en acceleration på 500 mm/s² försöker Marlin bygga upp hastigheten extremt snabbt, och Z-motorn hinner helt enkelt inte utveckla tillräckligt med moment. Resultatet blir att den stallar nästan direkt och tappar steg.
Det är därför:
det skrapande/knastrande ljudet uppstår just vid den här rörelsen
Z aldrig faktiskt når ner till Z5 pga stallning/tappade steg
skrivaren därefter börjar skriva ut alldeles för högt ovanför plattan
Det viktiga här är alltså samspelet mellan:
en extremt hög begärd hastighet (F20000)
en relativt hög tillåten maxhastighet (M203 Z12)
och framför allt en orimligt hög acceleration på Z (M201 Z500)
Med en rimlig Z-acceleration (t.ex. 20–50 mm/s²) hade Z-axeln sannolikt klarat att röra sig ner mot 12 mm/s utan att tappa steg – trots att F-värdet är helt orimligt.
Det är alltså accelerationen som fäller det här redan i första nedrörelsen.
För att kunna peka ut exakt vilka rader som måste bort eller ändras behöver jag hela start-G-koden, exakt som den ser ut i slicern.
Jag ska kolla igenom konfig-filena men jag är ganska säker på att allt beror på Start-G-koden.
Re: BLtouch och koden i Marlin?
Nu när jag tittat på den slicade G-koden lite mer i detalj tror jag att det är bäst att vi tar ett steg tillbaka och tittar på alla G-kodblock som slicern kan bidra med, inte bara Start G-code.
Anledningen är att PrusaSlicer kan injicera G-kod från flera olika ställen, och vi ser redan exempel på Z-rörelser som inte kommer från Start G-code, t.ex. under:
; Filament gcode
G1 Z0.350 F13800
För att verkligen få kontroll på detta vore det toppen om du kan posta innehållet från samtliga relevanta G-kodfält i slicern, till exempel:
Printer Settings → Custom G-code
Start G-code
End G-code
Filament Settings → Custom G-code
Filament start G-code
Filament end G-code
Samt gärna även:
om det finns något Z-relaterat i First layer handling / printer initialization
eller andra fält där du manuellt lagt in G-kod tidigare
Anledningen är att:
slicern just nu uppenbart sätter både Z-höjder och F-värden själv
flera av dessa rörelser sker efter G29
och med orimliga hastigheter för Z, vilket gör att Z tappar steg innan utskriften ens börjar
Kom på en sak.
För att slippa missa någon G-kod som injiceras från slicern (PrusaSlicer har flera ställen där detta kan ske), vore det enklast om du kan exportera en config bundle.
I PrusaSlicer gör du det via:
File → Export → Export Config Bundle…
Då får vi alla printer-, filament- och print-inställningar i en enda fil, inklusive all G-kod som slicern kan generera.
Det är mycket lättare än att klippa ur varje fält manuellt, och minimerar risken att något missas.
Anledningen är att PrusaSlicer kan injicera G-kod från flera olika ställen, och vi ser redan exempel på Z-rörelser som inte kommer från Start G-code, t.ex. under:
; Filament gcode
G1 Z0.350 F13800
För att verkligen få kontroll på detta vore det toppen om du kan posta innehållet från samtliga relevanta G-kodfält i slicern, till exempel:
Printer Settings → Custom G-code
Start G-code
End G-code
Filament Settings → Custom G-code
Filament start G-code
Filament end G-code
Samt gärna även:
om det finns något Z-relaterat i First layer handling / printer initialization
eller andra fält där du manuellt lagt in G-kod tidigare
Anledningen är att:
slicern just nu uppenbart sätter både Z-höjder och F-värden själv
flera av dessa rörelser sker efter G29
och med orimliga hastigheter för Z, vilket gör att Z tappar steg innan utskriften ens börjar
Kom på en sak.
För att slippa missa någon G-kod som injiceras från slicern (PrusaSlicer har flera ställen där detta kan ske), vore det enklast om du kan exportera en config bundle.
I PrusaSlicer gör du det via:
File → Export → Export Config Bundle…
Då får vi alla printer-, filament- och print-inställningar i en enda fil, inklusive all G-kod som slicern kan generera.
Det är mycket lättare än att klippa ur varje fält manuellt, och minimerar risken att något missas.
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Jag tror jag har hittat varför han kör G29 två gånger nu i alla fall.
Under "Filament settings -> Custom G-code" Har jag lagt in detta:
G28 ; Hem
G29 ; BLtouch
; Filament gcode
Sedan under "Printer settings -> Custom G-code" så har jag även:
G28 ; home all axes
G29 ; BLtouch
G1 Z5 F20000 ; lift nozzle
Sen om jag går in och kikar under "Printer settings -> Machine limits" så är "Maximum feedrate Z" på 12mm/s på både "Normal" och "Stealth" och "Maximum acceleration" på 5000mm/s på både "Normal" och "Stealth". "Maximum jerk Z" ligger på 0,4mm/s på både "Normal" och "Stealth".
Men jag skickar över en "Config bundle" också för säkerhets skull.
Under "Filament settings -> Custom G-code" Har jag lagt in detta:
G28 ; Hem
G29 ; BLtouch
; Filament gcode
Sedan under "Printer settings -> Custom G-code" så har jag även:
G28 ; home all axes
G29 ; BLtouch
G1 Z5 F20000 ; lift nozzle
Sen om jag går in och kikar under "Printer settings -> Machine limits" så är "Maximum feedrate Z" på 12mm/s på både "Normal" och "Stealth" och "Maximum acceleration" på 5000mm/s på både "Normal" och "Stealth". "Maximum jerk Z" ligger på 0,4mm/s på både "Normal" och "Stealth".
Men jag skickar över en "Config bundle" också för säkerhets skull.
Re: BLtouch och koden i Marlin?
Mitt förslag till första, kontrollerade åtgärd är att vi gör detta i ordning:
Sänk Z-accelerationen i slicern
I Printer settings → Machine limits
Sätt Maximum acceleration Z till 50 mm/s²
(detta är en rimlig och trygg nivå för en trapets/snäck-driven Z-axel)
Ändra Z-körningen i Start-G-code
Ändra:
G1 Z5 F20000
till:
G1 Z5 F300
(300 mm/min = 5 mm/s, vilket är en helt rimlig Z-hastighet)
Rensa slicern från övrig injicerad G-kod
Säkerställ att:
Endast Start G-code och End G-code används i slicern
Inget G28/G29 eller Z-relaterat finns kvar i:
Filament settings → Custom G-code
andra profiler eller specialfält som kan injicera G-kod
Slica en enkel testmodell och kör igen.
Om du vill vara extra försiktig: var beredd att slå av strömmen om något skulle bete sig konstigt – men med ovanstående ändringar ska Z röra sig lugnt och kontrollerat och inte krascha munstycket i plattan.
Om detta beter sig korrekt vet vi att vi är helt rätt ute, och kan därefter fortsätta att städa upp resten metodiskt (och vid behov justera Marlin).
Sänk Z-accelerationen i slicern
I Printer settings → Machine limits
Sätt Maximum acceleration Z till 50 mm/s²
(detta är en rimlig och trygg nivå för en trapets/snäck-driven Z-axel)
Ändra Z-körningen i Start-G-code
Ändra:
G1 Z5 F20000
till:
G1 Z5 F300
(300 mm/min = 5 mm/s, vilket är en helt rimlig Z-hastighet)
Rensa slicern från övrig injicerad G-kod
Säkerställ att:
Endast Start G-code och End G-code används i slicern
Inget G28/G29 eller Z-relaterat finns kvar i:
Filament settings → Custom G-code
andra profiler eller specialfält som kan injicera G-kod
Slica en enkel testmodell och kör igen.
Om du vill vara extra försiktig: var beredd att slå av strömmen om något skulle bete sig konstigt – men med ovanstående ändringar ska Z röra sig lugnt och kontrollerat och inte krascha munstycket i plattan.
Om detta beter sig korrekt vet vi att vi är helt rätt ute, och kan därefter fortsätta att städa upp resten metodiskt (och vid behov justera Marlin).
-
EPG
- Tidigare pellebeefmaster
- Inlägg: 446
- Blev medlem: 28 mars 2005, 20:27:58
- Ort: Oskarshamn
- Kontakt:
Re: BLtouch och koden i Marlin?
Jag testade att ställa in allt precis så men det verkar inte hjälpa nåt vidare, möjligen att det vibrerar med något lägre amplitud denna gången när den försöker att köra Z i det läget jämfört med tidigare.
Det går ju att köra Z manuellt eller "köra hem" utan några som helst problem heller.
Det går ju att köra Z manuellt eller "köra hem" utan några som helst problem heller.
Re: BLtouch och koden i Marlin?
Konstigt, var helt säker på att det var det som ställde till det. Hittar inget i Marlins konfig filerna som ser konstigt ut.
Slica något och skicka g-koden till min mail så får jag se hur det ser ut. Det måste ju gå att hitta vad det beror på.
Slica något och skicka g-koden till min mail så får jag se hur det ser ut. Det måste ju gå att hitta vad det beror på.
