›

Drucker Bleiben Stehen

Stefan410Stefan410
edited September 2021 in Repetier-Server
Hallo. Ich habe seit einiger zeit leider ein Problem.

Ich habe hier ein Raspberry Pi 4 mit 2 Drucker am Laufen
- I3 Mega
- Chiron
- Pi Cam
- PS3 Cam
- 7Zoll Touchdisplay
- Netzwerkanbindung über Lan

Mit SD Karte läuft durch und absolut kein Problem.
Allerdings ist es jetzt seit einiger zeit so das kein Druck mehr zu stande kommt über den Pi.

Es läuft alles bis zu einen gewissen Punkt und dann fängt alles an zu stocken. Egal bei welchen layer. Mal nach 10 minuten dann auch mal nach 4 stunden.
-USB Neuverbindung bei timeout, sorgt dafür das der durcker komplett neu startet und den Druck in die warteschleife hängt.
-Neuverbingung auf Nie, Drucker stockt aber nach USB Raus und Rein läuft er wieder.
-Pingpong An oder aus macht keinen unterschied.
-Byte von 64 bis 255, alles ausprobiert.
-USB Kabel erneuert
-5v Am usb abgeklemmt
-Original Netzteil erneuert
-Verschiedene Marlin Versionen auf beiden Druckern Versucht
-Repetier neu aufgesetzt mit der akutellsten Version 1.1.2

Das Problem hatte ich damals kurzfrisig aber war danach weg wie von geisterhand. Habe wochen lang ruhe gehabt. Jetzt seit 5 tagen ist das Problem ständig da. überwiegend bei dem Chiron. Manchmal fangen beide Gleichzeitig an. manchmal nur einer von beiden. Es lässt sich leider auch nicht Reproduzieren.

Ich habe allerdings den eindruck wenn ein drucker ausgesteckt ist dann läuft der andere ohne Probleme Durck das kann allerdings auch zufall sein.

In der Konsole wird mir dann folgenes angezeigt:
Chiron:
Recv: 2:07:25.412: //action:notification ETA 05 40 00 day 18
Recv: 2:07:35.403: ok (66)
Recv: 2:07:35.406: //action:notification ETE 03 32 27
Recv: 2:07:46.081: ok (21)
Recv: 2:07:46.084: //action:notification Layer 4/99
Recv: 2:07:55.733: ok (32)
Recv: 2:07:55.737: //action:notification ETA 05 40 02 day 18
Recv: 2:08:05.489: ok (35)
Recv: 2:08:05.492: //action:notification ETE 03 31 58
Recv: 2:08:15.256: ok (35)
Recv: 2:08:15.259: //action:notification Layer 4/99
Recv: 2:08:25.590: ok (38)
Recv: 2:08:25.593: //action:notification ETA 05 40 04 day 18
Recv: 2:08:35.472: ok (46)
Recv: 2:08:35.475: //action:notification ETE 03 31 28
Recv: 2:08:45.520: ok (37)
Recv: 2:08:45.522: //action:notification Layer 4/99
Recv: 2:08:55.644: ok (33)
Recv: 2:08:55.648: //action:notification ETA 05 40 06 day 18
Recv: 2:09:05.191: ok (32)
Recv: 2:09:05.195: //action:notification ETE 03 31 02
Recv: 2:09:15.967: ok (24)
Recv: 2:09:15.970: //action:notification Layer 4/99
Recv: 2:09:26.154: ok (16)
Recv: 2:09:26.158: //action:notification ETA 05 40 13 day 18
Recv: 2:09:36.281: ok (13)
Recv: 2:09:36.284: //action:notification ETE 03 30 40
Recv: 2:09:41.851: ok (10)
Mesg: 2:09:45.859: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:09:45.859: Connection status: Buffered:49, Manual Commands: 1, Job Commands: 5000
Mesg: 2:09:45.859: Buffer used:49 Enforced free byte:0 lines stored:1
Recv: 2:09:45.862: //action:notification Layer 4/99
Recv: 2:09:56.299: ok (19)
Recv: 2:09:56.302: //action:notification ETA 05 40 14 day 18
Recv: 2:10:05.227: ok (22)
Recv: 2:10:05.230: //action:notification ETE 03 30 04
Recv: 2:10:15.279: ok (69)
Recv: 2:10:15.282: //action:notification Layer 4/99
Recv: 2:10:25.325: ok (31)
Recv: 2:10:25.329: //action:notification ETA 05 40 11 day 18
Recv: 2:10:35.188: ok (27)
Recv: 2:10:35.191: //action:notification ETE 03 29 36
Recv: 2:10:45.170: ok (35)
Recv: 2:10:45.173: //action:notification Layer 4/99
Recv: 2:10:55.186: ok (40)
Recv: 2:10:55.190: //action:notification ETA 05 40 10 day 18
Recv: 2:11:05.484: ok (52)
Recv: 2:11:05.487: //action:notification ETE 03 29 07
Recv: 2:11:15.372: ok (39)
Recv: 2:11:15.374: //action:notification Layer 4/99
Recv: 2:11:25.244: ok (39)
Recv: 2:11:25.248: //action:notification ETA 05 40 13 day 18
Recv: 2:11:35.123: ok (27)
Recv: 2:11:35.126: //action:notification ETE 03 28 42
Recv: 2:11:45.760: ok (16)
Recv: 2:11:45.763: //action:notification Layer 4/99
Recv: 2:11:55.456: ok (25)
Recv: 2:11:55.460: //action:notification ETA 05 40 16 day 18
Recv: 2:12:05.481: ok (22)
Recv: 2:12:05.484: //action:notification ETE 03 28 13
Recv: 2:12:15.164: ok (31)
Recv: 2:12:15.167: //action:notification Layer 4/99
Recv: 2:12:26.348: ok (15)
Recv: 2:12:26.352: //action:notification ETA 05 40 22 day 18
Recv: 2:12:35.923: ok (13)
Recv: 2:12:35.926: //action:notification ETE 03 27 48
Recv: 2:12:45.498: ok (13)
Recv: 2:12:45.501: //action:notification Layer 4/99
Recv: 2:12:55.738: ok (16)
Recv: 2:12:55.741: //action:notification ETA 05 40 23 day 18
Recv: 2:13:05.542: ok (17)
Recv: 2:13:05.545: //action:notification ETE 03 27 16
Recv: 2:13:15.247: ok (19)
Recv: 2:13:15.250: //action:notification Layer 4/99
Recv: 2:13:25.859: ok (20)
Recv: 2:13:25.863: //action:notification ETA 05 40 20 day 18
Recv: 2:13:35.253: ok (54)
Recv: 2:13:35.256: //action:notification ETE 03 26 41
Recv: 2:13:45.600: ok (23)
Recv: 2:13:45.603: //action:notification Layer 4/99
Recv: 2:13:55.185: ok (17)
Recv: 2:13:55.189: //action:notification ETA 05 40 24 day 18
Recv: 2:14:05.097: ok (28)
Recv: 2:14:05.100: //action:notification ETE 03 26 13
Recv: 2:14:15.946: ok (56)
Recv: 2:14:15.949: //action:notification Layer 4/99
Recv: 2:14:25.139: ok (23)
Recv: 2:14:25.142: //action:notification ETA 05 40 22 day 18
Recv: 2:14:35.425: ok (29)
Recv: 2:14:35.428: //action:notification ETE 03 25 46
Recv: 2:14:45.492: ok (35)
Recv: 2:14:45.495: //action:notification Layer 4/99
Recv: 2:14:55.261: ok (36)
Recv: 2:14:55.265: //action:notification ETA 05 40 22 day 18
Recv: 2:15:05.068: ok (47)
Recv: 2:15:05.071: //action:notification ETE 03 25 16
Recv: 2:15:15.324: ok (36)
Recv: 2:15:15.327: //action:notification Layer 4/99
Recv: 2:15:25.449: ok (33)
Recv: 2:15:25.453: //action:notification ETA 05 40 24 day 18
Recv: 2:15:35.575: ok (33)
Recv: 2:15:35.578: //action:notification ETE 03 24 49
Recv: 2:15:45.044: ok (53)
Recv: 2:15:45.047: //action:notification Layer 4/99
Recv: 2:15:55.165: ok (43)
Recv: 2:15:55.169: //action:notification ETA 05 40 28 day 18
Recv: 2:16:05.146: ok (27)
Recv: 2:16:05.149: //action:notification ETE 03 24 22
Recv: 2:16:15.289: ok (35)
Recv: 2:16:15.292: //action:notification Layer 4/99
Recv: 2:16:25.071: ok (37)
Recv: 2:16:25.075: //action:notification ETA 05 40 27 day 18
Recv: 2:16:35.200: ok (53)
Recv: 2:16:35.203: //action:notification ETE 03 23 53
Recv: 2:29:55.774: ok (34)
Recv: 2:29:55.776: //action:notification ETA 05 41 29 day 18
Recv: 2:30:05.548: ok (35)
Recv: 2:30:05.550: //action:notification ETE 03 11 25
Recv: 2:30:15.298: ok (35)
Recv: 2:30:15.299: //action:notification Layer 5/99
Recv: 2:30:25.686: ok (42)
Recv: 2:30:25.688: //action:notification ETA 05 41 33 day 18
Recv: 2:30:35.406: ok (24)
Recv: 2:30:35.407: //action:notification ETE 03 10 59
Recv: 2:30:45.358: ok (81)
Recv: 2:30:45.359: //action:notification Layer 5/99
Recv: 2:30:55.829: ok (93)
Recv: 2:30:55.833: //action:notification ETA 05 41 33 day 18
Recv: 2:31:05.331: ok (118)
Recv: 2:31:05.334: //action:notification ETE 03 10 29
Recv: 2:31:15.176: ok (65)
Recv: 2:31:15.179: //action:notification Layer 6/99
Recv: 2:31:24.719: ok (66)
Mesg: 2:31:28.719: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:31:28.719: Connection status: Buffered:41, Manual Commands: 1, Job Commands: 5000
Mesg: 2:31:28.720: Buffer used:41 Enforced free byte:0 lines stored:1
Recv: 2:31:28.724: //action:notification ETA 05 41 35 day 18
Recv: 2:31:35.278: ok (77)
Recv: 2:31:35.281: //action:notification ETE 03 10 04
Recv: 2:31:45.245: ok (72)
Recv: 2:31:45.248: //action:notification Layer 6/99
Recv: 2:31:50.400: ok (47)
Mesg: 2:31:54.406: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:31:54.406: Connection status: Buffered:39, Manual Commands: 0, Job Commands: 5000
Mesg: 2:31:54.406: Buffer used:39 Enforced free byte:0 lines stored:1
Mesg: 2:31:58.413: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:31:58.413: Connection status: Buffered:31, Manual Commands: 1, Job Commands: 5000
Mesg: 2:31:58.413: Buffer used:31 Enforced free byte:0 lines stored:1
Mesg: 2:32:02.418: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:32:02.418: Connection status: Buffered:25, Manual Commands: 0, Job Commands: 5000
Mesg: 2:32:02.418: Buffer used:25 Enforced free byte:0 lines stored:1
Mesg: 2:32:02.419: Warning: Too many timeouts without response - disabling timeout message!
Mesg: 2:32:02.419: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!
Mesg: 2:32:02.419: This helps in case it is the serial driver that hangs.
Mesg: 2:32:59.691: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
Mesg: 2:33:00.398: Dtr: true Rts: true
Mesg: 2:33:00.399: Connection continued
Recv: 2:33:00.401: echo:Unknown command: "80.00 /80.00 @:58 B@:40"
Recv: 2:33:05.245: ok (53)
Recv: 2:33:05.248: //action:notification ETE 03 09 43
Recv: 2:33:15.561: ok (59)
Recv: 2:33:15.564: //action:notification Layer 6/99
Recv: 2:33:25.152: ok (53)
Recv: 2:33:25.156: //action:notification ETA 05 42 50 day 18
Recv: 2:33:35.170: ok (65)
Recv: 2:33:35.173: //action:notification ETE 03 09 15
Recv: 2:33:45.298: ok (55)
Recv: 2:33:45.301: //action:notification Layer 6/99
Recv: 2:33:55.650: ok (49)
Recv: 2:33:55.655: //action:notification ETA 05 42 51 day 18
Recv: 2:33:57.428: ok (40)

I3 Mega:
Mesg: 2:28:56.214: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:28:56.214: Connection status: Buffered:41, Manual Commands: 1, Job Commands: 5000
Mesg: 2:28:56.214: Buffer used:41 Enforced free byte:0 lines stored:1
Mesg: 2:29:03.215: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:29:03.215: Connection status: Buffered:25, Manual Commands: 0, Job Commands: 5000
Mesg: 2:29:03.215: Buffer used:25 Enforced free byte:0 lines stored:1
Mesg: 2:29:06.451: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
Mesg: 2:29:08.061: Dtr: true Rts: true
Mesg: 2:29:08.062: Connection continued
Recv: 2:29:08.064: echo:Unknown command: "60.00 /60.00 @:65 B@:44"
Mesg: 2:31:31.719: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:31:31.719: Connection status: Buffered:47, Manual Commands: 1, Job Commands: 5000
Mesg: 2:31:31.719: Buffer used:47 Enforced free byte:0 lines stored:1
Mesg: 2:31:57.428: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:31:57.428: Connection status: Buffered:41, Manual Commands: 1, Job Commands: 5000
Mesg: 2:31:57.428: Buffer used:41 Enforced free byte:0 lines stored:1
Mesg: 2:32:04.431: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:32:04.431: Connection status: Buffered:25, Manual Commands: 0, Job Commands: 5000
Mesg: 2:32:04.431: Buffer used:25 Enforced free byte:0 lines stored:1
Mesg: 2:32:11.435: Warning: Communication timeout - resetting communication buffer.
Mesg: 2:32:11.435: Connection status: Buffered:40, Manual Commands: 1, Job Commands: 5000
Mesg: 2:32:11.435: Buffer used:40 Enforced free byte:0 lines stored:1
Mesg: 2:32:11.436: Warning: Too many timeouts without response - disabling timeout message!
Mesg: 2:32:11.436: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!
Mesg: 2:32:11.436: This helps in case it is the serial driver that hangs.
Mesg: 2:33:05.575: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
Mesg: 2:33:06.283: Dtr: true Rts: true
Mesg: 2:33:06.287: Connection continued



