Octoprint-Chituboard
Octoprint-Chituboard copied to clipboard
rudetrooper
No Status, File I/O errors
I have a Elegoo Mars 2 Pro with the latest firmware using Chitubox 1.9.1. I added headers to the motherboard and am using a Raspberry Pi 2W and connected the Gnd, TX, RX wires per the diagram. I followed the software install in the CrazyRabbit Youtube video following the text file steps provided. I had no issues with the installation. Octoprint comes up and shows connected and State says Operational. I am able to upload files to SD. I plan to connect a Arducam Pi Camera with ribbon cable.
The README.md says that the plugin might not work if I've updated to the newest firmware. Does this mean that all features of Octoprint won't work (no status, no file upload/print, Webcam updates)
Loading and Printing files results in errors
WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on
even if I manually print a file using an inserted thumbdrive I never see the status get displayed.
File:
Uploaded:
Timelapse: -
Approx. Total Print Time: -
Print Time: -
Print Time Left: -
Printed: -
Layer: -
Will there ever be support for the latest Firmware?
I just installed my internal camera and it is working well. I am also able to manually move the Z up/down and home the printer without errror. But not status shows. Below is a log session with the Raspberry Pi Zero 2W on and connected to the serial port and the USB plug and a power up of the Elegoo Mars 2 Pro
Changing monitoring state from "Offline" to "Detecting serial connection" Performing autodetection with 1 port/baudrate candidates: /dev/ttyS0@115200 Trying port /dev/ttyS0, baudrate 115200 Connecting to port /dev/ttyS0, baudrate 115200 Handshake attempt #1 with timeout 2.0s Connected to: Serial<id=0x6a020c50, open=True>(port='/dev/ttyS0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Send: M4002 Recv: ok N:1 Changing monitoring state from "Detecting serial connection" to "Operational" Send: N0 M110 N0125 Recv: //# Recv: \x00#checkSum error,i:2 expect:0x7e,actual:0x7d!str:N0125 WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on Recv: Recv: ok Send: M115 Recv: ok CBD make it.Date:Jul 3 2021 Time:10:42:39 Repl: ok CBD make it.Date:Jul 3 2021 Time:10:42:39 -> ok FIRMWARE_NAME:CBD made it PROTOCOL_VERSION:V4.13 Date:Jul 3 2021 Time:10:42:39
Send: M21 Recv: // N:2 Recv: \x00it fail! WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on Recv: ok N:2 Send: M20 Recv: Begisk init fail!//Disk init fail! Recv: /nd file list Recv: \x00! WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on Recv: Eait Recv: \x00e list WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on Recv: wk L:0ok L:0 Recv: ok Send: M4000 Recv: ok N:4
When trying to print this is what gets logged.
Send: M23 _Pi_Zero_Lid_Vent_Large_IO.ctb Recv: //Disk init fail! Recv: //############sd_mo/k N:8674 Recv: \x00##sd_mounted Error! cann't open file ! WARNThe received line contains at least one null byte character at position 0, this hints at some data corruption going on
I'm getting the same error on mine, and same situation of having upgraded, to 1.9 firmware, then downgraded. Did you find a solution at all @jeffdavis503 ?
I have not found a solution. Keep waiting for a response to my post in issues.
On Mon, Apr 11, 2022, 2:00 AM John @.***> wrote:
I'm getting the same error on mine, and same situation of having upgraded, to 1.9 firmware, then downgraded. Did you find a solution at all @jeffdavis503 https://github.com/jeffdavis503 ?
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1094755603, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIUSHIVZTW4DNEHIE3EV6F3VEPS4BANCNFSM5QD5W5JQ . You are receiving this because you were mentioned.Message ID: @.***>
I finally got it working today! I changed to a third usb cable and just taped over the power supply line. @jeffdavis503 maybe try several cables and see if you can find one that truly supports all the data lines?
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
How did a USB cable help? Isn't the serial cable from the pins on the pi zero to the pins on the Mars 2 pro motherboard just 3 header wires?
On Mon, Apr 11, 2022, 1:36 PM John @.***> wrote:
I finally got it working today! I changed to a third usb cable and just taped over the power supply line. @jeffdavis503 https://github.com/jeffdavis503 maybe try several cables and see if you can find one that truly supports all the data lines?
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1095541876, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIUSHIQSC44NYM6MJOBYH53VESEN7ANCNFSM5QD5W5JQ . You are receiving this because you were mentioned.Message ID: @.***>
I can't downgrade the firmware because I use the latest chitubox software and have ctb files created with it along with another person.
On Mon, Apr 11, 2022, 5:27 PM Vikram Sarkhel @.***> wrote:
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. I'd recommend downgrading the firmware to the previous version of the firmware.
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1095730969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIUSHITBUNNNNDNH2QIM7ELVES7PDANCNFSM5QD5W5JQ . You are receiving this because you were mentioned.Message ID: @.***>
How did a USB cable help? Isn't the serial cable from the pins on the pi zero to the pins on the Mars 2 pro motherboard just 3 header wires? …
The 3 wires control the motor and start the prints etc but the usb cable is providing the pi as a storage device to print from. Disk init error for me at least, was because it couldn’t see the pi as a storage device.
I finished off my prints I’d made using 1.9 slicer then found a copy of 1.8.1 chitubox online, downgraded the firmware then started slicing new prints with that after
All working great so far, just waiting on a pi zero webcam to arrive and try to figure out a decent way to mount it to monitor if any failures.
Just need an x-Ray mode camera and a resin version of the spaghetti detective to quickly detect those occasionally first layer FEP failures and it’d be perfect 😆
Personally recommend using Lychee slicer since the UI is better but that's a personal preference. I have thought about making failure detection model for resin printing since I work in ML professionally but gathering all the required training data and labeling it would be time consuming and difficult.
My method has been to use UVTools modified Prusa-Slicer settings & run the SL1 files through UVTools. If FOSS is important to you, this method probably works the best.
@rudetrooper I understand your views on possible legal issues getting Octoprint to communicate with Chitu v1.9+ but all the new printers are coming stock with V1,9 or higher (my saturn S and Jupiter) and others. Seeing as Octoprint is only a monitoring software for SLA printers and has nothing to do with slicing I do not feel they would even look this direction. Please crack this so we can get back to remote monitoring these printers.
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
I'd love to understand this better. Unfortunately downgrading isn't an option for many of us (I have a Saturn S). What exactly is the encryption needed for? Currently I can move the head up and down, and I can upload .ctb files. I would really really really love to be able to see the progress of a print, and to be able to cancel a print in case something has gone wrong.
Is it possible to do this without worrying about the encryption, or is that required even for things like looking at the status?
If it is required then is it possible to NOT scrape the encryption key but allow users to do so themselves and put it in place?
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
I'd love to understand this better. Unfortunately downgrading isn't an option for many of us (I have a Saturn S). What exactly is the encryption needed for? Currently I can move the head up and down, and I can upload .ctb files. I would really really really love to be able to see the progress of a print, and to be able to cancel a print in case something has gone wrong.
Is it possible to do this without worrying about the encryption, or is that required even for things like looking at the status?
If it is required then is it possible to NOT scrape the encryption key but allow users to do so themselves and put it in place?
The encryption entails all communication with the printer. Moving the build plate, starting, stopping and pausing prints. Seeing what the printer is actually printing via gcode viewer. Pretty much all functionality of the printer and OctoPrint communications to the printer.
Can you point me in the right direction to try to create a PR or a branch for this?
On Sat, Jun 4, 2022, at 6:59 PM, wizard311 wrote:
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
I'd love to understand this better. Unfortunately downgrading isn't an option for many of us (I have a Saturn S). What exactly is the encryption needed for? Currently I can move the head up and down, and I can upload .ctb files. I would really really really love to be able to see the progress of a print, and to be able to cancel a print in case something has gone wrong.
Is it possible to do this without worrying about the encryption, or is that required even for things like looking at the status?
If it is required then is it possible to NOT scrape the encryption key but allow users to do so themselves and put it in place?
The encryption entails all communication with the printer. Moving the build plate, starting, stopping and pausing prints. Seeing what the printer is actually printing via gcode viewer. Pretty much all functionality of the printer and OctoPrint communications to the printer.
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1146715444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADSRCD3K546IL277LVHQH3VNP3V5ANCNFSM5QD5W5JQ. You are receiving this because you commented.Message ID: @.***>
Can you point me in the right direction to try to create a PR or a branch for this?
On Sat, Jun 4, 2022, at 6:59 PM, wizard311 wrote:
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
I'd love to understand this better. Unfortunately downgrading isn't an option for many of us (I have a Saturn S). What exactly is the encryption needed for? Currently I can move the head up and down, and I can upload .ctb files. I would really really really love to be able to see the progress of a print, and to be able to cancel a print in case something has gone wrong.
Is it possible to do this without worrying about the encryption, or is that required even for things like looking at the status?
If it is required then is it possible to NOT scrape the encryption key but allow users to do so themselves and put it in place?
The encryption entails all communication with the printer. Moving the build plate, starting, stopping and pausing prints. Seeing what the printer is actually printing via gcode viewer. Pretty much all functionality of the printer and OctoPrint communications to the printer.
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1146715444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADSRCD3K546IL277LVHQH3VNP3V5ANCNFSM5QD5W5JQ. You are receiving this because you commented.Message ID: @.***>
Sorry I can't help there it's above my pay grade but I wish I could.
Wow, that's frustrating. I hate that they did that. There don't seem to be many printers available that don't use it now either.
On Sat, Jun 4, 2022, at 6:59 PM, wizard311 wrote:
Sorry about the delayed response, I've been busy with work and life. The issue could be due to an issue with the cable. But I'm not planning on supporting the newest version of the Chitu firmware due to the closed source nature of their encryption in the CTBv4 format. To do properly it I would have to scrape the encryption key from Chitubox and include it in the plugin code potentially opening myself up to legal issues. I'd recommend downgrading the firmware to the previous version of the firmware.
I'd love to understand this better. Unfortunately downgrading isn't an option for many of us (I have a Saturn S). What exactly is the encryption needed for? Currently I can move the head up and down, and I can upload .ctb files. I would really really really love to be able to see the progress of a print, and to be able to cancel a print in case something has gone wrong.
Is it possible to do this without worrying about the encryption, or is that required even for things like looking at the status?
If it is required then is it possible to NOT scrape the encryption key but allow users to do so themselves and put it in place?
The encryption entails all communication with the printer. Moving the build plate, starting, stopping and pausing prints. Seeing what the printer is actually printing via gcode viewer. Pretty much all functionality of the printer and OctoPrint communications to the printer.
— Reply to this email directly, view it on GitHub https://github.com/rudetrooper/Octoprint-Chituboard/issues/19#issuecomment-1146715444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADSRCD3K546IL277LVHQH3VNP3V5ANCNFSM5QD5W5JQ. You are receiving this because you commented.Message ID: @.***>
The encryption key can be scraped from Chitubox. The plugin uses the file contents to get the file metadata and serve it in the dropdown menu. Also other parts of Octoprint need some of the embedded metadata. The gcode commands shouldn't be encrypted though. Anyone can fork the repo and create a pull request, I'm okay with accepting PRs as long as the code is decent. The code relating to the encryption and file analysis is in the file formats folder.