search

Arksine / moonraker

Web API Server for Klipper
https://moonraker.readthedocs.io
GNU General Public License v3.0
1.09k stars 420 forks source link

PanelDue stuck on Standby using CH340G USB to TTL converter #900

Closed GoTVm closed 3 months ago

GoTVm commented 3 months ago

What happened

I'm trying to interface a PanelDue 5i to a RPI4 using a CH340G based USB to TTL converter, but it is stuck on Standby, none of the buttons work, no macros show up and no files on the sdcard are found.

I managed to get the Panel to work using an Arduino UNO as a makeshift USB to TTL converter (macros would show up and I could control the printer), but I'd like to use a proper converter rather than a huge Arduino.

Client

Fluidd

Browser

Chrome

How to reproduce

Configure PanelDue as per the docs Connect it to a USB port on the host via a CH340G USB to TTL converter.

Additional information

moonraker.log

Arksine commented 3 months ago

The underlying hardware is abstracted from the PanelDue implementation. If an Arduino with USB Serial works and the CH340G does not then it suggests a driver issue or a hardware issue.

GoTVm commented 3 months ago

That tracks, I'll see if I can get my hands on another converter, maybe this one is defective. I might get a FTDI chip converter, they seem to be better supported by raspberry. I can't even recompile the ch340g driver, it keeps giving errors with the Linux kernel headers.

Any idea why it stays stuck on standby just with the converter though?

From: Eric Callahan @.> Sent: Tuesday, August 27, 2024 11:28:45 AM To: Arksine/moonraker @.> Cc: GoTVm @.>; Author @.> Subject: Re: [Arksine/moonraker] PanelDue stuck on Standby using CH340G USB to TTL converter (Issue #900)

The underlying hardware is abstracted from the PanelDue implementation. If an Arduino with USB Serial works and the CH340G does not then it suggests a driver issue or a hardware issue.

— Reply to this email directly, view it on GitHubhttps://github.com/Arksine/moonraker/issues/900#issuecomment-2312016107, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APY5EHKCRIHTDZFWINRKQW3ZTRBE3AVCNFSM6AAAAABNE3IFFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGAYTMMJQG4. You are receiving this because you authored the thread.Message ID: @.***>

Arksine commented 3 months ago

Its stuck on standby because Moonraker cannot establish communication with the PanelDue.

GoTVm commented 3 months ago

But it goes from connecting to standby, that's what leads me to think it can communicate to a certain extent but cannot convey all the info it should.

Arksine commented 3 months ago

Its possible that its an unstable connection. It receives the initial packet then the rest is garbled or dropped. I suspect the only way to be sure would be to use an oscilloscope to view the signal.

GoTVm commented 3 months ago

I don't have access to an oscilloscope so I'll have to try a different converter first. I'll report back as soon as I discover something.

GoTVm commented 3 months ago

Confirmed not a Moonraker issue. For some reason, my RPi4 does not recognize ANY CH340 based devices, even after recompiling and reinstalling the CH340x driver. Fixed it with a FTDI USB to TTL adapter.

GoTVm commented 3 months ago

Another question: since enabling the PanelDue, I've been getting many "Timer too close" errors, the WebUI gets stuck many times and all my prints have failed and gotten stuck. Is 1GB of RAM not enough to handle both Moonraker, Fluidd and the PanelDue?

Arksine commented 3 months ago

The PanelDue uses very little resources on the host, a 1GB Pi 4 is more than sufficient. The way you describe it, it sounds like the Kernel scheduler is starving host processes (Moonraker and Klipper) of CPU time. If it only occurs with the addition of the PanelDue, it likely continues to be a USB driver issue. It could be an issue with the host controller, or perhaps the FTDI driver is causing a problem.

I would recommend switching back to the arduino to see if you continue experiencing problems. Alternatively you could enable the Pi 4's UART and wire directly.

FWIW, I have found that the 32-bit version of Raspberry Pi OS is more stable than the 64-bit version. USB issues are fairly common on Pi's however they tend to be caused by webcams more than TTL adapters.

GoTVm commented 3 months ago

I can't wire the screen to the pi's uart due to space constraints, so the only choice I have is a USB converter. I already am on 32bit Raspberry pi os, I had to disable 64 bit to update the ch340 driver.

Do you think updating the driver (if it is even possible) would be worthwhile?

EDIT: just I also have a USB camera connected, could they be causing the issue together? Also, should I try rpi-update? I don't know what kernel is on my pi right now, but maybe it needs updating so it can pull more recent drivers? Also, if I wire the screen to the pi's uart pins, I guess I lose access to my printer via USB, right?

Arksine commented 3 months ago

Do you think updating the driver (if it is even possible) would be worthwhile?

The driver is shipped with the kernel, so if there is an update it will be applied when the kernel is updated. The problem could very well be an issue with the USB host controller, not the FTDI driver.

I also have a USB camera connected, could they be causing the issue together?

Yes, that could potentially cause the issue.

Also, should I try rpi-update?

I tend to stick with apt. IIRC rpi-update offers bleeding edge updates. This could fix some issues and introduce others, so I can't really provide a recommendation one way or the other.

GoTVm commented 3 months ago

Right now I'll try a couple of things: 1) run a print with the screen connected via the Arduino. As much as it is janky, if it works it works and I'll just hide the Arduino in the enclosure. 2) I'll try unplugging the camera and printing with the FTDI driver, but if that's the solution I guess I won't be able to use the screen (camera is mandatory) 3) Reducing the baudrate (probably useless) 4) trying to update the system and FTDI driver.

