ZVIRATKO: No, problém s reprodukováním právě je, že spíš ne... stalo se mi to teď poprvé; z toho upgradnuté je to pár dnů, ale má to 4 dlouhé tisky za sebou, samotnou tiskárnou se starším octopi projela hromada kg filamentu a nestalo se to nikdy. Takže uvidím, jestli se to ještě zopakuje a eventuelně jak rychle/často. Blbý je, že serial log jsem neměl zaplej, takže vyjma tohohle snippetu, co to vyblilo do normálního logu, tu komunikaci nemám.
Na čísla řádek jsem taky dost koukal, ale to je asi normální. Posílá je tam takhle octoprint, ale firmware tomu rozumí. Stejně jako je divnost ta hvězdička a číslo na konci každý řádky, což je zase nejspíš kontrolní součet. Ten průběh toho logu si jinak vysvětluju tak, že octoprint tam pere příkazy i s řádkama. Po 9 hodinách tisku se na ten sériák najednou připlete ta 4ka a skončí před tím číslem řádky, tiskárna vrátí chybu, že tohle jako nezná, ale octoprint jede dál. Načež tiskárna pak vrátí chybu, že ji chybí ten předchozí řádek (kterému nerozumněla kvůli přebývající 4). Octoprint to zaloguje, pošle znova ten rozbitej řádek a zdá se že ok. Když teda pominu to, že ten sériák by měl fungovat a neměly by se na něm objevovat nějaká cizí data, tak samotnej tenhle průběh mi přijde, že by ten tisk rozbít neměl. Prostě to akorát něco poslalo znova, možná se tím flushnul ten buffer, ale mělo to jet dál.
Takže úplná haluz je, že někdy od téhle chvíle to přestalo hýbat Y osou. A teď bohužel, jelikož ten serial log nemám, tak nevím, jestli tam octoprint posílal kokotiny nebo jestli firmware tiskárny dělal kokotiny. A pak je ještě otázka, jestli to rozbití komunikace jednu z těch stran rozbilo a vlivem nějakého dalšího bugu to udělalo tohle. Nebo je to něco horšího typu že se třeba v tom MCU tiskárny nějak posraly data v RAMce nebo něco na ten způsob - a pak jeden ze symptomů mohl být rozbitý buffer příkazů, ale zároveň kdo ví co dalšího v tom programu :-)