Mal unabhängig davon ^^...

Ich lande gerade selbst im Chaos.

Ich hatte heute bemerkt, dass beim Drucken der ersten Lage von zwei "Support Base Layers" manchmal die Extrusion nicht gestimmt hat. Das Trat nur auf, wenn die Bahnlänge grob 8cm lang war. (Die Längste)
Also habe ich versucht Advance auszuschalten, das hat aber nicht geholfen.
Dann habe ich bemerkt, dass mein E3D-V6 Heizblock-Gewinde ausgelutscht war und damit mein Hotend gewackelt hat. (Folge von "nach Fest kommt Lose"? Vermutlich..)

Ich hab das jetzt repariert, bin aber immernoch der Meinung, dass da was nicht stimmen kann. Mal sehen.

Wegen dem Fehler der nun ab und an auftritt trau ich mich garnicht mehr zu spekulieren. Ich habe schon geschaut: SoftwareSPI hatten wir glaube ich nie.
Und ich habe die Geschwindigkeit die man bei der Initialisierung mitgeben kann schon reduziert.
fat.begin(SDSS, SD_SCK_MHZ(4));
Wobei ich das vermutlich garnicht müsste. Das war mal ein Test, ob ähnliche Meldungen damit behoben sind. Es gab auch bei Repetier schon ein paar Issues diesbezüglich, da hatte eine kleinere Geschwindigkeit als
#define SPI_FULL_SPEED SD_SCK_MHZ(50)
beim Initialisierungen mancher Karten geholfen.

Interessant wäre nun, ob CrazyJ den Fehler über USB überhaupt nie sieht. Also wirklich nie. Dann liegt es am SD-Treiber oder dem davorliegenden Code. Oder an sonstigem SD-Kram. Definitiv.

LG

Mein heutiger Druck lief mit der FW 1.43.77 ohne Murren anstandslos durch.
Das ist doch schon mal was.

LG AtlonXP

Mein zweiter Druck heute mit der FW 1.43.80 (wieder über USB) ebenso.

Danke für die Tips.
Ein PI macht für mich nicht wirklich Sinn. Der Drucker steht nur 3m entfernt soll aber auch ohne USB funktionieren.
Das mit der Speicherkarte werde ich vielleicht mal probieren. Aber schöner wäre natürlich, wenn das immer sicher funktioniert. Hatte mit der original 1.39 leider bislang noch am wenigsten Probleme.

LG CrazyJ

Ich habe mich heute noch einmal mit den Rucklern (Mikrostopps) beschäftigt. Dazu habe ich mal alle verschiedenen SD-Karten, die ich so habe zusammengesammelt:

- Transcend SD 2GB
- SanDisk SD 1GB
- Xlyne SD 2GB
- Panasonic SDHC (4) 4GB
- Toshiba SDHC (6) 8GB

alle hatten den gleichen GCODE bekommen, und zwar zwei Mal im Kreis fahren. Bei allen Karten gab es zwischen 3 und 6 Rucklern während der Drucker die zwei Kreise absolviert hat.

Danach habe ich mir extra zum ersten Mal RepetierHost installiert - zwei mal den exakt gleichen (vorher von Slic3r erzeugten) GCODE gefahren, KEINE Ruckler!

Außerdem hatte ich auch früher schon einmal y-Ausbrecher beobachtet, aber mir nichts dabei gedacht. Ich dachte das wär so gewollt in der Firmware eingebaut, öfter mal nullen kann ja nicht schaden

Bis jetzt habe ich nur über SD-Karte gedruckt, jetzt werde ich wohl nur noch über RepetierHost und USB drucken. Ich hab übrigens noch die 1.43.20 drauf.

Das deutet gefühlt auf aufwändiges oder langsames Lesen hin.

Wir könnten die SPI-Speed die wir beim "spi.begin" mitgeben wieder auf FULL_SPEED stellen.
Und den CRC Modus deaktivieren, weil dieser offensichtlich den Druckern nicht geholfen hat. Wir hatten den auf Verdacht aktiviert, als ich so einen Bericht über einen Y-Ghost-Move bekam.
->
https://github.com/Nibbels/Repetier-Fir ... fig.h#L131
von 2 auf 0.
(Ab V1.43.11 war das testweise auf CRC-Modus 2)
->
https://github.com/Nibbels/Repetier-Fir ... rd.cpp#L87
und https://github.com/Nibbels/Repetier-Fir ... rd.cpp#L90
von SD_SCK_MHZ(4) auf SPI_FULL_SPEED

Ändern diese Einstellungen was an der Situation?
(Wäre interessant, den du hast das nun im Gefühl.)

.. die 1.43.80+ wird auch schneller sein, aber du hast hier vielleicht einen Flaschenhals entdeckt. Darum ist das spannend.
Ich stelle das für die nächste 1.43.83 so wie hier beschrieben um und teste folglich wieder mit den alten Einstellungen.

OK gut, ich wiederhole das Experiment dann demnächst mit der 1.43.80 und dann mit der 1.43.83

