New experimental firmware: all kinematics in host

This is quite interesting project. I've been reading the documentation and have a couple of questions: is GPIO state solely controlled by host? For example, when heater is on and controller disconnects from raspberrypi - will the heater keep on heating?

Similarly, if limit is triggered - is it up to the controller to stop processing stepper commands or it's up to the host?

Quote
newbob
This is quite interesting project. I've been reading the documentation and have a couple of questions: is GPIO state solely controlled by host? For example, when heater is on and controller disconnects from raspberrypi - will the heater keep on heating?

Similarly, if limit is triggered - is it up to the controller to stop processing stepper commands or it's up to the host?

Thanks. In both cases, the micro-controller software will take action without the host intervention. There's some details on how the above is implemented in the MCU_Commands document. In particular, see the description of the config_digital_out and end_stop_home commands.

-Kevin

Hey Kevin, first of all huge thanks for your amazing work ! Ill converse my small simple printer probably later today and will come back if i find anything noteworthy with that. Do you plan on implementing dual dual setups ? ( As in dual steppers / Dual endstops on multiple axes ) I got my big printer running with repetier but obviously it needs toolpath prediction aswell, just like any other cnc machine Thanks again, im really exited for klipper !

Edited 1 time(s). Last edit at 11/03/2017 06:29AM by lenne0815.

Quote
lenne0815
Hey Kevin, first of all huge thanks for your amazing work ! Ill converse my small simple printer probably later today and will come back if i find anything noteworthy with that. Do you plan on implementing dual dual setups ? ( As in dual steppers / Dual endstops on multiple axes ) I got my big printer running with repetier but obviously it needs toolpath prediction aswell, just like any other cnc machine Thanks again, im really exited for klipper !

Thanks. If by "dual steppers" you mean two separate stepper motor drivers with two separate sets of step/direction pins, then it is not currently supported in Klipper. (However, if the step/direction pins are shared, then it should just work.)

If you're looking to add support for that, it can be implemented with just changes to the host python code.

-Kevin

Yes i mean that but actually one step further: not only individually driving motors ( 99% of the time that would be just mirroring pulse outputs to other pins ) but and here comes the catch:

being able to do a homing sequence first together, afterwards individually to be auto squaring for that specific axis.

Repetier supports that feature since a couple of months for multiple dual axes and Marlin since yesterday i think when the mnpc guys got their code merged into marlin 2 ( was possible before thanks to a fork they made for Marlin 1.1.5 ) but it would be great if you could look at it and decide if its worth your time, there are lots and lots of machines which run multiple individual steppers on some or even all axes and rely on the auto squaring function aswell.

Unfortunately im as proficient in py as im at flying a spaceship, so my big printer is at your mercy

Edited 1 time(s). Last edit at 11/03/2017 01:17PM by lenne0815.

Ok, my small diy I3 is running Klipper.

It far exceeded my expectations, i know what a reasonable lookahead looks from Art Lebedevs implementation in Mach3 and i really didnt expect Klipper to match that on a 3D printer. It did. Needless to say right now im redialing in my settings at around 150mms whereas on Marlin prints would ring unbearably at just 75mms.

I recon Klipper to be the holy grail of 8 bit controller softwares.

Observations: While fiddling around with settings the bed got stuck on heating at one point, as soon as the ramps received power it switched the heatbed on, no warm or cold reboot could fix it, disconnecting pi not either. Reflashed and it works again.

Edited 3 time(s). Last edit at 11/03/2017 07:01PM by lenne0815.

Quote
lenne0815
Ok, my small diy I3 is running Klipper.

It far exceeded my expectations, i know what a reasonable lookahead looks from Art Lebedevs implementation in Mach3 and i really didnt expect Klipper to match that on a 3D printer. It did. Needless to say right now im redialing in my settings at around 150mms whereas on Marlin prints would ring unbearably at just 75mms.

Great!

Quote

I recon Klipper to be the holy grail of 8 bit controller softwares.

It works great with 32bit micro-controllers as well.

Quote

Observations: While fiddling around with settings the bed got stuck on heating at one point, as soon as the ramps received power it switched the heatbed on, no warm or cold reboot could fix it, disconnecting pi not either. Reflashed and it works again.

If you experience a failure or unusual behavior, issue an M112 command in the octoprint terminal, ssh into the RPi, and extract the /tmp/klippy.log file for analysis as described in the contact document. Having the log is crucial to understanding the issue.

-Kevin

Ill make sure to do that the next time i experience any issues ! ( when i realised what was going on it was already at 100c and i was in a bit of a hurry to pull the plug )

Im still amazed i can do this now [www.youtube.com] there are two remarkable things about this video, first all i did to "tweak" the cube was setting pressure advance to 0.5 and second these speeds would have outright stalled on marlin ( i suppose on repetier aswell ) with the first jerk as not obeying acceleration at higher speeds is a nono with tmc2100 at just 12v / stealth chop.

I personally think its good that 32bit boards are supported, but then again you made them pretty much obsolete

Im still pondering how i could get my big printer to work, i could pull out 4 drivers from the rumba and bridge ena step dir on two sets and remove the additional endstops for auto squaring and could make hard stops at the opposing side to run them against by hand before powering on... Its worth it !

One more question, when editing the cfg are the new values respected without doing anything else ? ( Right now im sending a restart to the 2560 but i guess thats actually not doing anything )

And another one, is there an auto pid tune already ? If not what would you propose is the easiest option ? Just reflashing marlin, pid tune and use the values from there ?

Edited 3 time(s). Last edit at 11/04/2017 08:51AM by lenne0815.

Quote
lenne0815
Im still pondering how i could get my big printer to work, i could pull out 4 drivers from the rumba and bridge ena step dir on two sets and remove the additional endstops for auto squaring and could make hard stops at the opposing side to run them against by hand before powering on... Its worth it !

FYI, a few other people have recently expressed interest in dual stepper support (see issue #39).

Quote

One more question, when editing the cfg are the new values respected without doing anything else ? ( Right now im sending a restart to the 2560 but i guess thats actually not doing anything )

After modifying the config, one must issue a RESTART command in the Octoprint terminal window for the config to take effect. Use the STATUS command to verify the restart was successful - as described in the Installation document.

I'm not sure what you mean by "sending a restart to the 2560".

Quote

And another one, is there an auto pid tune already ? If not what would you propose is the easiest option ? Just reflashing marlin, pid tune and use the values from there ?

The M303 command is supported. However, it's currently a little awkward to use - after the test completes, one must find the recommended values in the /tmp/klippy.log file, update printer.cfg with the new values, and RESTART for them to take effect.

-Kevin

Ok, then i did it right, i sent restart to the arduino via terminal every change, just wasnt sure if it does affect the print the as the kinematic calculations are done the pi so thats actually where the parameters are read ?
Thanks for implementing M303, i dont think its a big issue that its stored in the log, i recoup that time with the first 10% of the first print

Ive stumbled across the Github issue, watching it eagle eyed, maybe someone gets it done before i do the hardware mods

Is there are list somwhere for supported M Codes ? many i tried already which did work but a list would be great !

Edited 2 time(s). Last edit at 11/04/2017 11:57AM by lenne0815.

Quote
lenne0815
Ok, then i did it right, i sent restart to the arduino via terminal every change, just wasnt sure if it does affect the print the as the kinematic calculations are done the pi so thats actually where the parameters are read ?

Octoprint does not directly communicate with the micro-controller - instead it sends commands to the Klipper host software (aka Klippy) via the /tmp/printer communication port. Only the host software interacts directly with the micro-controller. A RESTART command instructs the host software to reload the config and do an internal reset - if the config file has a new pin configuration then in this process the host software will also instruct the micro-controller to reset itself and apply the updated pin config.

Quote

Thanks for implementing M303, i dont think its a big issue that its stored in the log, i recoup that time with the first 10% of the first print

Ive stumbled across the Github issue, watching it eagle eyed, maybe someone gets it done before i do the hardware mods

Is there are list somwhere for supported M Codes ? many i tried already which did work but a list would be great !

The gcode list isn't currently documented. In the mean time, if you look at the end of klippy/gcode.py you should find all the commands currently supported.

-Kevin

Ah ok, a restart resets both the host and the client, now i understand.

Found the Mcodes, thank you !

Thanks to you ill have an exiting evening, finally ive found a reason to step the tmcs up to ~30v and ill try to find my way around controlling external mosfets with klipper, from what ive seen so far its rather easy aswell.

PID for bed works, +-0.5'C. Good enough. Someone asked before.
This is my settings for sandwich: 3mm cork+MK2b+2mm glass :

[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: pid
pid_Kp: 53.40
pid_Ki: 0.56
pid_Kd: 1271.58
min_temp: 0
max_temp: 120

and command to find result of M303 E-1 S60 C8 (PID tuning for bed)

cat /tmp/klippy.log |grep Autotune

Edited 2 time(s). Last edit at 11/04/2017 04:11PM by rafalvonkrakow.

Thx rafal, i deleted that part of my comment after i found out bang bang with a hypothenuse of 0.5 works great aswell

Edited 1 time(s). Last edit at 11/04/2017 05:23PM by lenne0815.

Ok, i did step up the tmcs, hitting 250 now with 4k accels and 0.045 pressure advance, brought down retraction to 0.2.

The prints still exibit no common ringing when high speed cornering at all, what is becoming apparent now are smaller mechanical shortcomings like no precision milled idlers / Pulleys and bouncy belts.

The only general limit im seeing atm is extrusion rate / extrusion precision and print cooling ( Pla ), might even switch out the small printer to an volcano and add a second 50mm blower.

If this is a monument to your ingenuity its atleast the cheops kevin.

Edited 4 time(s). Last edit at 11/05/2017 07:19PM by lenne0815.

deleted

Edited 5 time(s). Last edit at 11/14/2017 07:55PM by newbob.

Does anyone recommend a particular platform for the MCU side of things?

I am interested in TMC2260 all around, so thought the Azteeg smoothieboard that can do that from Panucatt would be great. I have not confirmed yet whether Klipper supports that processor, of it there are better options. It seems according to devs "todo" [github.com] it is not an option yet. I may have overlooked it, but is there a list of supported MCUs so far? It seems due might be a good option as there are a few references to that. I can make my connectivity board for the due and add the TMC2660 drivers, but it might be alot more work.

For my project I'm trying to drop in place a klipper upgrade to a nice 3D printer, and am at the moment finding all the connectors so I can use stock wiring and what not [I have zero documentation on this printer sadly.] Hoping to choose the MCU board now so that in the same wire connector board I might be able to be smart about how I'm plugging in my MCU to avoid lots of jumper wires .

Based on what I've said so far, is the DUE the only relatively tested 32-bit platform for the MCU side of Klipper? It's OK if that is the case, just checking in. And does anyone recommend a DUE-type cape? The only one I'm familiar with is RAMPS32-bit, and i wasn't sure if that's recommended (love original ramps for what it offered but I overall didn't like the board and had one melt down on me couple years ago :p.)

Quote
Tomek
Does anyone recommend a particular platform for the MCU side of things?

I am interested in TMC2260 all around, so thought the Azteeg smoothieboard that can do that from Panucatt would be great. I have not confirmed yet whether Klipper supports that processor, of it there are better options. It seems according to devs "todo" [github.com] it is not an option yet. I may have overlooked it, but is there a list of supported MCUs so far? It seems due might be a good option as there are a few references to that. I can make my connectivity board for the due and add the TMC2660 drivers, but it might be alot more work.

The Smoothieboards are not currently supported. I'd like to see support added, but I don't have any short term plans to port Klipper myself.

The current supported micro-controllers are: Atmega 8bit chips (basically all common atmegas), Arduino Due, and Beaglebone PRU.

Also, separately, there is no current code support for the TMC2660 - if SPI messages are needed to configure the chip then some work may be needed to support that.

Quote

For my project I'm trying to drop in place a klipper upgrade to a nice 3D printer, and am at the moment finding all the connectors so I can use stock wiring and what not [I have zero documentation on this printer sadly.] Hoping to choose the MCU board now so that in the same wire connector board I might be able to be smart about how I'm plugging in my MCU to avoid lots of jumper wires .

Based on what I've said so far, is the DUE the only relatively tested 32-bit platform for the MCU side of Klipper? It's OK if that is the case, just checking in. And does anyone recommend a DUE-type cape? The only one I'm familiar with is RAMPS32-bit, and i wasn't sure if that's recommended (love original ramps for what it offered but I overall didn't like the board and had one melt down on me couple years ago :p.)

I've done unit testing on the Due and I don't foresee any major problems. However, there have not been a lot of users reporting feedback on it, so I'm not sure I'd call it "well tested". There's been more feedback on the Beaglebone+Replicape - but I personally wouldn't recommend the Beaglebone for a new setup.

-Kevin

Hmm, thanks Kevin for the response! I will think about it, perhaps the atmega 8-bit line will work out OK for me, with future upgrading to something faster/modern. I know I should try the Due if it's sorta-tested, and could benefit from more testing, but I am also leaving this printer with my more mechanically-not-software inclined father and may have a harder time troubleshooting odd issues, if there are any.

Will investigate what hardware options I have going with the 8-bit avrs...Another downside is I haven't seen boards with TMC2660s for the 8-bits, though I have enough hardware lying around that going with some other decent drivers and the existing 8-bit boards I have around may be enough for my short term needs.

I will look into whether or not I can add manage to port any of the SPI configuration for the TMC2660 drivers, it may be possible especially if I don't extend it to anything past "setup once per boot." I would be more comfortable doing that for an AVR than the due, but maybe it wouldn't be much different (just haven't really looked into that.)

One other board that looks really nice and has the drivers I want would be the duetwifi. It is based on the SAM4E8E, which seems like it should be relevant if the Due is running a similar processor, but I don't know enough for whether that would simplify porting.

Hope my statements don't sound too out of place, I am just someone with a mixed background in software (read: totally amateur but have/can do some things with C++ and python). I don't have a lot of intuition about how much work it would be to make another processor available with Klipper and whether I'd be up for that.

Short term most likely plan for me: Use A5984 or TMC2100 drivers on an 8-bit AVR board, and possibly extend the AVR code for the SPI config functions or use them in the dumb-step/dir mode.
Long term goal [especially if there's an idea about how hard it would be]: Maybe I can help to extend functionality from the due to the duetwifi? Seems it won't be immediate, because I suspect it will still be some work, and I have a lot of hardware changes to make to this printer before handing it off to my Dad.
(For me the main reason to use the duetwifi is that the PCB hardware is there for the drivers I want, but rationally, other drivers should be good enough for this project, for now, and I can extend the complexity later.)

Thanks again for your response and feedback! I look forward to getting Klipper running in the next month or so (my goal to have this printer up by the winter holidays/christmas for my Dad [he has expressed serious interest])

Edited 1 time(s). Last edit at 11/23/2017 10:58PM by Tomek.

:-)! Still making progress on the board I'm converting, and have a better sense of what's going on with the klipper code. Thank you, for what looks like a pretty small crew for this project (you + seems small bits from other people so far - nominally seems pretty much you) this is relatively much better documented than other things I've looked at. Wherever you have added notes about intent, code organization, etc, has been very helpful.

Do you recommend any particular software/ide for working with Klipper? Baring any recommendations I'd probably look at eclipse or atom.

Most of what I wrote in my previous post can be ignored :p. That is, I was just bumbling/excited about what hardware I'd choose but ultimately it won't matter too much. And I appreciate that I think I will be able to figure out how to do the config file and other such things for whatever I run (because it's fairly well documented and a logical workflow.) Maybe once I get a regular AVR board working I can look into getting other boards running and whether that's possible within my limited abilities. For now I still have a lot of pinouts to figure out on the printer I'm frankensteining.

Hello, Kevin!
I really liked the klipper and I want to use it. And I had to solve one more problem, layers shift, you can see in the photo. I do not use stepper motors in my 3D printer, I use collector motors with a step / dir interface instead. You can read about my printer here, I hope GoogleTranslit will help you. It seems klipper did not give my drivers enough width for step-pulse, because here's such a dirty hack fixed the layer shift:

stepper_event(struct timer *t)
{
    struct stepper *s = container_of(t, struct stepper, time);
    if (CONFIG_NO_UNSTEP_DELAY) {
        // On slower mcus it is possible to simply step and unstep in
        // the same timer event.
        gpio_out_toggle(s->step_pin);
        uint16_t count = s->count - 1;
        if (likely(count)) {
            s->count = count;
            s->time.waketime += s->interval;
                unsigned char xx;                                     /////////////
                for (xx=0; xx<10; xx++) { asm volatile ("nop") ; }  /////////////
            gpio_out_toggle(s->step_pin);
            if (s->flags & SF_HAVE_ADD)
                s->interval += s->add;
            return SF_RESCHEDULE;
        }
        uint_fast8_t ret = stepper_load_next(s, 0);
                unsigned char xx;                                       ///////////////
                for (xx=0; xx<10; xx++) { asm volatile ("nop") ; }     ///////////////
        gpio_out_toggle(s->step_pin);
        return ret;
    }

In another photo you can see the result. I understand that such a hack can not be left, but my skills are not enough to do it right. Therefore, I hope for your help.

Quote
pamalofeev
Hello, Kevin!
I really liked the klipper and I want to use it. And I had to solve one more problem, layers shift, you can see in the photo. I do not use stepper motors in my 3D printer, I use collector motors with a step / dir interface instead. You can read about my printer here, I hope GoogleTranslit will help you. It seems klipper did not give my drivers enough width for step-pulse, because here's such a dirty hack fixed the layer shift:

The Klipper stepping code is designed to provide at least a 2 micro-second step pulse. That time is sufficient for all commonly available stepper motor drivers. If I understand your article correctly, you've built your own motor driver (impressive!) that needs a longer step time.

Do you know how long of a step pulse time you need? The code you posted seems to produce a 4 micro-second step pulse time.

If your driver can handle a 3 micro-second step time then you could change:

            gpio_out_toggle(s->step_pin);
            if (s->flags & SF_HAVE_ADD)
                s->interval += s->add;

to:

            s->interval += s->add;
            gpio_out_toggle(s->step_pin);

It should not be necessary to add a delay on the second gpio_out_toggle() as that code path is already slow.

Increasing the step pulse time decreases the maximum stepping rate of the firmware. So I don't think it makes sense to change the main Klipper code.

-Kevin

Quote
KevinOConnor
If I understand your article correctly, you've built your own motor driver (impressive!) that needs a longer step time.
-Kevin

No, I used other people's designs, the basis of which was this old project. Despite the fact that it is very old, it is made correctly and works well. I studied at on the specialty "electric drive" and can distinguish a good DC drive from a bad one.
Thank you for helping me when I check this code, I will write here.
Sorry for my google-english.

Quote
KevinOConnor
If your driver can handle a 3 micro-second step time then you could change:

            gpio_out_toggle(s->step_pin);
            if (s->flags & SF_HAVE_ADD)
                s->interval += s->add;

to:

            s->interval += s->add;
            gpio_out_toggle(s->step_pin);

-Kevin

That helped! Thank you so much!

Quote
pamalofeev
You can read about my printer here

congratulations! really nice printer and very smooth.
It's an ideal companion for klipper...the same kind of enthusiasm...

Quote
hg42
It's an ideal companion for klipper...the same kind of enthusiasm...

Yes, I agree. With a klipper this printer works even more smoothly. In the publication I used teacup firmware.

Does klipper write anything to the 3d printer firmware other than when a person issues:

make flash FLASH_DEVICE=/dev/ttyACM0

Since I have read that the eeproms have a limited number of re-writes to them, I was curious to what situations klipper writes the firmware to the 3d printer electronics. Since I have not read this anywhere, it is probably not a problem.

Quote
geodave4
Does klipper write anything to the 3d printer firmware other than when a person issues:

make flash FLASH_DEVICE=/dev/ttyACM0

Since I have read that the eeproms have a limited number of re-writes to them, I was curious to what situations klipper writes the firmware to the 3d printer electronics. Since I have not read this anywhere, it is probably not a problem.

The Klipper run-time code does not modify the flash or eeprom. There is just the one time flash during the micro-controller build (as in the "make flash" command above).

-Kevin

Thanks. I will take a look at this again next month.

i am tmpted to try klipper but what stops me is the usb connection.. i have got rid of my octoprint in the past as the usb many times drops the connection and the printer haults mid print... very frustrating.

How realiable is the usb connection in klipper?

thanks for the great work!