Chiron bleibt einfach stehen!

Hi all,

ich hab mir Anfang der Woche Repetier Server Pro gekauft.

Gefällt mir eigentlich gut aber mein Drucker Anycubic Chiron bleibt wärend des Druckes einfach stehen!
Er reagiert auf keine Befehle mehr, erst wenn ich das Usb kabel kurz trenne geht er wieder.

Retten geht nicht, weil ich nie weiß wo er stehn geblieben ist... 

Ich arbeite jetzt schon seit Tagen daran aber es klappt einfach nicht.

Ich habe einen Anycubic Chiron
Rasbperry Pi 4 4gb Ram (mit Zusatzkühler und Zusatzlüfter)
64GB Sandisc A2
Pi ist mit LAN im Netzwerk
5.1V 3A USB-C Netzteil
7" Orginal PI Touchscreen

Ich habe das USB und Netzwerkkabel schon getauscht

Ich verwende die Orginal RP Image Repetier-Server-0.94.1
Aktuell die Repetier-Server-0.94.2 
Mein Pi ist auch Up to date 

5V Pin am USB Kabel ist abgeklebt 
Mit und ohne USB HUB getestet
Modemmanager ist deinstalliert

Marlin verwende ich diese her:
https://www.thingiverse.com/thing:3866011?fbclid=IwAR1gazy53zGG7NO7NMOXRUwwn3bEZc-2c4eaqVdRRVnmQi4-BBs4YC24OVU

Hier die letzten Zeilen von der Konsole:
https://pastebin.com/ymmwVB8f

Hier ein Video von meiner RP Druckersetup:
https://youtu.be/WywSjS2sdO8


Hoffe ihr könnt mir helfen.