Ich habe jetzt den Code getauscht. Auf meinem persönlichen Github gibts wieder eine etwas mehr experimentelle FW 1.43.84:

Also haben wir jetzt von der Stelle ab, an welcher byteweise eingelesen wird egal ob SD- oder USB-Quelle fast den exakt gleichen Code.
Das Lesen einer Datenquelle ist jetzt nicht mehr einfach nur runterprogrammiert, sondern es gibt wie bei Repetier V1.0.x Klassen:
- SerialGCodeSource
- SDCardGCodeSource
Das macht alles strukturierter und wir sind den alten Code nun los.

Wie oben erwähnt habe ich die SPI_FULL_SPEED wieder eingestellt. Ein Test mit einer Karte von mir war genauso erfolgreich wie bisher. Mehr habe ich noch nicht testen können.

Repetier hat einen GCode M360 der den Drucker die Config ausgeben lässt. Den habe ich nun auch eingebaut. Evtl. kann nun Repetier-Server / Repetier-Host die Einstellungen des Druckers automatisch auslesen, ich konnte das aber auch noch nicht testen.

Compilieren geht ohne Probleme, ich habe jedoch nur 2x einen Druck von SD-Karte gestartet und einmal von USB. Es war nichts auffällig, bis auf dass ich das Beenden eines Druckjobs noch genau inspizieren muss. Bricht man z.B. einen Druck übers Menü ab, dann muss der Drucker automatisch ein korrektes OutputObject machen während dem die Temperaturen auf 0 gestellt werden etc.
Möglichst auch, wenn eine Datenquelle versagt.
Ich muss mir auch nochmal den Fallback anschauen, dass der Drucker nach z.B. 10 Minuten die Stepper ausschalten sollte.
-> Ich muss durchtesten, ob sich die neue Variante bei beliebigen Druck-Ende-Möglichkeiten noch gleich verhält wie früher.

Also diese Version ist noch nicht zwingend zu empfehlen, aber wer Ahnung hat und mag darf gerne testen und mir Rückmeldung geben. Ich werde versuchen morgen Abend mehr zu drucken.

LG

Also..

Ich hab hier jetzt einen Code liegen https://github.com/Nibbels/Repetier-Firmware der 1.43.85 heißt.
Der Teil, welcher aus dem SD-Karten-Byte-Stream (und aus dem USB-Byte-Stream) die Zeichen zu GCodes umwandelt ist fast komplett ausgetauscht und damit vereinheitlicht worden.

Für mich ist nun hochspannend, ob diese Y-0-Moves welche anscheinend nur mit SD-Karten auftraten jetzt verschwunden sind.

Ich konnte heute abend einige Kleinstteile drucken, von SD und USB. Und ich habe mich vorallem aufs Testen von Abbrüchen, Print-Stops etc. konzentriert. Zieht man aktuell den USB-Stecker oder die SD-Karte während des Druckens raus, bleibt der Drucker einfach stehen. Eigentlich passt alles. Mir fiel zumindest kein Problem auf.

Der M360 scheint zu funktionieren. Soweit ich das erkennen kann, funktioniert nun dieser Knopf Hab ich den vorher beachtet? Der hat aber glaube ich nicht nachvollziehbar funktioniert? Drücke ich den Knopf wird M360 abgeschickt. Die Werte kommen zurück und das Profil ist eingestellt.

LG

Hallo Nibbels,
ich habe deine neue .85 Version heute mal "trocken" (ohne Filament und mit niedrigen Temperaturen) getestet. Bei 3 drucken keine Probleme mit der y-Achse oder Microstopps. Ich denk die läuft besser. Sehr gute Arbeit !

Folgendes ist mir aber noch aufgefallen:
Statt mit der y-Achse habe ich das Fahren an den Endschalter jetzt mit der x-Achse. Das Problem tritt auf, wenn folgendes zusammenkommt:
Druck von SD-Karte (über USB scheinbar nicht) und
die Solltemperatur des Extruder wird manuell am Drucker stark verändert (z.B. der Drucker druckt mit 200°C und man stellt auf 180 oder weniger)
->Folge: der Schlitten fährt gegen den x-Endschalter und zurück (ggf. mehrfach, scheinbar bis eine gewisse Schwelle erreicht ist) und druckt dann wieder weiter.

An Lesefehler mit der SD-Karte wird es wohl nicht mehr liegen aber warum ich das nur über SD Karte habe ...???
Während des Drucks scheint also eine Abhängigkeit mit der Temperatur zu bestehen und dadurch ein Verhalten auszulösen. Ist das gewollt und kann das irgendwo eingestellt werden ?

Hallo CrazyJ,
das mit der Temperatur Änderung ist eine gute Beobachtung.

Jetzt wo du es schreibst, in meinem G- Code wo die Z Achse gesponnen hatte (FW 1.43.20?),
waren auch einige Temperatur Änderungen bis zu 20 C° vorhanden.
Das Komische aber ist, dass es in der FW 1.43.77 Problemlos lief.

Na vielleicht hilft es weiter.

LG AtlonXP