What can I do with the USB host driver?

Is it safe to apt update and apt upgrade directly, or should I stick with the OS packages update in the WebUI? (If they aren't exactly the same thing already)

Also another issue I noticed, the screen kept showing Gcode response errors and trying to send random characters together with the gcode it normally sends (I think to get updates about the printer?). Is that normal or is there something wrong with my setup? The screen is connected with about 10cm jumper wires to the adapter and then 1.5m USB cable to the pi.

Arksine commented 3 months ago

What can I do with the USB host driver?

You could try running everything through a USB hub. When it comes to drivers we can only hope that the Kernel devs can identify issues and fix them. I believe they have been present for years now though.

Is it safe to apt update and apt upgrade directly, or should I stick with the OS packages update in the WebUI? (If they aren't exactly the same thing already)

They do the same thing. Its safe to perform upgrades using apt via the shell.

Also another issue I noticed, the screen kept showing Gcode response errors and trying to send random characters together with the gcode it normally sends (I think to get updates about the printer?).

I haven't experienced this issue on my device. Moonraker only supports PD Firmware Version 1.24, if you are running another version its possible the device could send commands that arent supported.

GoTVm commented 3 months ago

1) Just a generic USB hub, no frills, like the ones that split one single USB A connector to 8 ports? Or do I need anything specific? Is it to bypass the onboard USB host? I have one like this that I could throw between them. 2) good to know, then my system is updated. 3) fw version is 1.24. The error was something like "Gcode response error: unknown Gcode "NNNNNNNNN G408...". I don't have the error on me right now but I can check it when I'm home. I "solved" it by hiding info popups on the screen, but I'm sure it's still sending junk. Probably some issues with interference, though it's weird since it's very short cables (same as the ones coming out of the Arduino which never showed this issue).

Arksine commented 3 months ago

Any hub is worth a try. Use a USB 2.0 port on the Pi 4, USB 3 is known to have issues.

The error was something like "Gcode response error: unknown Gcode "NNNNNNNNN G408..."

Indeed, that looks like noise on the line.

GoTVm commented 3 months ago

Alright, I'll try the hub on the 2.0 port as well. About the noise, best course of action? I don't have any shielded wire, but I do have a couple of ferrite cores. Grounds are common between the screen and the pi (the communication wouldn't work otherwise, I'm pretty sure).

GoTVm commented 3 months ago

Seems to be fixed, ran two prints without issue. Connecting the camera and the screen to the RPi4 through a USB hub immediately fixed the issue. Load during printing is normal (below 10% Moonraker load, 0.5 cores used and 50% memory usage) and I no longer get stutters or any issue with the WebUI. Also, the random Gcode response errors disappeared.

I then tried to remove the hub and was immediately hit with random Gcode, Moonraker load spiked to 90% and I immediately recognized the issue. I will list the other troubleshooting steps I didn't get the chance to try for future reference and maybe so someone else could need them: