Anet A6 verspringt lagen in X-Y richting

[Ahjwinth]

Vandaag een vreemd probleem. Na een lange print (14 Uur) en nog 1 uur te gaan zijn opeens de lagen versprongen.
Zie de foto. Nadat ik de print had gestopt heb ik de x/y nulpunten gecontroleerd en deze stonden nog steeds goed. Door handmatig de X & Y as te verplaatsen naar de limit switch kwam de afstand indicatie keurig op 0 uit. Dus het kan niet een mechanisch probleem zijn dat de stappen motor is versprongen of een snaar. Dit is zowie zo vreemd want x/y verspringt tegelijk.
Heeft iemand een idee?

Ik gebruik Cura om te slicen, een RPI 3 met octoprint om te printen. Ik gebrui de SD kaart in de Octopi. Printer is een Anet A6 met de standaard bijgeleverde firmware. Staat nog op de todo lijst om te upgraden naar Marlin.

Nadat ik de fout had ontdekt heb ik nog gekeken in de Gcode viewer van octopi of er een fout in het bestand zat maar de lagen waren keurig netjes boven elkaar in de Gcode.

[kaphaak]

Dit lijkt eerder op een probleem met de riemen niet goed afgesteld, te los of te strak, kijk eens naar je x-as en y-as riemen zou ik zeggen.

Grtz Ronald.

[3drob]

Hallo,

Ga mee met Ronald in eerste instantie,
maar kijk uit je hebt ook allerlei spulletjes zoals RPI 3 en SD kaart en je weet niet wat daar allemaal mee fout kan gaan.
Ik doe een paar dingetjes opgooien en jij moet dat dan even controleren, goed?
Ik zelf heb problemen gehad met de SOORT, SD kaart andere hogere kwaliteit was de oplossing toen voor mij.
En dan dat moederboard met die steppers(stepstickjes) bij mij kon ik ze afregelen -
(ik heb ik heb Arduino met Ramps 1.4 en stepstickjes)
Jij kunt geloof ik niets aan het geheel doen,
Maar wat je wel kunt is een goed ventilatortje er op zetten zodat alles zo koel mogelijk blijft!
Heb ik ook gedaan! En of andere PC ventilator er bij en gaaannn, Koelt de FETs de stepper chips alles.

En voor de rest weet ik niks meer te verzinnen!
Een van deze dingetjes moeten het toch zijn denk ik.

VrGr Rob.

[hardy]

Het lijkt op een interrupt bij het aansturen van de stepperdrivers/processor, het heeft schijnbaar ook maar 1 keer plaatsgevonden tijdens het tegelijk verplaatsen van X en Y, want na dat verspringen is het weer normaal verder gegaan zo te zien, misschien dat toch die raspberry dat heeft veroorzaakt doordat daar iets in het programma even voorrang gekregen heeft bij de data overdracht, ik ben zelf ook niet zo'n liefhebber van draadloze overdracht bij dit soort processen, omdat het heel nauw luistert met de data overdracht, maar ik ken octoprint verder ook niet precies.

Hardy

[phtvs]

Ik heb precies hetzelfde probleem gehad en idd was de RPI de boosdoener bij mij. Ik print nu weer gewoon vanaf sd-kaart in de Anet en sindsdien geen enkel probleem meer.

[Ahjwinth]

Iedereen bedankt voor de reactie. Ik heb nogmaals alles mechanisch nagelopen maar de tandwielen op de stappenmotors zitten allemaal vast. De tandriemen zijn niet te slap dus mechanisch sluit ik uit dat er iets aan de hand is. Dus er blijft voor mij iets software matig/elektrisch over. De octoprint werkt goed op de RPI maar ik zal in het vervolg de grotere objecten toch maar direct vanaf de SD kaart printen ipv de octoprint.
De overdracht van de RPI naar de printer gaat via de USB kabel dus niet draadloos. Enkel het laden van de gcode gaat via de WiFi. Als het bestand eenmaal geladen is op de octoprint word de WiFi niet meer gebruikt.
Inmiddels heb ik een aantal andere prints gemaakt zonder problemen. Bedankt voor het meedenken.