Comments

  • Du kannst noch die Anzeige auf dem Drucker LCD deaktivieren. Mein Anycubic I3 zeigt die zumindest eh nicht an, wenn das hier genau so ist ist es nur erhöhtes Risiko und vielleicht gibt es ja inhalte die ihn stören.

    Was aber heir zu passieren scheint ist das die Firmware die gesendeten Befehle nicht mehr erhält oder nicht mehr antwortet. Da du nicht sagst das sich was bewegt würde ich nicht erhält sagen. Aber man sieht das der Server sie noch sendet. Da ist also etwas im Kommunikationsweg das schief läuft wenn ich annehme das die Firmware noch läuft. Kommt bei einigen Geräten leider schon mal vor, auch wenn ich selber es noch nicht hatte. 

    Kannst du bei der Firmware in configration_adv.h

    // Bad Serial-connections can miss a received command by sending an 'ok'
    // Therefore some clients abort after 30 seconds in a timeout.
    // Some other clients start sending commands while receiving a 'wait'.
    // This "wait" is only sent when the buffer is empty. 1 second is a good value here.
    //#define NO_TIMEOUTS 1000 // Milliseconds

    // Some clients will have this feature soon. This could make the NO_TIMEOUTS unnecessary.
    //#define ADVANCED_OK

    auf

    // Bad Serial-connections can miss a received command by sending an 'ok'
    // Therefore some clients abort after 30 seconds in a timeout.
    // Some other clients start sending commands while receiving a 'wait'.
    // This "wait" is only sent when the buffer is empty. 1 second is a good value here.
    #define NO_TIMEOUTS 1000 // Milliseconds

    // Some clients will have this feature soon. This could make the NO_TIMEOUTS unnecessary.
    #define ADVANCED_OK

    setzen? Dann hast du erstens eine bessere Fehlerkontrolle in der Firmware und wenn die Firmware nichts empfängt würde sie "wait" senden, was du dann in der konsole bei deaktiviertem ACK sehen solltest. Wenn es dann wieder passiert sieht man dann ob die firmware noch mit antworten durchkommt. 

    Meine Vermutung ist aber das sich irgendwo der serial-usb-serial stack wegen irgendwas durcheinander kommt und nicht mehr korrekt sendet. Daher klappt nach dem aus und einstecken des usb Kabels auch wieder alles. Damit wird der Treiber neu initialisiert. Hilft dabei auch der emergency stop? Der versucht ja ein reset der firmware zu verursachen. Bei meinem I3 piept dann das Display. Bin aber nicht sicher ob das auch die serielle firmware auf dem board zurück setzt.
  • Vielen dank für die Ausführliche Antwort!

    #define NO_TIMEOUTS 1000
    #define ADVANCED_OK

    hab auch auskommandiert und starte gleich mal einen druck

    den Emergancy Stop hab ich noch nicht getestet
  • genau das selbe ... in der Console steht jetzt:
    Mesg:22:26:11.374: Warning: Communication timeout - resetting communication buffer.
    Mesg:22:26:11.374: Connection status: Buffered:39, Manual Commands: 1, Job Commands: 5000
    Mesg:22:26:11.374: Buffer used:39 Enforced free byte:0 lines stored:1
    Mesg:22:26:42.375: Warning: Communication timeout - resetting communication buffer.
    Mesg:22:26:42.376: Connection status: Buffered:17, Manual Commands: 1, Job Commands: 5000
    Mesg:22:26:42.376: Buffer used:17 Enforced free byte:0 lines stored:1
    Mesg:22:27:13.378: Warning: Communication timeout - resetting communication buffer.
    Mesg:22:27:13.378: Connection status: Buffered:24, Manual Commands: 1, Job Commands: 5000
    Mesg:22:27:13.378: Buffer used:24 Enforced free byte:0 lines stored:1
    Mesg:22:27:13.378: Warning: Too many timeouts without response - disabling timeout message!
    Mesg:23:26:53.026: Dtr: false Rts: true (3)
  • Hattest du ACK anzeige aktiviert in der Konsole? Ging ja in erste Linie darum zu sehen ob die Firmware noch Daten sendet bzw ob noch welche empfangen werden können. Wenn das der Fall war ist das ein Problem.

    Kannst du noch im Server deaktivieren und wieder neu verbinden testen - Druck wird hin sein aber wenn er dann wieder Kommuniziert heist das, dass ich den kom stack auch softwareseitig wieder herstellen kann. Dann kann ich beipielsweise beim zweiten timeout ein reconnect erzwingen und so eventuell weiter drucken.

    Meldet der Drucker eigentlich "busy" bei langen operationen wie homing? Dann kann man sogar das timeout auf 3 Sekunden reduzieren, so dass er nach 6 Sekunden wieder weiter drucken würde.
  • wo aktiviere ich denn ACK?

    Hab nirgends so eine einstellung gefunden
  • Ind er konsole. In der deutschen Version heist der Punkt "Bestätigungen". Normal nur für den Server interessant, aber wenn man die Dialoge korrekt verfolgen will doch wichtig.
  • immer noch das selbe problem - der Drucker hat jetzt 23h ohne probleme gedruckt und nun spackt er wieder!!!




    Send: 0:33:43.406: N180348 G1 X28.025 Y82.525 F6000
    Recv: 0:33:44.430: ok N180347 P0 B2
    Send: 0:33:44.430: N180349 G1 Z22.400 F2400
    Mesg: 0:34:15.435: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:34:15.435: Connection status: Buffered:65, Manual Commands: 1, Job Commands: 774
    Mesg: 0:34:15.435: Buffer used:65 Enforced free byte:18 lines stored:2
    Send: 0:34:15.435: M117 ETE 00:30:10
    Send: 0:34:15.435: N180350 G1 E0.0000 F2400
    Send: 0:34:15.436: N180351 G92 E0.0000
    Mesg: 0:34:46.436: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:34:46.436: Connection status: Buffered:69, Manual Commands: 1, Job Commands: 772
    Mesg: 0:34:46.436: Buffer used:69 Enforced free byte:45 lines stored:3
    Send: 0:34:46.436: M117 Layer 111/125
    Send: 0:34:46.436: N180352 G1 X376.975 Y82.525 E9.3429 F2700
    Mesg: 0:35:17.443: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:35:17.444: Connection status: Buffered:64, Manual Commands: 1, Job Commands: 771
    Mesg: 0:35:17.444: Buffer used:64 Enforced free byte:41 lines stored:2
    Send: 0:35:17.444: M117 ETA 01:05:03 day 11
    Send: 0:35:17.444: N180353 G1 X376.975 Y331.475 E16.0084
    Mesg: 0:35:48.450: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:35:48.451: Connection status: Buffered:66, Manual Commands: 2, Job Commands: 770
    Mesg: 0:35:48.451: Buffer used:66 Enforced free byte:40 lines stored:2
    Send: 0:35:48.451: M117 ETE 00:30:10
    Send: 0:35:48.451: N180354 M106 P0 S255
    Send: 0:35:53.297: M117 Layer 112/125
    Mesg: 0:36:24.304: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:36:24.304: Connection status: Buffered:61, Manual Commands: 1, Job Commands: 770
    Mesg: 0:36:24.304: Buffer used:61 Enforced free byte:40 lines stored:3
    Send: 0:36:24.304: M117 ETA 01:06:13 day 11
    Send: 0:36:24.304: N180355 G1 X28.025 Y331.475 E25.3513
    Mesg: 0:36:55.305: Warning: Communication timeout - resetting communication buffer.
    Mesg: 0:36:55.305: Connection status: Buffered:65, Manual Commands: 1, Job Commands: 769
    Mesg: 0:36:55.305: Buffer used:65 Enforced free byte:39 lines stored:2
    Send: 0:36:55.305: M117 ETE 00:29:58
    Send: 0:36:55.305: N180356 G1 X28.025 Y82.525 E32.0168
  • Wie man sieht sendet der server noch Befehle nur antwortet die Firmware des Druckers nicht mehr. Es ist also definitiv nicht einfach ein Kommunikationsfehler der durch uns behoben werden kann. Das ist also kein Fehler im Server selbst und kann daher nicht durch uns gelöst werden.

    Wer hier auf dem Schlauch steht kann man leider nicht sehen. Die möglichen Komponenten sind:
    - Linux serial Treiber
    - Drucker USB->Serial Wandler
    - Drucker Firmware
    - USB Kabel verursacht Probleme die dann nicht mehr behoben werden können.

    Eine dieser vier Komponenten ist durcheinander und sendet/empfängt keine Daten mehr. Was du ändern kannst ist das USB Kabel - ob es hilft kann ich nicht sagen. Am besten kurz, geschirmt mit Eisenkern am Ende. Die Vermutung liegt nahe das durch Störungen einer der Treiber auf dem falschen Fuß erwischt wird und dann nicht mehr korrekt funktioniert. Oder aber eine Spannungsschwankung oder andere Störung verursacht eine Störung im Treiber am Drucker.
  • habe gestern mit dem Anycubic geschrieben und denen den Fehler erklärt.

    Sie vermuten den fehler in einem der Kabelbäume oder einer der Adapterplatinen.
    Sie schicken mit sämtliche Kabel und Adapterplatinen neu zu.
  • Kann gut sein. Pass insbesondere mit Kabeln für Kommunikation USB auf das die NICHT in die nähe von Heizkabeln und Motorkabeln kommen. Durch Induktion können da auch gerne mal falsche Signale dann durchkommen die den Treiber durcheinander bringen oder eine Platine hat ein elektronik problem. Alles möglich.
  • Alle Kabel und Adapterplatinen getauscht:



    immer noch das selbe problem!

    Er bleibt einfach stehen - steht 1-2 min und fährt dann wieder nur EINEN Befehel und steht dann wieder 1-2 min

    Send: 7:38:54.416: N190789 G1 X272.048 Y328.880 E393.9572
    Recv: 7:38:54.416: wait
    Recv: 7:38:55.336: ok N190789 P0 B3
    Send: 7:38:55.337: N190790 G1 X374.379 Y226.549 E404.3540
    Recv: 7:38:55.401:  T:209.79 /210.00 B:60.30 /60.00 @:107 B@:9
    Recv: 7:38:56.402:  T:209.64 /210.00 B:59.94 /60.00 @:111 B@:29
    Recv: 7:38:57.341: echo:busy: processing
    Recv: 7:38:57.403:  T:210.00 /210.00 B:60.28 /60.00 @:103 B@:10
    Recv: 7:38:58.399: ok N190790 P0 B3
    Recv: 7:38:58.399: wait
    Send: 7:38:58.400: N190791 G1 X374.379 Y225.191 E404.4515
    Recv: 7:38:58.405:  T:210.00 /210.00 B:60.07 /60.00 @:103 B@:21
    Recv: 7:38:59.406:  T:209.93 /210.00 B:59.85 /60.00 @:106 B@:34
    Mesg: 7:39:59.402: Warning: Communication timeout - resetting communication buffer.
    Mesg: 7:39:59.402: Connection status: Buffered:42, Manual Commands: 0, Job Commands: 5000
    Mesg: 7:39:59.402: Buffer used:42 Enforced free byte:42 lines stored:1
    Send: 7:39:59.403: N190792 G1 X270.690 Y328.880 E414.9863
    Mesg: 7:41:00.403: Warning: Communication timeout - resetting communication buffer.
    Mesg: 7:41:00.403: Connection status: Buffered:42, Manual Commands: 0, Job Commands: 5000
    Mesg: 7:41:00.403: Buffer used:42 Enforced free byte:42 lines stored:1
    Send: 7:41:00.403: N190793 G1 X269.333 Y328.880 E415.0838
    Mesg: 7:42:01.405: Warning: Communication timeout - resetting communication buffer.
    Mesg: 7:42:01.405: Connection status: Buffered:42, Manual Commands: 0, Job Commands: 5000
    Mesg: 7:42:01.406: Buffer used:42 Enforced free byte:42 lines stored:1
    Mesg: 7:42:01.406: Warning: Too many timeouts without response - disabling timeout message!
    Send: 7:42:01.406: N190794 G1 X374.379 Y223.834 E425.7565
    Send: 7:43:02.412: N190795 G1 X374.379 Y222.476 E425.8540
    Send: 7:44:03.418: N190796 G1 X267.975 Y328.880 E436.6646
    Send: 7:45:04.427: N190797 G1 X266.617 Y328.880 E436.7622
    Send: 7:46:05.432: N190798 G1 X374.379 Y221.118 E447.7107
    Send: 7:47:06.436: N190799 G1 X374.379 Y219.761 E447.8083
    Send: 7:48:07.445: N190800 G1 X265.260 Y328.880 E458.8948
    Send: 7:49:08.449: N190801 G1 X263.902 Y328.880 E458.9923
    Send: 7:50:09.450: N190802 G1 X374.379 Y218.403 E470.2167
    Send: 7:51:10.457: N190803 G1 X374.379 Y217.045 E470.3143
    Send: 7:52:11.462: N190804 G1 X262.544 Y328.880 E481.6766
    Send: 7:53:12.466: N190805 G1 X261.187 Y328.880 E481.7742


  • Ok, also werden die Befehle die der Server schickt zwischen den Timeouts tatsächlich ausgeführt. Das war ja eine der offenen Fragen ob die Kommunikation steht oder nicht. Senden klappt hier nur weil wir kein "ok" zurück bekommen denkt der server das die Firmware beschäftigt ist und wartet auf den nächsten Timeout. Frage ist also warum schickt die Firmware plötzlich keine antworten mehr oder wenn sie es tut wo gehen sie verloren. Die Antwort dazu kenne ich aber leider nicht:-(
  • das problem hängt auf jedenfall mit Repetier-Server zusammen

    Wenn ich per SD karte drucke - läuft er ohne probleme durch!

    Hardwareprobleme kann ich ausschließen
    Mehrere Pis versucht
    Mehrere SD karten versucht
    Kühlung optimiert
    5V am kabel abgeklebt
    Mehrere Kabel (hocherwertige)
    Sämtliche Kabel und Platinen erneuert
    Mehrere Firmware versionen getestet
    Mehrere Repetierserver Versionen getestet

  • SD Karte muss nicht über serielle Schnittstelle reden, das zählt nicht und grade da hängt ja das Problem.

    Hast du mal server unter Windows versucht?
    Auch einen Versuch wert wäre ping pong zu aktivieren in den Kommunikationseinstellungen. Normalnicht nötig aber bei machen Usern ändert sich manchmal was weil die Firmware nicht damit zurecht kommt. Wobei es ja hier eigentlich immer eine weile geht und dann gibt es Probleme.
  • Nein unter Windows habe ich es noch nicht probiert.

    Aber werde ich heute abend mal probieren.


    Pingpong habe ich schon versucht - selbe Ergebnisse
    Nach einer weile bleibt er wieder stehen :-(
Sign In or Register to comment.