OpenPnP with Klipper anyone?

[Bernd Walter]

Did anyone test klipper with OpenPnP?

Background:
I'm currently using 2 MKS-Gen boards running repetier firmware, plus a
set of additional (mostly self build) for various IO functions.
I concentrate on the MKS Gen because that's the only one, which Klipper
could make sense, since those run the stepper motors.
Right now I'm running XY and both Z CAMs on one board and 4x rotation
on the other.
I can't rotate while doing XY moves because of the required M400 commands.
The Boards run AVR (ATMEGA2560) with 5V and limited steps/s.
Y is running a NEMA23 with a big external driver, which requires 5V signals.
My Y axis speed is limited by the AVR.

Klipper is doing the maths on e.g. a Raspberry Pi and offloads only the
timing related things to the micronctroller board and reaches higher
steps/s on an AVR than a traditional firmware on an ARM.
It can also use multiple boards in sync, so I would end up with a single
G-code controller for both boards.
It could fix both points for me without changing hardware, well I might
use a separate Raspberry Pi for that though.
It also has the concept of auxillary stepper drivers, but unlike Repetier
it does propper ramping for those.

--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

[Marek T.]

So you send G0 XYZ and M400 to the one controller and G0 C + M400 to another subdriver.

Understand tha when you send G0 XYZ + M400 an Openpnp awaits for M400 confirmed with <ok> to can send G0 M400 to subdriver only?

I have XYC on one controller but don't like maths doing synchronized motion for XYC. I would prefer have XY synchronized and C have independently finished but started together with XY.

So I'm thinking to add another small controller for the C only. It seems that M400 can be troubling for my idea too...

[Bernd Walter]

On Thu, May 30, 2019 at 04:28:26AM -0700, Marek T. wrote:
> So you send G0 XYZ and M400 to the one controller and G0 C + M400 to
> another subdriver.

Exactly

> Understand tha when you send G0 XYZ + M400 an Openpnp awaits for M400
> confirmed with <ok> to can send G0 M400 to subdriver only?

Yes.
It would work if the M400 hadn't to be integrated into the motion command.
So start both motions and then wait for both to finish.

> I have XYC on one controller but don't like maths doing synchronized motion
> for XYC. I would prefer have XY synchronized and C have independently
> finished but started together with XY.
> So I'm thinking to add another small controller for the C only. It seems
> that M400 can be troubling for my idea too...

I couldn't run them on one controller as I have 4 C axis and my boards only
handle 5 stepper drivers.
That said, it is outdated as I'm using an external driver for Y it doesn't
depend on a stepstick slot anymore and could be configured with GPIO pins.

Klippers auxillary axis seem to run unsyncronized.
I likely will use them for C and Z when I convert, but that has to be tested
first.
And it also supports small controllers running on SAMD21 or ATMEGA168.
However, so far I have zero experience with that software, but I'm tempted
to give it a first test on a 3D printer to gain some experience.
Also some of my printers struggle with speed as well, e.g. on gyroid infill
and since all my printers have an OctoPi already.

My test to give it a quick on a Geetech delta, which I considered a buying
fail and never made it into a funkctional state, didn't work on first test :-(
pi@octopi:~/klipper $ make flash FLASH_DEVICE=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK005JN4-if00-port0
Flashing out/klipper.elf.hex to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK005JN4-if00-port0 via avrdude

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (21576 bytes):

Writing | ## | 4% 0.26savrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
^Csrc/avr/Makefile:32: recipe for target 'flash' failed
make: *** [flash] Interrupt

Pretty sure that is something with the GT2560 board the printer came with.
Have to give it a power cycle to do another test.
Maybe I have to flash a propper bootloader first.

> W dniu czwartek, 30 maja 2019 12:50:32 UTC+2 u??ytkownik Bernd Walter
> napisa??:

[Marek T.]

Good luck :-), and keep the thread updated when got some success pls.

[Matt Baker]

I run it on my 3d printers, works great. Should be a big improvement for a delta on a mega2560.

I follow along on the github to some degree, and I don't think anyone has tried it with a pnp yet.

Looks like you just have a bootloader issue of some sort.

Matt