Spørgsmål:
Printeren flytter tilfældigt hjem under udskrivning og genoptager derefter som normalt
Tom van der Zanden
2016-04-10 15:31:23 UTC
view on stackexchange narkive permalink

Under udskrivningen foretager min printer lejlighedsvis nogle mystiske bevægelser: den bevæger sig meget langsomt enten X- eller Y-aksen helt til venstre / fronten, før den langsomt bevæger sig tilbage til sin oprindelige position og genoptager udskriften som normalt. Jeg har kontrolleret mine G-kodefiler, og bevægelserne er bestemt ikke en del af G-koden. Hvad kan forårsage dette?

Jeg udskriver fra et SD-kort på en kartesisk printer.

Hvilken firmware (Marlin, ..)? Hvilken printer (kartesisk, delta, ..)? Udvidelser (uden filamentføler, ..)? Kilde til G-koder (udskrivning fra SD-kort eller fra seriel grænseflade)? Det lyder som om printeren holder udskriften på pause. Årsagerne kan være, at der ikke er nogen G-koder (langsom seriel forbindelse) eller noget andet signal (ud af glødetrådssensor udløser)
Spørgsmålet er mærket marlin. Jeg har redigeret spørgsmålet for at inkludere, hvor jeg udskriver fra. Jeg har ikke en glødetrådssensor.
Havde lige det samme problem. Jeg kunne udskrive fint fra computeren, men indlæse den samme fil på disken og få tilfældig rejse til 0-punkterne på x og y helt tilfældigt.
To svar:
Tom van der Zanden
2016-04-11 01:50:22 UTC
view on stackexchange narkive permalink

Problemet skyldtes et korrupt SD-kort, der lejlighedsvis fik noget affald læst fra det. Det viser sig, at Marlin vil prøve at fortolke en korrupt flytkommando som G0 X1q3.54 og stadig læse så mange tal som muligt. I dette eksempel vil det blive fortolket som G0 X1 snarere end (som muligvis været beregnet) G0 X103.54 .

Dette forklarer mine symptomer perfekt:

  • X og Y flyttede altid til (ca.) deres hjemmepositioner, men det var altid kun en af ​​dem (det er ganske usandsynligt, at begge træk er beskadiget).

  • Z blev ikke påvirket, fordi Z-bevægelser er meget sjældnere i G-koden (kun ved lagændring), og det var derfor meget usandsynligt, at et Z-træk ville blive påvirket.

  • E blev ikke berørt, da en anmodning om at flytte E til nær 0 ville blive forhindret af Marlins lange forebyggelse af ekstrudering.

Eurgh! Jeg kan ikke lide, at Marlin gør det. Interessant fund, dog. Vil meget gerne vide, hvordan du fandt ud af det.
Hvad er korrupt i `` G0 X1y3.54 ''?
@Wirewrap Min hensigt var, at den "ukorrupte" G-kode ville have været noget som 'G0 X103.54', og jeg erstattede 0 med et tilfældigt tegn. Desværre valgte jeg en virkelig forvirrende tilfældig karakter. Tak fordi du påpegede det.
Trish
2018-08-19 13:41:29 UTC
view on stackexchange narkive permalink

Udover et korrupt SD-kort, der gemmer arbejdsbits, hvilket fører til absurde kommandoer, er det også muligt, at andre dele i filens Creatin er kompromitteret:

Dette kan f.eks. ske, hvis kortet fjernes under skrivning - men i dette tilfælde skal det for det meste være en ufuldstændig fil ved import til en tolk.

Mere vil en tilfældig fordeling af dårlige kommandoer vises, hvis skriveprocessen i sig selv er defekt, for eksempel hvis SD Porten er defekt, eller adapteren har en fejl. En anden måde, som skrivning kan mislykkes på, er, hvis driverne til SD-kortadapteren / porten er beskadiget.

At detektere en dårlig fil eller et beskadiget kort er muligt ved at genimportere G-koden til en udskæring (f.eks. tillader CURA dette) og se på værktøjsstierne. Hvis en port gør dette med et hvilket som helst kort, er software skylden: Se om den fortsætter efter en driveropdatering (sjælden!) Og en geninstallation af udskæreren. Hvis det fejler i en port, men fungerer i en anden, kan porten eller adapteren muligvis være skyld og muligvis udskiftes. Hvis det er endemisk med et kort, er dette korrupt og skal kastes ud. Hvis det er endemisk for en enkelt fil, skal du overskrive den med en ny - undertiden mislykkes skrivning af grunde, der næsten er umulige at forstå.

Hvis filen &card er fint, men læses forkert på printeren, så er kortet læser i printeren eller tavlen har skylden.



Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...