search

rudetrooper / Octoprint-Chituboard

Added basic support chituboard based printers(Elegoo Mars, Anycubic Photon, Phrozen, etc.) to octoprint.
GNU Affero General Public License v3.0
81 stars 18 forks source link

not sure what I'm doing wrong #17

Closed jd1701d closed 2 years ago

jd1701d commented 2 years ago

when I try to print something on my ld 002r most of the time it disconnects and gives me the error starting a print. Screen Shot 2022-02-01 at 8 58 48 PM

it's a real crapshoot to get something to print most of the time and then there's 2 connects in the port options which are named the same thing. I don't really know where to start figuring out what's going on let alone fix it, I'm vary new at programing.

jd1701d commented 2 years ago
152087307-13e87105-2a1c-4aa5-81dc-703f9efc14d4
rudetrooper commented 2 years ago

The 2 /dev/ttys0 options in the serial port menu are normal, selecting either of them will work. Are you starting the prints by selecting the files within the resin folder in the file menu? That normally pops up when you try to start a a print from SD.

jd1701d commented 2 years ago

I use the resin folder. half of the time it seems to be a longer wait before the printer starts compared to starting the print from the screen, then it quick like I'm using a thumb drive. I keep seeing a resend ratio but it always stays at 0 / ## 0% Right now it seems to be working fine but usually I have to tell it to print a few times over a couple minutes before it starts. Like usual it doesn't happen when you want it too. I've included the logs but the serial connection one wasn't turned on until today. I the logs are helpful in some way for you.

serial.log plugin_pluginmanager_console.log octoprint.log

Screen Shot 2022-02-05 at 8 38 40 PM
rudetrooper commented 2 years ago

Oh, the plugin is actually operating properly. Don't click the print button multiple times, theirs just some lag before the start print gcode is sent due to the file analysis step. Whats happening is when you start a print the Chituboard plugin does some analysis on the file using the file_formats code linked below. This is required to show which layer is currently being printed in the state frame. That takes some time especially on the Raspberry Pi Zero W which is somewhat underpowered with only has a single arm core. https://github.com/rudetrooper/Octoprint-Chituboard/tree/main/octoprint_chituboard/file_formats

jd1701d commented 2 years ago

I didn't know that. Thought I had messed up the setup or something. Guess I was just getting impatient when I couldn't think anything was happening. Thanks for explaining it for me, I love the program.

jd1701d commented 2 years ago

well it's at it again and the log caught it this time. It's even rejecting old print files I did a couple days ago. serial.log

rudetrooper commented 2 years ago

I see the errors with simpsons001.ctb and the HardFault_Handler issue. Its something to do with the printer firmware or some formatting issue. I need to do some research to figure this out. Also I recommend disabling the checksum in the printer settings and the "Apply parity double open workaround".

jd1701d commented 2 years ago

here's a video I shot that showing what's going on https://youtu.be/8BmNEunrGsI

the printer says that it's an unknown file but if I go in and manually select it from the printer's screen it'll print with no issues. The file that I tried to print was a file that I had printed before I had the pi hooked up and after I had everything satup, both times with success but suddenly nothing wants to print.

jd1701d commented 2 years ago

I think my firmware in V4.3.1_LCDK/1440x2560/F2.13 upgrading to V4.3.16_LCDKE/1440X2560/F2.13 seems to have worked. I've never touched the programing or firmware since the pi was installed, I guess gremlins got in there😜 attached is the final logs incase you want to see them. thank you for all your help.

octoprint.log plugin_pluginmanager_console.log serial-3.log