Das (Connection continued) zeigt er mir dann an wenn ich das USB Kabel neu eingesteckt habe. dann durckt er ganz normal weiter.

Ich hoffe ihr könnt mir helfen. habe schon sehr viel gelesen aber alles hat nichts gebracht

Liebe Grüße

Comments

  • RepetierRepetier
    Timeouts sind meistens die folge von Kommunikationsproblemen. Zu viele hintereinader können zum stopp führen. Das ist normal ein Problem durch elektromagnetische störungen der Geräte. Je mehr Geräte am pi hängen desto empfindlicher werden die wie du ja selber schon gemerkt hast.

    Was hilft ist erst mal marlin mit advanced ok zu übersetzen und ping ping aus, 127 byte buffer mindestens oder besser 255 wenn du marlin so kompilierst. Am besten noch wait aktivieren. Die Kommunikationsprobleme verhindert es nicht aber wir erkennen die Fehlenden „ok“ meldungen on the fly so dass es nicht mehr zu den aussetzern kommt.
  • Stefan410Stefan410
    edited September 2021

    Repetier said:
    Timeouts sind meistens die folge von Kommunikationsproblemen. Zu viele hintereinader können zum stopp führen. Das ist normal ein Problem durch elektromagnetische störungen der Geräte. Je mehr Geräte am pi hängen desto empfindlicher werden die wie du ja selber schon gemerkt hast.

    Was hilft ist erst mal marlin mit advanced ok zu übersetzen und ping ping aus, 127 byte buffer mindestens oder besser 255 wenn du marlin so kompilierst. Am besten noch wait aktivieren. Die Kommunikationsprobleme verhindert es nicht aber wir erkennen die Fehlenden „ok“ meldungen on the fly so dass es nicht mehr zu den aussetzern kommt.



    Das würde ich gerne aktivieren nur weiß ich leider nicht wie.  Kenne mich leider nicht mit der Firmware so gut aus. habe mich halt stark rein gelesen um die baudrate runter zu setzten. 

    also 255byts auf jeden fall aktiviert lassen?

    ich habe mir jetzt einen Aktiven USB Hub besorgt um evtl die spannung im drucker zu stabilisieren. habe wenig hoffnung aber die stirbt ja bekanntlich zu letzt.

    bis jetzt laufen beide schon seit ne stunde.

    Der Kleine i3 lauft alleine super und hat absolut keine Probleme. Sobald der Chiron nur das kabel eingesteckt hat aber eingeschaltet ist macht der i3 schon probleme. allerdings ist der i3 nicht am netzt und kein kabel eingesteckt hat der chiron denoch das problem. deswegen habe ich im gefühl das es von ihm kommt.

    Wäre es möglich das dass mainboard ein weg hat?



  • RepetierRepetier
    Bei marlin gibt er eine config_adv.h da steht das mit dem advanced ok drin. Also einfach aktivieren, neu übersetzen und aufspielen. Ich geh hier allerdings davon aus das du vorher auch selbst kompiliert hast und nur nicht weißst wo die Option steht.

    Solche Probleme können durchaus von einem board/Drucker kommen. Letztens hatte einer Probleme sobald ein Drucker hinzu kam und Grund war ein "kurzschluss" zwischen USB masse und gehäuse wenn ich das richtig verstanden hab. Das hat alle angeschlossenen Geräte durcheinander gebracht. Auch sollten Pi und alle Drucker ein der gleichen Phase hängen, was aber in einem Raum normal eh der Fall ist. Sonst bekommst du so was wie früher die Brummschleife bei hifi Geräten.
  • Stefan410Stefan410
    edited September 2021
    ja richtig, habe mir aber eine vorgefertigte Config geladen da ich davon nicht viel ahnung habe und mich da in laufe der nächsten zeit mich mal mit beschaftigen wollte. habe eine selber kompiliert weil ich einen Anderen Thermistor verbaut habe und es anständig haben wollte. zweiter schritt war dann die baudrate runter zu setzen. 
    das wäre dann der dritte den ich wohl machen werde.

    ja ich verstehe. hängen aber alle an der selben steckdose. genau wie der Repetierhost und der jetzt dazugekommene aktiv hub. Aktuell läuft der druck auf beiden druckern schon 4 stunden. so lange war es seit dem problem noch nicht.

    Ich habe ja immer noch die hoffnung das es vllt die lösung ist. wir werden es abwarten müssen. ich werde es erst einmal so testen werde die kabel jetzt nochmal komplett anders legen so das keine anderen kabel mehr nähe des usb kabels ist. leider muss ich baulich bedingt 3m Kabel nutzen. ich weiß ist nicht so prickelnd aber ist leider nicht anders möglich aber lief ja auch bislang ohne probleme. Habe natürlich auch hochwertige mit 3 fache abschiermung genommen. also kein 5 euro amazon kabel

    wenn jetzt alles gut zu ende läuft belasse ich erst mal so. werde die byts auf 255 setzt statt die jetztzigen 127.
    sollte es probleme geben mache ich das mal mit der firmware.
    soll ich dann auch wieder auf 250000 baud setzten? weil damit lief es ja bisher auch. und die änderung hat das problem ja nicht beseitigt.

    PS. ich habe allerdings festgestellt seit dem der Aktiv Hub dran ist das der CPU Load Deutlich niedriger ist. vorher war immer ein wert von ca. 1.0, jetzt sind alle drei werde weit drunter und taumeln bei ca. 0.05 bis 0.40 rum. ich weiß nicht in wie weit das ein einfluss hat.
  • RepetierRepetier
    250000 oder 115200 baud macht nicht so viel unterschied da die usb latenz schwerer wiegt. Hab aber gemerkt das mal die eine mal die andere weniger Fehler liefern kann. Manchmal sind sie auch beide gleich gut. Wenn die Fehler also nicht ansteigen nimm ruhig 250000.

    CPU last hängt davon ab was gerade läuft. Mit "top" kannst du das in linux gut sehen wer hier cpu Zeit zieht. Sollte nicht von hub oder nicht abhängen, da es die gleiche Arbeit zu verrichten gibt.

    Der Hub kann helfen, da er die signale ja umleitet. Was der pi bekommt ist nicht was der hub vom Drucker sieht. Also eine Entkopplung der Störungen. Solange er es also richtig erhält und so weiter leitet kann es einen positiven Effekt haben. Plus signal wird verstärkt und Kabel können manchmal dadurch kürzer ausfallen.
  • Stefan410Stefan410
    Repetier said:
    250000 oder 115200 baud macht nicht so viel unterschied da die usb latenz schwerer wiegt. Hab aber gemerkt das mal die eine mal die andere weniger Fehler liefern kann. Manchmal sind sie auch beide gleich gut. Wenn die Fehler also nicht ansteigen nimm ruhig 250000.

    CPU last hängt davon ab was gerade läuft. Mit "top" kannst du das in linux gut sehen wer hier cpu Zeit zieht. Sollte nicht von hub oder nicht abhängen, da es die gleiche Arbeit zu verrichten gibt.

    Der Hub kann helfen, da er die signale ja umleitet. Was der pi bekommt ist nicht was der hub vom Drucker sieht. Also eine Entkopplung der Störungen. Solange er es also richtig erhält und so weiter leitet kann es einen positiven Effekt haben. Plus signal wird verstärkt und Kabel können manchmal dadurch kürzer ausfallen.

    Also Druck lief bis heute morgen tadellos durch. keinerlei aussetzer. ich werde es jetzt so ein wenig weiter testen. habe gerade auch wieder auf 250000 erhöht und lasse ihn gleich laufen sobald sich was tut melde ich mich. Und wenn sich nichts tut lasse ich es euch auch wissen.

    Vielen dank erst einmal fur den support und den tipp der firmware. wenn nochmal probleme auftauchen mache ich das mal. wenn ich jetzt alles mache weiß man ja nicht wo im enteffekt die lösung lag. :-D
    und das wollen wir doch alle wissen ;-P
  • Stefan410Stefan410
    So da bin ich wieder.
    Nach über eine woche Drucken den ersten aussetzer aber diesmal wirklich komplett ausgefallen das repetiert sogar gestoppt hat da die verbringung abgebrochen ist. Allerdings waren die aussetzter weg. das lief alles sauber. Habe auch den Advanced Ok Aktiviert aber  damit ist das autoleveling nicht mehr möglich. also wieder raus genommen. nach ein wenig suchen und weiter lesen zwecks firmware ist mir aufgefallen das ich in der Firmware TMC2208 eingetragen habe, habe aber nach einiges lesen herrausgefunden habe das diese nur für UARt geeignet sind und ich somit auf 2208 Standealone Stellen müsste. Das habe ich getan. Bisher läuft es.

    Allerdings zeigt er mir immer wieder das an wärend des drucks:

    Recv:12:32:58.138: //action:notification ETA 13 46 19 day 3
    Recv:12:33:07.927: //action:notification ETE 01 13 10
    Recv:12:33:17.701: //action:notification Layer 7/239
    Recv:12:33:28.369: //action:notification ETA 13 46 13 day 3
    Recv:12:33:38.105: //action:notification ETE 01 12 35
    Recv:12:33:47.860: //action:notification Layer 9/239
    Recv:12:33:58.032: //action:notification ETA 13 46 10 day 3
    Recv:12:34:07.674: //action:notification ETE 01 12 02
    Recv:12:34:17.891: //action:notification Layer 12/239
    Recv:12:34:27.731: //action:notification ETA 13 46 07 day 3
    Recv:12:34:37.956: //action:notification ETE 01 11 29
    Recv:12:34:47.789: //action:notification Layer 14/239
    Recv:12:34:57.843: //action:notification ETA 13 46 02 day 3
    Recv:12:35:07.852: //action:notification ETE 01 10 54
    Recv:12:35:17.834: //action:notification Layer 16/239
    Recv:12:35:27.903: //action:notification ETA 13 45 58 day 3
    Recv:12:35:37.621: //action:notification ETE 01 10 20
    Recv:12:35:47.850: //action:notification Layer 17/239
    Recv:12:35:57.965: //action:notification ETA 13 45 55 day 3
    Recv:12:36:07.603: //action:notification ETE 01 09 46
    Recv:12:36:17.737: //action:notification Layer 20/239
    Recv:12:36:28.106: //action:notification ETA 13 45 50 day 3
    Recv:12:36:37.578: //action:notification ETE 01 09 12
    Recv:12:36:47.858: //action:notification Layer 22/239
    Recv:12:36:56.142: Error:checksum mismatch, Last Line: 25534
    Recv:12:36:56.142: Resend: 25535
    Recv:12:36:56.219: Error:Line Number is not Last Line Number+1, Last Line: 25535
    Recv:12:36:56.219: Resend: 25536
    Recv:12:36:56.286: Error:Line Number is not Last Line Number+1, Last Line: 25536
    Recv:12:36:56.286: Resend: 25537
    Recv:12:36:56.374: Error:checksum mismatch, Last Line: 25541
    Recv:12:36:56.374: Resend: 25542
    Recv:12:36:56.534: Error:Line Number is not Last Line Number+1, Last Line: 25546
    Recv:12:36:56.535: Resend: 25547
    Recv:12:36:56.643: Error:Line Number is not Last Line Number+1, Last Line: 25548
    Recv:12:36:56.643: Resend: 25549
    Recv:12:36:56.726: Error:Line Number is not Last Line Number+1, Last Line: 25549
    Recv:12:36:56.726: Resend: 25550
    Recv:12:36:56.821: Error:checksum mismatch, Last Line: 25554
    Recv:12:36:56.821: Resend: 25555
    Recv:12:36:56.909: Error:checksum mismatch, Last Line: 25559
    Recv:12:36:56.910: Resend: 25560
    Recv:12:36:57.000: Error:checksum mismatch, Last Line: 25565
    Recv:12:36:57.001: Resend: 25566
    Recv:12:36:57.081: Error:Line Number is not Last Line Number+1, Last Line: 25566
    Recv:12:36:57.081: Resend: 25567
    Recv:12:36:57.164: Error:checksum mismatch, Last Line: 25571
    Recv:12:36:57.165: Resend: 25572
    Recv:12:36:57.966: //action:notification ETA 13 45 46 day 3
    Recv:12:37:07.548: //action:notification ETE 01 08 37
    Recv:12:37:17.651: //action:notification Layer 23/239
    Recv:12:37:27.551: //action:notification ETA 13 45 42 day 3
    Recv:12:37:37.726: //action:notification ETE 01 08 03
    Recv:12:37:47.801: //action:notification Layer 25/239
    Recv:12:37:57.832: //action:notification ETA 13 45 39 day 3
    Recv:12:38:07.516: //action:notification ETE 01 07 30
    Recv:12:38:17.612: //action:notification Layer 27/239
    Recv:12:38:27.839: //action:notification ETA 13 45 35 day 3
    Recv:12:38:38.113: //action:notification ETE 01 06 57
    Recv:12:38:47.674: //action:notification Layer 29/239
    Recv:12:38:58.196: //action:notification ETA 13 45 32 day 3
    Recv:12:39:07.651: //action:notification ETE 01 06 24
    Recv:12:39:17.527: //action:notification Layer 30/239
    Recv:12:39:27.659: //action:notification ETA 13 45 29 day 3
    Recv:12:39:37.659: //action:notification ETE 01 05 51

    Druck läuft aber bisher durch. es ist mit dem Error auch komplett zufall ich kann kein muster erkennen in welchen situationen das zu stande kommt.

    bin jetzt auch wieder auf 250000 Baud, 255 Byte, Ping Pong aus.
     
    Seit dem ich auf Standalone umgestellt habe ist das stottern bei den leerfahrten weg. also bei den bewegungen.
    Kann das auch mit dem aussetzern zu tun haben?
  • RepetierRepetier
    Die Fehlerliste hier denke ich ist ein einziger Kommunikationsfehler mit Problemen beim reparieren. Die nächste version ist da etwas besser. Wenn du firmware mit buffer 256 byte compiliert hast ist es einfach Zufall. Passiert immer wieder mal. Wenn es mit 127 byte puffer deutlich selter passiert dann ist der puffer doch nicht so groß.
     //action:notification
    ist nur die meldung des druckers auf M117.  Hab ich fürs update als ACK eingetragen, so dass es normal nicht mehr im log erscheinen sollte.
  • Stefan410Stefan410
    Also mus sich mir deswegen keine gedanken machen ?
    Stefan410 said:
    .........
     
    Seit dem ich auf Standalone umgestellt habe ist das stottern bei den leerfahrten weg. also bei den bewegungen.
    Kann das auch mit dem aussetzern zu tun haben?

    Wie sieht es damit aus? kann das zu den vergangenen aussetzter geführt haben?

  • RepetierRepetier
    So eine verlängerte Error liste kann du kurzen aussetzern führen. Darum haben wir viel Zeit in die optimierung gesteckt. In 1.1.2 die Lösung war aber noch nicht ganz so performant und problemlos in der korrektur wie wir wollten. Daher das update in 1.2.0. Wenn wir keine fehler mehr finden kommt es morgen raus, dann sehen wir mehr.
  • Stefan410Stefan410
    Alles klar. Ich bin gespannt. Und werde berichten
  • Stefan410Stefan410
    Hat wohl nicht lang gehalten das mit dem Standalone TMC Treiber war es nicht.

    Ich habe gerade mit der Version 1.1.2 Gedruckt. und nach ca. eine stunde brach der druck ab.
    Darauf hin habe ich gecheckt ob  das angekündigte Update 1.2 da ist. Die selbe datei wieder gestartet und jetzt läuft es seit 3 stunden. Allerdings habe ich keine Große hoffnung.

    Das Kam wieder zu stande bei der 1.1.2
    Recv:17:57:13.743: //action:notification ETE 07 10 14
    Recv:17:57:23.567: //action:notification Layer 55/488
    Recv:17:57:33.946: //action:notification ETA 01 07 28 day 5
    Recv:17:57:43.622: //action:notification ETE 07 09 44
    Recv:17:57:53.029: X:178.29 Y:208.74 Z:11.10 E:0.00 Count X:13927 Y:17292 Z:4368
    Recv:17:57:53.617: //action:notification Layer 55/488
    Recv:17:58:03.520: //action:notification ETA 01 07 28 day 5
    Recv:17:58:14.670: //action:notification ETE 07 09 16
    Recv:17:58:23.626: //action:notification Layer 56/488
    Recv:17:58:33.456: //action:notification ETA 01 07 30 day 5
    Recv:17:58:43.743: //action:notification ETE 07 08 46
    Recv:17:58:53.828: //action:notification Layer 56/488
    Recv:17:59:03.423: //action:notification ETA 01 07 30 day 5
    Recv:17:59:13.323: //action:notification ETE 07 08 17
    Mesg:17:59:27.087: Warning: Communication timeout - resetting communication buffer.
    Mesg:17:59:27.087: Connection status: Buffered:222, Manual Commands: 0, Job Commands: 5000
    Mesg:17:59:27.087: Buffer used:222 Enforced free byte:41 lines stored:6
    Mesg:17:59:31.094: Warning: Communication timeout - resetting communication buffer.
    Mesg:17:59:31.094: Connection status: Buffered:204, Manual Commands: 0, Job Commands: 5000
    Mesg:17:59:31.094: Buffer used:204 Enforced free byte:41 lines stored:5
    Mesg:17:59:36.358: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    Mesg:17:59:39.270: Dtr: true Rts: true
    Mesg:17:59:39.273: Connection continued
    Mesg:17:59:43.405: Warning: Communication timeout - resetting communication buffer.
    Mesg:17:59:43.405: Connection status: Buffered:227, Manual Commands: 1, Job Commands: 5000
    Mesg:17:59:43.405: Buffer used:227 Enforced free byte:41 lines stored:6
    Mesg:17:59:47.411: Warning: Communication timeout - resetting communication buffer.
    Mesg:17:59:47.411: Connection status: Buffered:220, Manual Commands: 0, Job Commands: 5000
    Mesg:17:59:47.411: Buffer used:220 Enforced free byte:41 lines stored:6
    Mesg:17:59:51.419: Warning: Communication timeout - resetting communication buffer.
    Mesg:17:59:51.419: Connection status: Buffered:203, Manual Commands: 0, Job Commands: 5000
    Mesg:17:59:51.419: Buffer used:203 Enforced free byte:41 lines stored:5
    Mesg:17:59:51.419: Warning: Too many timeouts without response - disabling timeout message!
    Mesg:17:59:51.419: Advice: If communication does not recover try adding usb reconnect on timeout in printer settings!


    Ich kapiere es nicht. ich hab einfach alles ausgetauscht und probiert und einfach kein ende in sicht. ich bin tatsächlich kurz davor aufzugeben.... seit wochen beschäftige ich mich mit dem thema.

    Wie sieht es mit den Max. Paralleler Befehle aus? das steht bei mir auf unbegrenzt. macht es sind ihn zu begrenzen? und wenn ja auf welchen wert?
  • Stefan410Stefan410
    Druck hat gerade abgebrochen und hat das in der Konsole hinterlassen

    Mesg:18:39:06.764: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    Mesg:18:39:08.613: Dtr: true Rts: true
    Mesg:18:39:08.614: Connection continued
    Recv:18:39:08.618: echo:Unknown command: "echo:Unknown comma"
    Recv:19:44:54.840: X:178.29 Y:208.74 Z:11.10 E:0.00 Count X:13927 Y:17292 Z:4368
    Recv:20:50:46.302: X:179.17 Y:206.42 Z:23.50 E:0.00 Count X:14172 Y:16939 Z:9328
    Recv:22:00:01.864: X:174.77 Y:185.46 Z:36.10 E:0.00 Count X:13980 Y:17623 Z:14368
    Mesg:22:40:25.772: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    Mesg:22:40:29.054: Dtr: true Rts: true
    Mesg:22:40:29.056: Connection continued
    Mesg:22:49:00.152: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...

  • RepetierRepetier
    1.2.0 ist raus mit schnellerer Fehlerkorrektur, aber 
    Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    bedeutet die Verbindung wurde komplett verloren. Kein hinweis das der Server das verursacht hat, also vermute ich board/firmware/linux haben das gemacht.

    Hattest du schon in /var/log/syslog nachgesehen ob es linux war? Da siehst du ja die usb verbindung die gestoppt wurde und auch ob linux es auslöste oder weil usb von sich aus verschwunden war.
  • Stefan410Stefan410
    Habe gerade geschaut nach dem syslog, allerdings ist es nicht mehr zu sehen von gestern. werde wohl dann ein weiteren fehler abwarten müssen. ich habe allerdings gestern das display abgeklemmt und ohne laufen lassen und auf einmal druckt er 8 stunden durch..... kann aber auch alles nur wieder zufall sein...

    Wie sieht es mit den Max. Paralleler Befehle aus? das steht bei mir auf unbegrenzt. macht es sind ihn zu begrenzen? und wenn ja auf welchen wert? Sollte ich diesen ggf mal begrenzen?

  • RepetierRepetier
    Max. parallele befehle macht nur ohne ping pong sinn. Ein wert von 2 oder 3 ist ok bei Marlin. Aber das problem hat damit nichts zu tun.

    syslog wird jeden tag neu gestartet. Die vom Vortag heist dann syslog.0 in /var/log. Noch ältere syslog.2.gz sind dann sogar noch komprimiert um platz zu sparen.
  • Stefan410Stefan410
    Pingpong habe ich aus. sollte ich dies lieber einschalten bei marlin?

    in den syslog komme ich leider jetzt gerade nicht rein.
  • RepetierRepetier
    Kannst es versuchen mit ping pong, ist normal immer noch schnell genug und das was alle anderen hosts nutzen. Oder als kompromiss max. 2 parallele Befehle weil es vorteile bei gelegentlichen Fehlern und geschwindigkeit hat aber keine exzessive nutzung erlaubt. Marlin 2 hat ja normal 4 Befehlspuffer plus Eingangspuffer, da bleibt dann normal genug Luft.
  • Stefan410Stefan410
    Alles klar dann werde ich das ausprobieren wenn er wieder probleme macht. allerdings mit abgeklemmten display keine probleme mehr. auch zeit überschreitungen und fehler in den Verbindungsdaten sind auf 0 gewesen. mit angehangenen display immer etwas über 100 fehler bei 5 stunden druck und das wirklich bei jedem druck! auch wenn er mal gut durchlief. meine vermutung ist das mein display vllt zu viel spannung gezogen hat. ich habe ihm jetzt gerade eine externe spannungsversorgung gegeben und werde testen wie es jetzt lauft.

    Was ich mir vielleicht auch vorstellen kann ich habe diesen lüfter hier dran:


    es kann sein das ggf die leistund von dem lüfter zu hoch ist. auch wenn es 5v sind zieht er mehr watt. Das daruch evtl schwankungen enstehen oder die gemeinsame stromaufnahme vom display und Lüfter zu hoch ist. Also mitlerweile bin ich fast von überzeugt das es ein spannungsproblem ist. weil das Problem ja schleichend kam und immer schlimmer wurde. ggf ein übergangswiderstand durch flugrost auf den kontakten da ich in der nähe vom wasser wohne und eine recht hohe luftfeuchtigkeit habe.

    ich hoffe das dass problem jetzt behoben ist und ich endlich ruhe habe.

Sign In or Register to comment.