Closed E4ST2W3ST closed 5 months ago
Thank you for the hardwork @E4ST2W3ST, look forward to using this on my n3p
Thanks. As high-level feedback, I think it would be useful to add support for forwarding an mcu serial port back to the host software. I do have a few comments on the implementation here:
-Kevin
I can say (at least for me, as a user) that I'm definitely interested in this, as if I understand properly, I could use this to write a set of macros that could communicate with a stock MMU connected to the printer board serial (how marlin/prusa handles it), and listen for things like the runout trigger from it, which is really the only thing stopping me from switching from marlin at the moment.
This would be much better (IMO) than the current MMU support under klipper, requiring me to change the board of the MMU to something that can also run klipper, and controlling both directly via MCU.
This would be one use case for the SERIAL_BRIDGE commands, to send filament change/retraction commands, listen for confirmation and success/fail responses.
Hi. This PR will also be very useful for creality printers, they also have a Nextion (TJC) HMI display. I am looking forward to this code being added.
@E4ST2W3ST Any further details on this PR? Seems that this is starting to gain traction with folks and I know I'm patiently waiting to get this added to my printer. Thanks!
Also interested in this too, but since I wanted to use it now and keep things inline with upstream, I used git apply
with a .patch of the PR so I can use the functionality and still get the latest updates (unless there is a merge conflict, which there likely wouldn’t be as the commit is mostly additions).
If this is improved upon more and gets merged into Klipper, I’d do a git reset --hard
to revert all the manual additions.
Kevin make it, please)
Before you now continue spamming this thread with "me too", you did realize that:
I have appreciated people sharing their use case as I have a similar project in the works. I'll probably be repacking, cleaning up, and expanding compatibility for some choice features in this PR.
@E4ST2W3ST I rewrite the neptune3pro's screen firmware to support klipper. The screen is connected to the klipper host, and a service is running to interact with moonraker and the screen. https://github.com/t1ngyu/neptune-screen
If there is a serial bridge between the MCU and the klipper, it is more interesting.
It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
Also interested in this too, but since I wanted to use it now and keep things inline with upstream, I used
git apply
with a .patch of the PR so I can use the functionality and still get the latest updates (unless there is a merge conflict, which there likely wouldn’t be as the commit is mostly additions).If this is improved upon more and gets merged into Klipper, I’d do a
git reset --hard
to revert all the manual additions.
do you know why *patch file not found?
Add functionality that allows communicating and configuring uart ports on the target MCU. Currently supports the STM32 architecture.
Inspired from ete100's pull request for similar functionality.
The feature allows for generic communication with uart peripherals, along with an implementation supporting the Neptune 3Pro/3Plus/3Max screens .
To use, run a make menuconfig for STM32 ,enabling low-level configuration options. A list of available bridge configurations will be presented that don't interfere with the main UART: