Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Status, File I/O errors #19

Open
jeffdavis503 opened this issue Mar 7, 2022 · 18 comments
Open

No Status, File I/O errors #19

jeffdavis503 opened this issue Mar 7, 2022 · 18 comments

Comments

@jeffdavis503
Copy link

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?

@jeffdavis503
Copy link
Author

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:N0
125
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

@jeffdavis503
Copy link
Author

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

@zeroecho
Copy link

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 ?

@jeffdavis503
Copy link
Author

jeffdavis503 commented Apr 11, 2022 via email

@zeroecho
Copy link

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?

@rudetrooper
Copy link
Owner

rudetrooper commented Apr 12, 2022

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.

@jeffdavis503
Copy link
Author

jeffdavis503 commented Apr 12, 2022 via email

@jeffdavis503
Copy link
Author

jeffdavis503 commented Apr 12, 2022 via email

@zeroecho
Copy link

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 😆

@rudetrooper
Copy link
Owner

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.

@mcdviii
Copy link

mcdviii commented Apr 17, 2022

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.

@wizard311
Copy link

@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.

@minego
Copy link

minego commented Jun 5, 2022

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?

@wizard311
Copy link

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.

@minego
Copy link

minego commented Jun 5, 2022 via email

@wizard311
Copy link

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 #19 (comment), 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.

@minego
Copy link

minego commented Oct 11, 2022 via email

@rudetrooper
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants