New experimental firmware: all kinematics in host

Quote
MarkLogan
I didn't see much change with the various pressure advance values either. There is definitely a little blobbing at the corners on high speed, but the various pressure advance settings didn't seem to make much difference. I have it set to .2 and for the most part I'm getting good prints, although there have definitely been some prints where it skips steps/under extrudes in a couple of places. I think its very much related to the combination of retraction settings and pressure advance. Funny thing is that I was getting a lot of stringing, more so than with marlin, so I had to increase my retraction length which decreased the places where I was seeing under extrusion/skipped steps.

I'm on a corexy (D-bot) with a bowden extruder - with a particularly long bowden tube due to the size of the print area and the location of the extruder motor.

Okay. I'd recommend disabling pressure_advance if you don't observe an improvement in the hollow square test with values between 0.0 and 0.2. I think of the retraction during pressure_advance as a controlled release of pressure instead of an actual pulling of the filament. If you're not observing the pressure release, then it's an indication that the extruder may be pulling filament (instead of just allowing filament to naturally flow backwards), and that's just going to complicate things.

FWIW, other users have reported similar findings, but were able to utilize pressure advance if they reduced their extrude temperature. (At a high temp, the filament just drips out of the extruder, but with a slightly lower temp, the filament has a higher viscosity and the extruder has more control over it.) That said, if you aren't seeing an issue with temperature, I wouldn't tune that just to use pressure advance.

What retraction setting are you using now? What were you using on Marlin?

Quote
KevinOConnor

Quote
MarkLogan
I didn't see much change with the various pressure advance values either. There is definitely a little blobbing at the corners on high speed, but the various pressure advance settings didn't seem to make much difference. I have it set to .2 and for the most part I'm getting good prints, although there have definitely been some prints where it skips steps/under extrudes in a couple of places. I think its very much related to the combination of retraction settings and pressure advance. Funny thing is that I was getting a lot of stringing, more so than with marlin, so I had to increase my retraction length which decreased the places where I was seeing under extrusion/skipped steps.

I'm on a corexy (D-bot) with a bowden extruder - with a particularly long bowden tube due to the size of the print area and the location of the extruder motor.

Okay. I'd recommend disabling pressure_advance if you don't observe an improvement in the hollow square test with values between 0.0 and 0.2. I think of the retraction during pressure_advance as a controlled release of pressure instead of an actual pulling of the filament. If you're not observing the pressure release, then it's an indication that the extruder may be pulling filament (instead of just allowing filament to naturally flow backwards), and that's just going to complicate things.

FWIW, other users have reported similar findings, but were able to utilize pressure advance if they reduced their extrude temperature. (At a high temp, the filament just drips out of the extruder, but with a slightly lower temp, the filament has a higher viscosity and the extruder has more control over it.) That said, if you aren't seeing an issue with temperature, I wouldn't tune that just to use pressure advance.

What retraction setting are you using now? What were you using on Marlin?

I had just put new Capricorn bowden tube on before changing to this firmware. With that bowden tube I had taken my retraction down to around 3.5mm from 4.5mm. Now I've gone back up to the 4.5mm and it seems to be working fairly well. Trouble is I can't say whether its related to the firmware or the actual bowden tube At some point I'll turn off the pressure advance and do some tests with both retraction levels to see how it works. Have to say that right now things are quite stable - I'm printing at 100mm/s and getting nice high quality prints with the pressure advance and retraction settings that I have.

But mm X step in config file?

Hi Kevin.

How do we upgrade our package? I have seen a number of updates have been posted recently.

Have been trying to do some actual printer rather than test prints, but I am hitting the issue of firmware restart on X and Y axis which is only with 3 decimal places (0.0125 and also with 0.0124) and I will lose quite a bit of accuracy to go to two decimal places.

My drivers were supposed to be A4988 but they are marked HR4988 which are supposed to be capable of micro stepping at 128 times, so I am keen to try, but need klipper as it is only arduino mega, but these drivers do seem harsh.

Thanks
Regards
Alastair

Quote
chapelhill
How do we upgrade our package? I have seen a number of updates have been posted recently.

One would ssh into the raspberry pi and run: cd ~/klipper/ ; git pull

Then, in the general case, one would rerun the klipper install script and reflash the micro-controller code as described in the installation instructions. However, most of the time, only a host software restart is needed: sudo service klipper restart

FYI, the bug with unusual Z step sizes should be fixed in the latest code.

-Kevin

Hi Kevin.

Thanks very much for the quick response and updates, I will have a go as soon as my current print has finished and flash back Klipper onto the Arduino.

Regards
Chapelhill.

I just tried vase mode (spiralize outer contour in Cura) on a pumpkin shape. It had some strange results. You can picture the outside of the pumpkin as a series of almost semi-circles that meet at a point between each. Not a great description I know... Anyway, what was happening was that print head was starting at a point where the semi-circle would meet the previous one, but then it was traveling on a bigger arc than where the edge of the object was. It was almost 1/8" outside the object at its furthest, and then it would come back in and be in the right spot for where the next semi-circle would start. The filament was actually shrinking in to almost be in the right spot, but obviously was not adhering to the previous layer.

I haven't gone back and tried this particular print in marlin to see if its a slicing issue. The layer view in Cura makes it look correct, but that's not 100% guarantee of anything. I guess my question is: Is there anything in Klipper that I should look at for doing a vase mode print? Later this afternoon I'm going to grab another item and try it in vase mode to see if I see the same issue. Then I can go back and compare to marlin if that is necessary.

Thanks,
Mark

Quote
MarkLogan
I just tried vase mode (spiralize outer contour in Cura) on a pumpkin shape. It had some strange results. You can picture the outside of the pumpkin as a series of almost semi-circles that meet at a point between each. Not a great description I know... Anyway, what was happening was that print head was starting at a point where the semi-circle would meet the previous one, but then it was traveling on a bigger arc than where the edge of the object was. It was almost 1/8" outside the object at its furthest, and then it would come back in and be in the right spot for where the next semi-circle would start. The filament was actually shrinking in to almost be in the right spot, but obviously was not adhering to the previous layer.

I haven't gone back and tried this particular print in marlin to see if its a slicing issue. The layer view in Cura makes it look correct, but that's not 100% guarantee of anything. I guess my question is: Is there anything in Klipper that I should look at for doing a vase mode print? Later this afternoon I'm going to grab another item and try it in vase mode to see if I see the same issue. Then I can go back and compare to marlin if that is necessary.

Klipper does not currently implement look-ahead between moves that contain Z movement. (Look-ahead is currently only done if both moves are in the same XY plane.) This means that in "vase mode" there is no look-ahead being done. This will result in each g-code move starting from zero acceleration and returning to zero acceleration at the end of the move. On a curved surface, that's a lot of g-code moves which is likely resulting in some jerkiness in the head.

Worse, because look-ahead isn't done, pressure advance lookahead is also not done. This means that the extruder is going to be doing a lot of forward and backwards movement if pressure advance is configured.

Is it possible that the 1/8" difference you are seeing is actually the result of insufficient filament (due to constant extruder velocity changes) on the print? That is, is the previous layer pulled in due to lack of filament resulting in the next layer appearing to be outside the print?

Enabling look-ahead between moves with Z changes does not look like it will be difficult. So, that's probably the best way forward. Let me know if you're willing to test.

Quote
KevinOConnor

Quote
MarkLogan
I just tried vase mode (spiralize outer contour in Cura) on a pumpkin shape. It had some strange results. You can picture the outside of the pumpkin as a series of almost semi-circles that meet at a point between each. Not a great description I know... Anyway, what was happening was that print head was starting at a point where the semi-circle would meet the previous one, but then it was traveling on a bigger arc than where the edge of the object was. It was almost 1/8" outside the object at its furthest, and then it would come back in and be in the right spot for where the next semi-circle would start. The filament was actually shrinking in to almost be in the right spot, but obviously was not adhering to the previous layer.

I haven't gone back and tried this particular print in marlin to see if its a slicing issue. The layer view in Cura makes it look correct, but that's not 100% guarantee of anything. I guess my question is: Is there anything in Klipper that I should look at for doing a vase mode print? Later this afternoon I'm going to grab another item and try it in vase mode to see if I see the same issue. Then I can go back and compare to marlin if that is necessary.

Klipper does not currently implement look-ahead between moves that contain Z movement. (Look-ahead is currently only done if both moves are in the same XY plane.) This means that in "vase mode" there is no look-ahead being done. This will result in each g-code move starting from zero acceleration and returning to zero acceleration at the end of the move. On a curved surface, that's a lot of g-code moves which is likely resulting in some jerkiness in the head.

Worse, because look-ahead isn't done, pressure advance lookahead is also not done. This means that the extruder is going to be doing a lot of forward and backwards movement if pressure advance is configured.

Is it possible that the 1/8" difference you are seeing is actually the result of insufficient filament (due to constant extruder velocity changes) on the print? That is, is the previous layer pulled in due to lack of filament resulting in the next layer appearing to be outside the print?

Enabling look-ahead between moves with Z changes does not look like it will be difficult. So, that's probably the best way forward. Let me know if you're willing to test.

I'm running another test right now, its working much better. I think the gap was likely a bad model/bad slicing as opposed to a problem with the firmware.

That being said, you are absolutely right about the forward/backwards moves on the extruder. I had already planned to do my next print with pressure advance turned off to see the difference in the extruder.

I'm not noticing jerkiness in the head. Its actually moving reasonably smoothly. From the looks of it, this piece has been designed at a relatively low resolution, so its really more a series of short straight lines making up the curve which may alleviate the jerkiness in this print. There are lots of designs that I could print in vase mode that are more perfectly round and I would be more than happy to test any code changes you may make.

the coordinates of the bed center where I insert them? in simplify is also centered the octoprint I have put in

Quote
MarkLogan
I'm not noticing jerkiness in the head. Its actually moving reasonably smoothly. From the looks of it, this piece has been designed at a relatively low resolution, so its really more a series of short straight lines making up the curve which may alleviate the jerkiness in this print. There are lots of designs that I could print in vase mode that are more perfectly round and I would be more than happy to test any code changes you may make.

FYI, I updated the code to support look-ahead between Z moves. Just pull the latest code to test it.

-Kevin

Hi Mark.
I tested the code for the variable overflow in compression on my corexy at the weekend and did not manage to get any further incidents of the firmware stopping using my theoretical X,y and z step size. When I get some more time I will try the 128 microstepping which was the worst case last time to give a more thorough test.
Thanks
Regards
Chapelhill

Quote
KevinOConnor

Quote
MarkLogan
I'm not noticing jerkiness in the head. Its actually moving reasonably smoothly. From the looks of it, this piece has been designed at a relatively low resolution, so its really more a series of short straight lines making up the curve which may alleviate the jerkiness in this print. There are lots of designs that I could print in vase mode that are more perfectly round and I would be more than happy to test any code changes you may make.

FYI, I updated the code to support look-ahead between Z moves. Just pull the latest code to test it.

-Kevin

Kevin - I downloaded the latest yesterday and did a print in vase mode. Came out great, I think less forward/backward on the extruder but hard to tell. The entire vase/bowl came out water tight which is pretty much my measure for a good vase mode print. I'm doing another now that is a complex vase mode print to see how it handles everything. The first layer was a single line for the entire layer (very cool print really) and I noted that there was no backwards/forwards on the extruder. I'll monitor throughout the print and see how it does. I'm going to be away for a few days but when I'm back I'll do a standard 'round' vase to confirm that its working as expected for that too.

Here's the link to what I'm printing right now:
[www.thingiverse.com]

Oh, I also did a couple of small 'non-vase mode' prints and everything was fine. Figured I should confirm standard prints weren't affected by the changes too

Mark

Hi Kevin.
I updated code today and have been using the stepper drivers in 32x micro stepping for x, y and extruder, still using z stepper on 16x but I think the calculation for the step distance on Z might still be causing a problem (1.5mm pitch.) The print worked completely normal except when it was probably executing the print end script and the Firmware crashed. It could be an error in my ending script, so apologies if it is and perhaps my M140 S0 ; turn off bed as I have no bed configured could be causing it?
G91 ; use relative positioning for the XYZ axes
G1 Z10 F300 ; move 10mm to up of the current location
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M84 ; disable motors
M246 ;Disable cooler fan
M107 :Turn fan off

It won't stop me using it, as I suspect if I change the G1 Z10 F300 to something like G1 Z9 F300 it will work.

I have full klippy.log if you need it?

Thanks
Regards
Chapelhill

Edited 1 time(s). Last edit at 09/08/2017 09:28AM by chapelhill.

I've done a further test on vase/spiralize mode. I printed a test cup in vase mode (https://www.thingiverse.com/thing:2437766) and ran into a problem when I had pressure advance on. The bottom layers printed great, however as soon as it got to the 'spiral' part, the printing slowed way down and the pressure advance was going a little crazy. It would make it somewhere between 4 and 10 circuits and then the filament would stop extruding - I think mostly because it had worn the filament in a single location due to repeated forward/backward movements on the same small area of filament.

I turned pressure advance off and tried again. The cup came out very well with all forward/backward movement on the extruder gone (which makes sense obviously). The only thing of note was that the nozzle speed was significantly lower during the 'spiral' part of the print vs the printing of the bottom layers.

Mark

Quote
chapelhill
Hi Kevin.
I updated code today and have been using the stepper drivers in 32x micro stepping for x, y and extruder, still using z stepper on 16x but I think the calculation for the step distance on Z might still be causing a problem (1.5mm pitch.) The print worked completely normal except when it was probably executing the print end script and the Firmware crashed. It could be an error in my ending script, so apologies if it is and perhaps my M140 S0 ; turn off bed as I have no bed configured could be causing it?
G91 ; use relative positioning for the XYZ axes
G1 Z10 F300 ; move 10mm to up of the current location
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M84 ; disable motors
M246 ;Disable cooler fan
M107 :Turn fan off

It won't stop me using it, as I suspect if I change the G1 Z10 F300 to something like G1 Z9 F300 it will work.

I have full klippy.log if you need it?

Yes - I'd need the full log to investigate. If it's large run "gzip -k /tmp/klippy.log" and then attach the resulting /tmp/klippy.log.gz file. Use scp to copy the file from the rpi.

-Kevin

Hi Kevin.
Full compressed Klippy log attached:

I have been doing some more printing and with same end script it does not always have the problem and I have only experienced it at the end.

Hope that helps.
Regards
Chapelhill

Quote
chapelhill
Hi Kevin.
Full compressed Klippy log attached:

I have been doing some more printing and with same end script it does not always have the problem and I have only experienced it at the end.

Hope that helps.
Regards
Chapelhill

Thanks. It looks like there was a bug in the corexy kinematics. (It wasn't related to z movement.) Specifically, the host programs the mcu with a maximum stepper halt velocity - it's used as a failsafe to detect communication problems. Unfortunately, the math in that calculation was appropriate for cartesian printers, but not corexy printers.

It should be fixed now in the latest code.

Separately, if I understand your config correctly (corexy, 200mm/s, .00625 mm/step) you're peaking at around 70K steps/second. Not bad for a 16Mhz avr.

-Kevin

Hi Kevin.
I updated to latest version and ran about 4 or 5 prints off with no re-occurrence of the issue at the end of print. I have not had a chance to test maximum speed yet as I have only just converted to 24v but will hopefully at the weekend.
Regards
Chapelhill.

Hi Kevin.

I did get another shutdown event but only after cancelling a print and trying to home.
I have klippy log but it is too big to upload even compressed.
Do you want me to get the start and last bits of the log file?

Send: G91
Recv: ok
Send: G1 Y10 F6000
Recv: ok
Send: G90
Recv: ok
Send: G91
Recv: ok
Send: G1 X10 F6000
Recv: ok
Send: G90
Recv: ok
Send: G91
Recv: ok
Send: G1 X10 F6000
Recv: ok
Send: G90
Recv: ok
Send: G91
Recv: ok
Send: G28 Z0
Recv: !! Failed to home stepper z: MCU is shutdown
Recv: ok
Send: G90
Recv: // MCU shutdown: Timer too close
Recv: // This is generally indicative of an intermittent
Recv: // communication failure between micro-controller and host.
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Recv: !! Printer is shutdown
Recv: ok

Quote
chapelhill
Hi Kevin.

I did get another shutdown event but only after cancelling a print and trying to home.
I have klippy log but it is too big to upload even compressed.
Do you want me to get the start and last bits of the log file?

Alas, I need the full log in order to analyze the problem. If it's too large to post it here, compress it (gzip -k /tmp/klippy.log) and attach it to a new issue on github. Or, you can email it to me ([email protected]).

-Kevin

Kevin - I went away for a few days. Left the printer off while I was gone. Came back and tried to print something. It repeatedly stopped after homing X, Y and Z. I could manually move and home the various directions. I synced the latest version including rebuilding and reflashing. Now I can connect and start heating, but about 10 seconds after I start heating, it shuts down. I'm not sure if its a hardware issue or a firmware issue. I cleaned out the log, restarted fresh and then copied the log after the problem. Attaching here. I can retry flashing marlin to confirm whether its a hardware problem, but that will probably be tomorrow night before I get time. (Although knowing me I'll probably stay up late and do it tonight because I really want to know ).

Quote
MarkLogan
Kevin - I went away for a few days. Left the printer off while I was gone. Came back and tried to print something. It repeatedly stopped after homing X, Y and Z. I could manually move and home the various directions. I synced the latest version including rebuilding and reflashing. Now I can connect and start heating, but about 10 seconds after I start heating, it shuts down. I'm not sure if its a hardware issue or a firmware issue. I cleaned out the log, restarted fresh and then copied the log after the problem. Attaching here. I can retry flashing marlin to confirm whether its a hardware problem, but that will probably be tomorrow night before I get time. (Although knowing me I'll probably stay up late and do it tonight because I really want to know ).

There's been a lot of recent work done in the Klipper clock synchronization code and an error was inadvertently introduced. It should be fixed now.

-Kevin

Quote
KevinOConnor

Quote
MarkLogan
Kevin - I went away for a few days. Left the printer off while I was gone. Came back and tried to print something. It repeatedly stopped after homing X, Y and Z. I could manually move and home the various directions. I synced the latest version including rebuilding and reflashing. Now I can connect and start heating, but about 10 seconds after I start heating, it shuts down. I'm not sure if its a hardware issue or a firmware issue. I cleaned out the log, restarted fresh and then copied the log after the problem. Attaching here. I can retry flashing marlin to confirm whether its a hardware problem, but that will probably be tomorrow night before I get time. (Although knowing me I'll probably stay up late and do it tonight because I really want to know ).

There's been a lot of recent work done in the Klipper clock synchronization code and an error was inadvertently introduced. It should be fixed now.

-Kevin

Thanks again for replying to me so quickly and getting my printer back up and running. Very much appreciated!

Mark

[www.3ders.org] University of Michigan professor doubles 3D printing speeds using vibration-mitigating algorithm

Edited 1 time(s). Last edit at 10/21/2017 03:08PM by kdodman.

I checked on Git, any love for the Azteeg X5 (mini & GT) Smoothies planned? I have Due/Radds & a Pi3B on the way, but it would be cool to use boards that are already installed...

Thanks Much!

Quote
Diggrr
I checked on Git, any love for the Azteeg X5 (mini & GT) Smoothies planned?

I'd like to see support added, but I don't have any immediate plans to port Klipper myself.

If anyone is interested in taking it up, take a look at the code in the src/sam3x8e/ directory as an example of what is necessary.

-Kevin

Man, I wish I could..
Due/Radds it is, I just have to order steppers drivers yet...I have a NEMA23 in the mix and need a few more amps.

Thanks, hell-bent on giving your work a shot.

This is an announcement for the Klipper v0.5.0 release. Highlights of this release:
* Support for printers with multiple extruders.
* Initial support for running on the Beaglebone PRU. Initial support for the Replicape board.
* Initial support for running the micro-controller code in a real-time Linux process.
* Support for multiple micro-controllers. (For example, one could control an extruder with one micro-controller and the rest of the printer with another.) Software clock synchronization is implemented to coordinate actions between micro-controllers.
* Stepper performance improvements (20Mhz AVRs up to 189K steps per second).
* Support for controlling servos and support for defining nozzle cooling fans.
* Several bug fixes and code cleanups

A mailing list and an IRC channel have also been setup. See https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md for more information.

For general information on Klipper see:
https://github.com/KevinOConnor/klipper

For the Klipper release history see:
https://github.com/KevinOConnor/klipper/blob/master/docs/Releases.md

Kevin, congrats on another excellent release.

Klipper is a monument to your ingenuity, I'm a big fan and hope it gains in popularity and use, it deserves more attention.