New experimental firmware: all kinematics in host

Quote
pamalofeev

Quote
hg42
you still did not answer from where you got the number 25.

He got it here.

Quote

FEATURES
Klipper touts several “compelling features”:

Each stepper event is scheduled with a precision of 25 microseconds or better. The software does not use kinematic estimations (such as the Bresenham algorithm). It calculates precise step times based on the physics of acceleration and the physics of the machine kinematics. More precise stepper movement translates to quieter and more stable printer operation.

When I needed help with a teacup, the Traumflug refused me. When I needed help with the klipper, Kevin completely helped me. Maybe that's why the klipper is better than "others firmwares"?

I like that large part of Klipper (including configuration) is on Rpi and can be modified almost on the fly, no recomplile/flash needed. Another, potential, advantage will be output to more than one controller at a time which may lower cost for multi stepper setups (two atmega controllers instead of rare 10 stepper board). Lastly, it does not hurt that documentation and code is easy to read.

Reading about Teacup I was impressed about debugging options like running on VirtualAVR or i386 machine.


EDIT: klipper can run in VirtualAVR as well and also has a graphing script (graphstats) that parses logs.

Edited 3 time(s). Last edit at 12/31/2017 04:18PM by newbob.

"25 times a second" cannot be mentioned anywhere because it's definitely not true...

"NTP like" isn't mentioned anywhere, it's my own conclusion from the code I have looked at (not thoroughly).

This looked for me like:

send a request for a timestamp (taking some time to go through the communication channel),
receive the timestamp,
take the half between the times of the request and reception of the timestamp,
compare that to the timestamp.

Comparing to Marlin doesn't help a lot.

Marlin isn't bad but never tried to be the most accurate. If they would, they would change the jerk algorithm first, which creates a lot of ripples after each edge (I think we see something like that on the pictures above).
Marlin instead is very good in features because they accept new things from the community very very fast. The development is generally blazingly fast (big user base and many developers, and I really like their way to communicate with each other).
But being fast creates quality problems (bugs all the time). Especially because the community wants new features and versions.
I see Marlin as a test bed for new features. And I think it works well for that.

The real competitors are Smoothieware, RepRapFirmware and similar. 32bit...fast, smooth, exact etc.

The points for the community are these:

Klipper does work well with cheap hardware (say 35EUR for a PI3 and <<20EUR for one or even two RAMPS = about 50EUR + drivers).

It can reach better levels of performance, because there is enough computation power for any kind of calculations.

It is scalable and flexible like hell...
you can have a dedicated controller for each axis and each heater etc. (e.g. take 2-5EUR Arduino Nanos).
From what I read, I could even use another PI as MCU (in a linux real time process) for controlling steppers.
Or you could use a faster host. There are enough boards available, that can calculate steps and such and have serial interfaces (via USB or native), that's a quite common feature set, isn't it?.
Another good example for the flexibility is a beaglebone black with it's two PRUs, which are very fast and already supported.

Programming the top level doesn't need a C/C++ programmer...(= kind of expert).
Note, I am a C++ developer (mainly, among other languages) for about 30 years, so I know about it.
Python will add a lot of dynamic to the project, because it is much easier to understand and to handle and there will be much more developers.

However, the downside will be much more chaos...
that's why I would like to see a code base as flexible and modular as possible before all those developers start to join the project.
Kevin, may be you shouldn't beat the drum too much at this time.

Edited 1 time(s). Last edit at 01/03/2018 05:27AM by hg42.

Quote
newbob
I like that large part of Klipper (including configuration) is on Rpi and can be modified almost on the fly, no recomplile/flash needed.

I agree, it's another level of flexibility.
On Smoothieware you can edit the configuration and restart.
On Klipper you can edit just about every aspect that matters and restart.

Now many developers will say, today you compile very fast and you can do it with C/C++, too.
But the problem is you as a developer can do, but there are a lot of people that can understand, use or change python code but don't have the skills in C/C++.

Quote
newbob
EDIT: klipper can run in VirtualAVR as well and also has a graphing script (graphstats) that parses logs.

which shows how mature the project already is...

Quote
hg42

Quote
newbob
I like that large part of Klipper (including configuration) is on Rpi and can be modified almost on the fly, no recomplile/flash needed.

I agree, it's another level of flexibility.
On Smoothieware you can edit the configuration and restart.
On Klipper you can edit just about every aspect that matters and restart.

And in RepRapFirmware, you can change all the configuration parameters and not even have to restart, you just send the new configuration codes through the web interface. This means you can try out changes very quickly.

I take your point about Klipper being able to use cheap hardware, which is especially relevant to users who already have an 8-bit board + RPi running Octoprint and want to get more mileage out of their existing hardware. But for building a new system, once you add good high microstepping drivers, the total hardware cost isn't far short of a good 32-bit board anyway. A Duet may still cost a little more than your RPi+RAMPS suggestion, but you also get high current (as well as high microstepping) drivers, power monitoring, 24V compatibility, mosfets that don't overheat, much higher available heated bed current, a good warranty policy, and support.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

to be clear...
if you want a (high end) system working out of the box, a Duet (or other 32bit boards) is a good choice.
Such "one board does it all" solutions are especially well suited to a professional environment, where high availability and a low failure rate are wanted or necessary.
Boards like Duet or Smoothieboard are also well designed for high standards in security and durability.

I also like the way every parameter is tweakable in RepRapFirmware (though I never had one, but I read about it).
Actually, I (still) miss the availability of each and every parameter in Klipper.

But my general thoughts are directed to more experimental systems in the family of RAMPS - RADDS - CRAMPS - etc. for users that like to discover new things.
I think, 3D-Printing is still at it's beginning, in a pioneering phase. There is still no best way to go. Only something like current state of the art.
Everything may change. E.g. if I compare noise of a printer several years ago with my corexy with tmc2130 drivers, it's incredible how this changed.
Also using force detection on the hotend or the motors allows things nobody thought of years ago.

If you are working on experimental things, you are always in need of more freedom and more power (because of different reasons, e.g. because experimental algorithms are not optimized at all).
You may suddenly need more axes, more extruders, more of anything...you just don't know what's coming. So scalability is crucial.

It's also nice to program algorithms etc. in dynamic scripting languages. It's generally nearer to the algorithm and more high level thinking.

The point with cheap hardware is also based on the fact, that you don't like to risk a fancy and expensive board for such experiments. So you tend to try those things on cheap hardware or something laying around from other printers. E.g. I had everything to test Klipper in my box. All from "retired" hardware.

Very interesting!

Maybe you can incorporate the microcontroller part of the code on a SBC Linux computer (random-fruit pi) by using the I2S shift register output hack.

[forums.reprap.org]

Everything, from openscad to stepper control, could run on a single processor. This would be lovely since half my failed prints came from communication failures.

Hey Kevin, your Firmware is one awesome piece of Software, congrats!

I want to go all in with Klipper on my CoreXY with Ultratronics board.
The only thing holding me back are the timings of my External Stepper.
Im using Leadshine DM422C, they are great but pretty Slow.

The Timings are really well described but a bit weird in comparison with other Drivers:

b) t2: DIR must be ahead of PUL effective edge by 5ms to ensure correct direction;
c) t3: Pulse width not less than 7.5ms;
d) t4: Low level width not less than 7.5ms.

Im using Repetier Firmware currently and set it like that:

#define STEPPER_HIGH_DELAY 8
#define DIRECTION_DELAY 3

Pamalofeev had a similar Issue on Page 7, although i bet you described it very well im too much of a Programming noob to understand and change it to my needs.

Maybe you could help me out with this Issue

Quote
KevinOConnor

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
mrc
Hey Kevin, your Firmware is one awesome piece of Software, congrats!

I want to go all in with Klipper on my CoreXY with Ultratronics board.
The only thing holding me back are the timings of my External Stepper.
Im using Leadshine DM422C, they are great but pretty Slow.

The Timings are really well described but a bit weird in comparison with other Drivers:

b) t2: DIR must be ahead of PUL effective edge by 5ms to ensure correct direction;
c) t3: Pulse width not less than 7.5ms;
d) t4: Low level width not less than 7.5ms.

Im using Repetier Firmware currently and set it like that:

#define STEPPER_HIGH_DELAY 8
#define DIRECTION_DELAY 3

Pamalofeev had a similar Issue on Page 7, although i bet you described it very well im too much of a Programming noob to understand and change it to my needs.

Maybe you could help me out with this Issue

Thanks. I'm not sure which board you have - if this is a 32bit SAM3X8E board (as the Ultratronics Pro V1 is advertised to be), then you should be able to get an 8 micro-second delay by changing the following line in src/stepper.c from:

#define UNSTEP_TIME timer_from_us(2)

to

#define UNSTEP_TIME timer_from_us(8)

You'll then need to recompile and flash the micro-controller code. I don't think the direction pin timing is an issue as Klipper typically loads that way in advance of its first step.

Cheers,
-Kevin

Edited 1 time(s). Last edit at 01/10/2018 09:10PM by KevinOConnor.

Thanks a lot for your fast help!

The Installation worked flawless thanks to the very well done Documentation.
Endstops, Thermistors and Heater are working so far.

But my Stepper are making Problems, till now only one Stepper is working (Y).

X isn´t moving at all, the motor is only stalling.

Z responses to Homing but it´s only wiggling, not really noisy so i don´t think its losing steps.

I double checked the Pin Settings but i can´t find the solution, i got the feeling that im missing something important.

PS: is there a possibility to move the motors without Homing? It´s a nice safety feature but its not that great for debugging.

# This file serves as documentation for config parameters of corexy
# style printers. One may copy and edit this file to configure a new
# corexy printer. Only parameters unique to corexy printers are
# described here - see the "example.cfg" file for description of
# common config parameters.

# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
# FIRST. Incorrectly configured parameters may cause damage.

# The stepper_x section is used to describe the X axis as well as the
# stepper controlling the X+Y movement.
[stepper_x]
step_pin: ar35
dir_pin: ar34
enable_pin: ar37
step_distance: .001869
endstop_pin: ^!ar31
position_endstop: 0
position_max: 240
homing_speed: 10

# The stepper_y section is used to describe the Y axis as well as the
# stepper controlling the X-Y movement.
[stepper_y]
step_pin: ar22
dir_pin: ar23
enable_pin: ar33
step_distance: .001869
endstop_pin: ^!ar12
position_endstop: 0
position_max: 280
homing_speed: 10

[stepper_z]
step_pin: ar25
dir_pin: ar26
enable_pin: ar24
step_distance: .000245
endstop_pin: ^ar29
position_endstop: 0.2
position_max: 180

[extruder]
step_pin: ar46
dir_pin: ar47
enable_pin: ar48
step_distance: .001205
nozzle_diameter: 0.300
filament_diameter: 1.750
heater_pin: ar3
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog0
control: pid
pid_Kp: 13.5700
pid_Ki: 0.9000
pid_Kd: 50.9100
min_temp: 0
max_temp: 280

[heater_bed]
heater_pin: ar2
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog1
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: ar6

[mcu]
serial: /dev/ttyACM0
pin_map: arduino

[printer]
kinematics: corexy
#   This option must be "corexy" for corexy printers.
max_velocity: 300
max_accel: 3000
max_z_velocity: 15
max_z_accel: 10

in comparison my Repetier Firmware settings:

// Ultratronics Board  (experimental, use with care probably even not working!)
// [www.reprapworld.com]
#if MOTHERBOARD == 409
#ifndef __SAM3X8E__
#error Oops!  Make sure you have 'Arduino Due' selected from the 'Tools -> Boards' menu.
#endif

#define KNOWN_BOARD
#define CPU_ARCH ARCH_ARM

#define ORIG_X_STEP_PIN     35
#define ORIG_X_DIR_PIN      34
#define ORIG_X_MIN_PIN      31
#define ORIG_X_MAX_PIN      30
#define ORIG_X_ENABLE_PIN   37

#define ORIG_Y_STEP_PIN     22 
#define ORIG_Y_DIR_PIN      23
#define ORIG_Y_MIN_PIN      12
#define ORIG_Y_MAX_PIN      11
#define ORIG_Y_ENABLE_PIN   33

#define ORIG_Z_STEP_PIN     25
#define ORIG_Z_DIR_PIN      26
#define ORIG_Z_MIN_PIN      29
#define ORIG_Z_MAX_PIN      28
#define ORIG_Z_ENABLE_PIN   24

// Note that on the Due pin A0 on the board is channel 2 on the ARM chip
#define HEATER_0_PIN     3
// Due analog pin A0 = channel 7
#define TEMP_0_PIN       7

#define HEATER_1_PIN     2 
// Due analog pin A1 = channel 6
#define TEMP_1_PIN       6
// Due analog pin #58

#define HEATER_2_PIN     8
// Due analog pin A2 = channel 5
#define TEMP_2_PIN       5

#define HEATER_3_PIN     6
// Due analog pin A3 = channel 4
#define TEMP_3_PIN       4

#define HEATER_4_PIN     9
// Due analog pin A4 = channel 3
#define TEMP_4_PIN       3

// Dua analog pin #59 = A5 -> AD 2
#define THERMOCOUPLE_0_PIN  65   
#define THERMOCOUPLE_1_PIN  52   
#define THERMOCOUPLE_2_PIN  51   
#define THERMOCOUPLE_3_PIN  50   

#define ORIG_E0_STEP_PIN    47
#define ORIG_E0_DIR_PIN     46
#define ORIG_E0_ENABLE_PIN  48

#define ORIG_E1_STEP_PIN    44
#define ORIG_E1_DIR_PIN     36
#define ORIG_E1_ENABLE_PIN  45

#define ORIG_E2_STEP_PIN    42
#define ORIG_E2_DIR_PIN     41
#define ORIG_E2_ENABLE_PIN  43

#define ORIG_E3_STEP_PIN    39
#define ORIG_E3_DIR_PIN     38
#define ORIG_E3_ENABLE_PIN  40

#define SDSUPPORT      -1 
#define SDPOWER 	   -1
// 4,10,52 if using HW SPI.
#define SDSS 59
//#define NONSTANDARD_SDSS
#define MOSI_PIN        75
#define MISO_PIN        74
#define SCK_PIN         76

#define ORIG_SDCARDDETECT  60
#define SDCARDDETECTINVERTED 0
#define LED_PIN 	   13
#define ORIG_FAN_PIN 	6 
#define ORIG_FAN2_PIN  5 
#define ORIG_PS_ON_PIN -1
#define KILL_PIN	   -1
#define SUICIDE_PIN    -1  //PIN that has to be turned on right after start, to keep power flowing.
#define ENC424_SS             61 

I've been reading the docs and wondering how acceleration and deceleration portions of the trapezoidal motion is synchronized between the axes. Is acceleration/decel slope shared among axes?

Quote
mrc
Thanks a lot for your fast help!

The Installation worked flawless thanks to the very well done Documentation.
Endstops, Thermistors and Heater are working so far.

But my Stepper are making Problems, till now only one Stepper is working (Y).

X isn´t moving at all, the motor is only stalling.

Z responses to Homing but it´s only wiggling, not really noisy so i don´t think its losing steps.

I double checked the Pin Settings but i can´t find the solution, i got the feeling that im missing something important.

Nothing looks unusual from the config. We'd need to see the /tmp/klippy.log file to investigate further - see docs/Contact.md. Also, if you've modified the code, please also include the output from "cd ~/klipper ; git diff"

Quote

PS: is there a possibility to move the motors without Homing? It´s a nice safety feature but its not that great for debugging.

That is not currently implemented.

Quote
newbob
I've been reading the docs and wondering how acceleration and deceleration portions of the trapezoidal motion is synchronized between the axes. Is acceleration/decel slope shared among axes?

I'm not sure I understand your question. The Klipper host software determines the ideal time to step each stepper motor based on the formulas for acceleration and printer kinematics. Those times are then compressed, sent to the micro-controller, and the micro-controller executes that schedule of step times. So, acceleration is synchronized between stepper motors by virtue of each stepper stepping near their ideal time.

Klipper does not use "speed ramps" or similar kinematic estimation algorithms. These systems introduce inaccuracies into the motion of the printer - they are justified by the reduced micro-controller overhead they provide. Klipper doesn't need to estimate the kinematics as the kinematics are calculated on a general purpose computer (eg, a low-cost Raspberry Pi).

-Kevin

Quote
KevinOConnor

Quote
newbob
I've been reading the docs and wondering how acceleration and deceleration portions of the trapezoidal motion is synchronized between the axes. Is acceleration/decel slope shared among axes?

I'm not sure I understand your question. The Klipper host software determines the ideal time to step each stepper motor based on the formulas for acceleration and printer kinematics. Those times are then compressed, sent to the micro-controller, and the micro-controller executes that schedule of step times. So, acceleration is synchronized between stepper motors by virtue of each stepper stepping near their ideal time.

Klipper does not use "speed ramps" or similar kinematic estimation algorithms. These systems introduce inaccuracies into the motion of the printer - they are justified by the reduced micro-controller overhead they provide. Klipper doesn't need to estimate the kinematics as the kinematics are calculated on a general purpose computer (eg, a low-cost Raspberry Pi).

-Kevin

Thanks for your reply Kevin. I'm going to sit down one day and read the code...

I have another question, consider toolhead going from point A[0,0] to B[1,1]. You could do x+1 and then y+1 (you end up at the right point but path is not the shortest, not a line) I guess that's what one would call approximation. If you synchronize movement of both axes you'll get from A to B in the shortest possible way, drawing a line. However what if you have to move from A[0,0] to B[0,3]. Do you go x+1 and x+1 y+1 together? It seems to me due to step size and inability to control how fast step takes, in some cases, path has to be approximated. Am I right?

Quote
newbob
I have another question, consider toolhead going from point A[0,0] to B[1,1]. You could do x+1 and then y+1 (you end up at the right point but path is not the shortest, not a line) I guess that's what one would call approximation. If you synchronize movement of both axes you'll get from A to B in the shortest possible way, drawing a line. However what if you have to move from A[0,0] to B[0,3]. Do you go x+1 and x+1 y+1 together? It seems to me due to step size and inability to control how fast step takes, in some cases, path has to be approximated. Am I right?

If you command a cartesian printer from 0,0 to 1,1 at (say) 10 mm/s constant velocity then that's a move of ~1.414mm and the move should take ~.1414 seconds. The X stepper should then move at a velocity of ~7.071mm/s (1mm / .1414s). Similarly the Y stepper would have the same velocity. From this, you can figure out the step times for the X and Y steppers.

If you command a cartesian printer from 0,0 to 1,3 at 10mm/s constant velocity then that's a move of ~3.162mm and the move should take ~.3162 seconds. The X stepper should then move at a velocity of ~3.162mm/s, while the Y stepper should move at a velocity of ~9.487mm/s.

If, for argument sake, the stepper had a step size of 1mm and the move start time was at 7.0 seconds, then in the first case both the X and Y step would have an ideal time of ~7.070711. In the second case, the X would have an ideal step time of ~7.158114 while the Y would have ideal step times of ~7.05270, ~7.158114, ~7.263523.

Once Klipper has the ideal times, it compresses them (which can move each step time from its ideal time within an error window no greater than .000025 seconds to improve compression), sends them to the mcu, which executes the times according to the schedule.

-Kevin

Hey Connor thanks again for you reply.

i attached the the Log file, you can download the Klipper directory from my drive:
[drive.google.com]

EDIT: i missed to change the delay (8) in this log, nevertheless it behaved exactly the same as with the delay (only Y running).

meanwhile i reinstalled and flashed everything without further sucess. I switched temporary back to repetier firmware without any issues.

Best

Edited 2 time(s). Last edit at 01/14/2018 01:52PM by mrc.

Is it possible to use the Repeater Server instead of OctoPi?

Quote
mrc
i attached the the Log file, you can download the Klipper directory from my drive:
[drive.google.com]

EDIT: i missed to change the delay (8) in this log, nevertheless it behaved exactly the same as with the delay (only Y running).

Neither the log nor the "Klipper directory" link you sent show the code change. In order to help I'd need to see the log from after the change as well as the output from the command "cd ~/klipper ; git diff" run after the change on the Raspberry Pi. Again, it would require changing src/stepper.c to use 8 microseconds and then the micro-controller needs to be reflashed.

-Kevin

Quote
alexmx
Is it possible to use the Repeater Server instead of OctoPi?

I don't know - someone would need to test it and report back.

-Kevin

I planning to install Repetier Server next to the OctoPi. The first question is "\tmp\printer" serial port which defined in "Serial Connection" in "Additional serial ports"?

-Alex

Quote
KevinOConnor

Quote
mrc
i attached the the Log file, you can download the Klipper directory from my drive:
[drive.google.com]

EDIT: i missed to change the delay (8) in this log, nevertheless it behaved exactly the same as with the delay (only Y running).

Neither the log nor the "Klipper directory" link you sent show the code change. In order to help I'd need to see the log from after the change as well as the output from the command "cd ~/klipper ; git diff" run after the change on the Raspberry Pi. Again, it would require changing src/stepper.c to use 8 microseconds and then the micro-controller needs to be reflashed.

-Kevin

Sorry for this noob question, and big thanks for your Help! Flashing the MCU AFTER changing the Stepper.c fixed my problem.

It´s running smoothly now, i guess i can do my first Print with Klipper today.

Quote
hg42
It is scalable and flexible like hell...
you can have a dedicated controller for each axis and each heater etc. (e.g. take 2-5EUR Arduino Nanos).

Poked around in the klipper documentation to see how I could do this, am I correct to assume that I would need to wire up a stepper driver to each Arduino Nano, load up the firmware with them (configuring its alias) and then connect all of them to the main Raspberry Pi through a USB hub?

Quote
teikjoon
am I correct to assume that I would need to wire up a stepper driver to each Arduino Nano, load up the firmware with them (configuring its alias) and then connect all of them to the main Raspberry Pi through a USB hub?

3 x yes

Note I should have said "could" instead of "can" because there are some limitations.

For a corexy it is currently necessary to have XY on the same CPU, because:

• an endstop for a motor must generally be on the same MCU (I think... probably because it has to react fast enough, interrupt handling etc.)
• for corexy a motor must be stoppable by both endstops, because an endstop is not directly related to the motor, e.g. X movement uses only X endstop but both motors

