1 byte print status 'stuck' #46
Comments
|
That is a strange occurrence, is it identifying the file properly in the state panel? with all the issues you've raised it would be a good idea to enable debug logging for octoprint.plugins.bambuprinter in OctoPrint's logging section of settings, and we can get more details as to what may be happening in the bambu and octoprint logs. |
|
I have debugging on but nothing super useful seems to come out. Lots of repeated lines (19k of 20k). Every 3 seconds or so: (I'm fairly certain that was a 1-byte-progress print.) I'm running more prints today so I will gather some logs and map them to behavior. Edit to add: |
|
Even after successfully uploading and selecting a new file, it still shows the laptop-wall-kit as selected: Starting a print from Octo does not work. (attached) During printing it is confused, but it has started counting bytes: |
|
thanks for partial logs, that did help identify a missing printing state and new version 0.1.7 released to fix that. I don't know if it will fix the issue, but it shouldn't hurt. is your printer cloud connected or running in local only mode? what model is your printer? |
|
Printer is local only, a P1S with AMS. The wifi is unifi, which has more of an impact than I'd like, but the RPI and the printer are on the same network. There is nothing else trying to talk to the printer (no webcam streamer, no slicers, just octo.) |
|
Thanks. I have heard of random communication issues on unifi wifi, but I personally have never experienced it with my X1C with AMS and UniFi AmpliFi HD setup. To give insight, if the file being sent from slicer isn't in the file list the plugin will attempt to update the file list to get the size and date of it cached into OctoPrint's memory. Once there it should start reporting the 1/x bytes when the state changes to RUNNING or PREPARE (with that update mentioned above). Then as print progress reports from printer are received the bytes should increase. |
this bit is the real concerning bit. that amount of state change in such a short period of time makes me thing the printer itself is sending weird information via MQTT. |
|
I powered it all up (via plugin to HA) and reconnected, then uploaded a file via octo and started it printing from the console. |
|
You did upload file to OctoPrint SD card side correct? Local files not seen as stored in SD card will not work. |
|
It was uploaded to the sd and successfully streamed. |
|
Not sure if this is the same issue or not, but there seem to be a bunch of state machine issues and this is one of them :) Today's print is showing progress, but stuck in "starting print from sd". Gcode percent and temperatures are all updating except time. (At 30% gcode, it still hasn't produced an ETA. Better than the wild times from earlier though.) This is a reprint of a previously-uploaded file, uploaded outside of octo. Log excerpts: |
The 1-byte change seems to have had weird side effects on some prints. This one is almost complete but still shows byte 1 (and the ETA jumps all over the place, from minutes to years.)
Forcing a disconnect/reconnect fixed it:
The text was updated successfully, but these errors were encountered: