Ok, ich sehe was du meinst. Problem ist das es nicht Teil des Dateinamens ist den wir anzeigen mal abgesehen davon das wir die Metadatei nicht lesen, da wir die Infos selber aus der g-code analyse und rendering erzeugen.
Ja sofern ich mehere Platten habe, mache ich immer EINEN kompletten export für alle platten, die datei lade ich dann im repetierserver hoch und repetierserver legt dann die einzelnen gcodes ab. Bei dem ablegen könnte man ja theoretisch die platten namen aus der metadatei nutzen
aber wie gesagt, das ist absoluter bonus, erstmal wäre geil wenn man die drucke starten kann und ich wieder zu meinen normalen workflows zurück kann. das ich jedes mal des blöde bambustudio aufmachen muss oder diesen krampf von display nutzen muss ist echt nervig
Ja das verstehe ich, wäre das nicht zufällig der Name der g-code Datei. Ich merke mir das mal, vielleicht ergibt sich ja eine möglichkeit etwas anderes als den Pfad anzuzeigen und dennoch zu wissen welche Datei es ist. Zum Glück ist Pfad und Name schon nciht mehr das gleiche. Erst aber mal alles zum laufen bringen.
Dank deiner Mail sehe ich das der P1S einiges anders sendet. Auch scheint er den Druck in /cache abzulegen und nicht im Stammverzeichnis. Nehme an das passiert wenn man vom Bambu aus einen Druck startet stadt ihn auf sd karte zu kopieren, so können die die alte Datei löschen und die sd Karte wird nicht immer voller, wenn man mal von den Timelapse Videos absieht.
wenn man aus Bambusstudio einen gcode direkt druckt landet die Datei im cache, sendet man die datei an den drucker aus Bambusstudio dann landet sie im Stammverzeichnis
sofern ich noch andere sachen logen soll oder was bestimmtes am drucker testen dann einfach bescheid geben
ich kann auch mal loggen wärend ich aus Bambusstudio einen gcode von der sdkarte starte oder auch wenns am drucker selbst gestartet wird.
Ja genau den Link habe ich für die meisten Funktionen genutzt, danke.
Was die steuerung per MQTT angeht denke ich klappt es weitgehend. Das mit dem Cache hatte ich bis gestern nicht auf dem Schirm, weil ich nicht wusste wofür er ist.
Das dringendste Problem ist für mich aktuell warum SFTP die dateien nicht runter lädt bei dir obwohl er sie sieht. Leider will er noch nciht am neuen Rechner kompilieren, auch wenn es nur noch an einer Bibliothek hakt. Dann gibt es eine Version mit mehr debug meldungen um die Ursache zu finden und evtl. schon lesen des Startbefehls um die Datei korrekt zu ermitteln.
Comments
aber wie gesagt, das ist absoluter bonus, erstmal wäre geil wenn man die drucke starten kann und ich wieder zu meinen normalen workflows zurück kann. das ich jedes mal des blöde bambustudio aufmachen muss oder diesen krampf von display nutzen muss ist echt nervig
Dank deiner Mail sehe ich das der P1S einiges anders sendet. Auch scheint er den Druck in /cache abzulegen und nicht im Stammverzeichnis. Nehme an das passiert wenn man vom Bambu aus einen Druck startet stadt ihn auf sd karte zu kopieren, so können die die alte Datei löschen und die sd Karte wird nicht immer voller, wenn man mal von den Timelapse Videos absieht.
sofern ich noch andere sachen logen soll oder was bestimmtes am drucker testen dann einfach bescheid geben
ich kann auch mal loggen wärend ich aus Bambusstudio einen gcode von der sdkarte starte oder auch wenns am drucker selbst gestartet wird.
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Was die steuerung per MQTT angeht denke ich klappt es weitgehend. Das mit dem Cache hatte ich bis gestern nicht auf dem Schirm, weil ich nicht wusste wofür er ist.
Das dringendste Problem ist für mich aktuell warum SFTP die dateien nicht runter lädt bei dir obwohl er sie sieht. Leider will er noch nciht am neuen Rechner kompilieren, auch wenn es nur noch an einer Bibliothek hakt. Dann gibt es eine Version mit mehr debug meldungen um die Ursache zu finden und evtl. schon lesen des Startbefehls um die Datei korrekt zu ermitteln.
ich mein wer repetier nutzt wird wohl kaum noch Dateien auf dem drucker speichern XD