I already tested another solution (which Kevin doesn't want):

• I made both endstops pull on the same line (which works, because endstop inputs usually have a pullup resistor and need only be pulled to GND)
• I connected this combined endstop to both MCUs. So both endstops always stop both motors.
• I had to change corexy.py to have only one endstop input per motor
• You then have to ensure that both endstops are open on intitialization and after homing. Klipper homing currently leaves the print head in triggered endstops (no retract after homing), so I had to change this, adding a second retraction

This combined_endstops solution works for me and I use it daily.

For delta this would be more complicated, because you cannot simply combine the endstops. You need to know which one is triggered.
To distribute them onto separate MCUs, endstop reading and stopping motors could be separated (e.g. by combining the signals with diodes).

Apart from respecting such physical dependencies that have to be handled, it's easy to put each axis, extruder, temperature control etc. on it's own MCU.

Edited 2 time(s). Last edit at 01/21/2018 10:26PM by hg42.

Quote
teikjoon

Quote
hg42
It is scalable and flexible like hell...
you can have a dedicated controller for each axis and each heater etc. (e.g. take 2-5EUR Arduino Nanos).

Poked around in the klipper documentation to see how I could do this

but keep in mind, this is only a potential thing to do, if you need scalability, or may be you like the modular approach.

A simple mega2560/RAMPS combination will easily do the whole MCU job, because all complex things like calculating delta kinematics or precise step times run on the host (PI or PC).
So Klipper kind of "upgrades" your printer electronics by outsourcing the heavier jobs.

Though, I admit that I did not test this myself (I use RAMPS for XYZ + a TronXY board for the rest). But it seems to be a usual configuration (Kevin uses a RAMBO I think).

Edited 1 time(s). Last edit at 01/22/2018 07:40AM by hg42.

I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.

Only thing that is problematic is the "restart" command, it seems that it doesnt work. It gives me "Automated restart of mcu.... Etcetc" Is there any way to get this working?

And the other thing is that z-axis studders, it moves a couple of millimeters and then just studdering...

I used general-printrboard.cfg and changed pin names to match sav mk1, was this the right way to do it?

Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.

Only thing that is problematic is the "restart" command, it seems that it doesnt work. It gives me "Automated restart of mcu.... Etcetc" Is there any way to get this working?

If you're having an issue, please follow the directions at https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md to report it. In particular, we need the klippy.log file in order to assist.

Quote

And the other thing is that z-axis studders, it moves a couple of millimeters and then just studdering...

Please also be sure to read about that item in the FAQ.

Quote
KevinOConnor

Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.

Only thing that is problematic is the "restart" command, it seems that it doesnt work. It gives me "Automated restart of mcu.... Etcetc" Is there any way to get this working?

If you're having an issue, please follow the directions at https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md to report it. In particular, we need the klippy.log file in order to assist.

Quote

And the other thing is that z-axis studders, it moves a couple of millimeters and then just studdering...

Please also be sure to read about that item in the FAQ.

Now I managed to get Z-axis to work.

I´m going to try the github way with the reset problem, I looked the log file but I couldn´t found any problem from there, just the same message "Automated reset of mcu...." First I´m going to check if theres something else wrong.

Quote
hg42
A simple mega2560/RAMPS combination will easily do the whole MCU job, because all complex things like calculating delta kinematics or precise step times run on the host (PI or PC).
So Klipper kind of "upgrades" your printer electronics by outsourcing the heavier jobs.
.

I guess I will try out klipper first, then see if I can start splitting each motor to a seperate Arduino/stepper driver...was asking because I was interested in messing about with multi-extruder things like the diamond hot end

Looked through github, guess there is not Z probe code in yet...but is it possible to map the bed via an external mechanism, then load this into klipper somehow?

Currently I use manual mesh bed levelling in Marlin...since it is able to generate a (mesh?) of Z-offsets...could I not save it as a text file and tweak some code so that it would use these offsets?

Hi Kevin !
I'm a big fan of your work, which seems strategic to me: this approach could change a lot of things in 3D FDM printing.

1 - Not only the gurus will be able to put their grain of salt in the firmware, written in Python. New ideas will certainly emerge.

2 - Controller cards that do everything, and impose their personality and performance (and their limitations) on the printer, could disappear, replaced by small control units, simple, cheap, and not necessarily specific to 3D printing, and perhaps communicating wirelessly, for each machine component (Hot bed, Hot-end, Steppers/Endstops, etc...).

3 - Once Klipper is installed on a computer that can also run other applications, there is nothing to stop you from associating a slicer with it, and thus potentially bypassing the intermediate step of the G-Code.

The G-Code is almost 60 years old, it is one of the oldest standards of computing. Although it is the software base for all current printers, it is not, in my opinion, well suited. The G-Code makes positions in a Cartesian frame of reference the central concept, while most modern machines, and not just 3D printers, need to use trajectory as a basic concept, with NURBS as the underlying mathematics. It is conceptually simpler, more elegant, more efficient and closer to physical realities. The G-Code allows only a very brief and too ideal representation of the movement, and adapts to the new needs only with grafts and blisters. For example, it is almost impossible to encode a viscous movement, which is the essence of FDM printing, whereas with NURBS, it is trivial. To do without the G-Code, and to put everything into more adapted mathematical representations, would, in my opinion, be a salutary simplification.

Logically, this evolution should be accompanied by the replacement of the STL format, which is also much too basic (no color or material specification, in particular), in favour of a more modern format based on Bézier curves and NURBS.

Have you considered this path of evolution, in the future, for Klipper: to do without the G-Code?


Translated with www.DeepL.com/Translator

Quote
M_Xeno
Hi Kevin !
I'm a big fan of your work, which seems strategic to me: this approach could change a lot of things in 3D FDM printing.

Thanks!

Quote

Have you considered this path of evolution, in the future, for Klipper: to do without the G-Code?

I agree that G-Code isn't flexible enough to meet the needs of modern 3d printing. I tried to make the Klipper code more approachable for those that want to experiment with other solutions. However, I don't have any short term plans to work on it myself.

Cheers,
-Kevin

Quote
kapperi

Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.

I´m going to try the github way with the reset problem, I looked the log file but I couldn´t found any problem from there, just the same message "Automated reset of mcu...." First I´m going to check if theres something else wrong.

Actually it doesn't work at all. Shortly after starting the print I got "Timer too close" problem.

So this is useless with my hardware.

I started two issues in github but klippy.log was from this later problem.

I really dont want that crappy marlin anymore...