Pressure advance useless for curves / circles?

[oderwat]

Am I right, that pressure advance will have no effect when you print a tube or cylinder?

[StefanMeGit]

if the its not printed in vase mode, pressure advance will also work on tube or cylinders... it works on every speed or speed down... doesn't matter what object or curve or whatever.

[oderwat]

So it does not work on single extrusions/lines but on a continuous extrusion speed calculated as one dimensional vector. If that speed changes it jumps in. Is that about correct?

[StefanMeGit]

Thats correct... thats the main function of pressure_advanced.

[KevinOConnor]

Pressure advance takes effect whenever the extruder flow rate changes. It is not related to the direction of movement. There's some details on pressure advance at: https://github.com/KevinOConnor/klipper/blob/master/docs/Kinematics.md#extruder-kinematics

-Kevin

[oderwat]

What I actually was questioning is if it helps to avoid a seam when printing a tube like object.

I think I am going to write a GCode generator which lets me create a test case. I think of having a halve circle where the speed for one half is different than for the other halve and one of the halves have a full stop in the middle. the same for the "other side" which should be a rectangle which have 3 speeds and a full stop in the middle too. for lifting to a new layer I am thinking of a central small square pilar with all for sides using the same speed but one of the corners will be the z-lift point.

I think this should work with a single line and may be a good way to analyse different settings. It could actually change the settings every some layers. Something in those lines...

[oderwat]

So if I understand @KevinOConnor and the docs right, PA will only look at the E speeds and not at all at the printer head speeds. But the E speeds are calculated by Klipper based on the given extrusion lengths and travel distances (and accel/max speed) calculated from that. That is close to what I imagined on how pressure advance may work. I just overlooked that the Extruder speed actually is directly coupled to what I thought of being the "one dimensional" speed vector calculated from the movements. Thats me trying to grasp stuff without programming it myself :)

[slipstreamliner]

@oderwat Klipper processes standard sliced gcode and makes adjustments to the way sudden changes in acceleration are handled in order to form a more stabilized motion throughout the layer; this leads to a number of great results while printing. For example, the dreaded Zig-Zag is replaced by a trapezoidal wall infill method. In fact, the trapezoidal method is really how the acceleration control is "implemented" even though it's jut Gcode at that point. Further, the extruder axis kinematics are handled separately than the X/Y/Z in Klipper. Also, remember that the real power in Klipper is that we can offload complex kinematics like bezier curves to a separate, more powerful microcontroller. If you really want to understand, the Kinematics document is extremely well written. And if you REALLY want to understand(i'm pretty sure Kevin has linked one or both of these)... take a look at these articles.) I worked in industrial controls for many years, so, keeping 20 ton machines from going into a literal death spiral has always been important for me. ;) You probably know this one from Physics... https://en.wikipedia.org/wiki/Hooke%27s_law -- but this one is a bit more advanced, and better describes what you're dealing with in terms of extrusion kinematics. https://en.wikipedia.org/wiki/Hagen%E2%80%93Poiseuille_equation

And just to reinforce what I am saying here: yes, PA is looking at your e-velocity. Lookahead is concerned with your printhead's acceleration. HOWEVER I think the part that may be missing, is this... and please @KevinOConnor correct me if I'm wrong... and I'm probably wrong on a few things. Pressure advance has its own lookahead method as well. This prevents globbing on things like corners when printing at high speeds with pressure advance.

[oderwat]

What parameter do I need to change to define the mm/s speed of the retraction part for the pressure advance execution?

My current tests of different pressure advance values do a visible and audible effect to the extruder but there is hardly any change in the print with many models I tried. For what I am currently testing it seems as if the retraction and "de-retraction" occurs with such a high speed and "just where the speed changes" that there is barely any effect on the actual print result. This is what I noticed before (and hence created this issue). It "does stuff" but it has no effect besides kicking my extruder extra hard to do some kinda 0,05 second long retraction/de-retraction on extrusion speed changes (look ahead is disabled btw).

I am currently coding a "gcwiz" dubbed application. This was used for special the test print below. It can dynamically test pressure advance and many other stuff. For pressure advance my first test is this one perimeter wall with two sections of different speeds. Basically what the linear advance test for Marlin does but stacking. Every 10 layers the pressure advance parameter gets changed. I was of the impression that there should be an effect on the "bulge" at the location where the speed changes. That it would be possible to have it smoothed because of pressure advance.

The following image shows a one one perimeter wall (here laying on the side). The lowest ten layers where printed with a linear advance setting of 0,00. Then it is increasing every ten layers by 0,05. There are total 200 layers, so it goes 20 times +0,05 which ends at 0.95 pressure advance.

EDIT: I did 0,02 steps changing every 20 layers first (0,02 up to 0,2). But that did not show any difference so I used the 0,05 steps for a more extreme result.

Here some output which shows what I do (for layer 100 in this fragment)

Switching to Layer 180 (35.900000 mm)
G1 Z35.900000
ok
G92 E0
ok
Setting Pressure Advance to 0.900000
SET_PRESSURE_ADVANCE ADVANCE=0.900000 ADVANCE_LOOKAHEAD_TIME=0.000000
ok
G1 X60 Y110 F600 E1.663007
// pressure_advance: 0.900000
// pressure_advance_lookahead_time: 0.000000
ok
G1 X10 Y110 F1200 E3.326014
ok
Switching to Layer 181 (36.100000 mm)
G1 Z36.100000
ok
G92 E0
ok
G1 X60 Y110 F1200 E1.663007
ok
G1 X110 Y110 F600 E3.326014
ok

As I wrote, the effect is very noticeable on the extruder steppe but there is nothing really happening in the printed model!

I just started a test where it will adjust pressure advance 20 x 0,25 steps so it will end with 5 mm .. lets see it that does anything noticeable.

P.S.: I actually started to write me some Python code which lets me easily code dynamic tests where I can change a lot of parameters programatically which are hard to dynamically change in a slicer and would need a lot of GCode post-processing if at all possible. This (alpha) app directly prints to Klipper without "anything" in between.

Examples of what I can do with it: Repeatable easy printer stress testing. Printing a cube with 4 one perimeter sides where all four sides use a different extrusion multiplier. Modifying temperature, speed and extrusion multiplier at the same time for a stringing test. Printing mathematical shapes. Basically programmable GCode "on the fly" creator. It's great fun after I solves some unexpected problems :)

[oderwat]

I must miss something! Even with values up to 5 mm the print does not change and the extruder just "clicks" shortly at the speed changes.

[mmone]

Did you try the "official" pressure advance tuning tips?

[oderwat]

@mmone Sure. With no effect either. Do you have tried it and got any effects?

[mmone]

No but I'm about to. Did you set the parameters in the config file or only via GCODE? If I read the code correctly, if the pressure advance parameters are not present in the config file modifying them via GCODE won't work.

[oderwat]

@mmone The documentation says that pressure advance need to be "in the config" but can be set to 0.0 to not use it. I read that as "if the line is not there, Klipper does not enable the feature". I did a long series of tests and read a lot about the feature and how it is supposed to work. I set it in gcode and in config and it also obviously does change how klipper works. It just works strange and has no noticeable effect for the printed object. I actually wonder if there is a bug in the code. I hope @KevinOConnor will find some time to read https://github.com/KevinOConnor/klipper/issues/361#issuecomment-394129007 and gives his thoughts about it.

[mmone]

I'm running a few testprints and will post pictures.

[KevinOConnor]

On Sat, Jun 02, 2018 at 06:48:24PM -0700, Hans Raaf wrote:

What parameter do I need to change to define the mm/s speed of the retraction part for the pressure advance execution?

Pressure advance is configured in units of "mm per mm/s". It's configured by either issuing a SET_PRESSURE_ADVANCE command or by setting the pressure_advance value in the config file.

I recommend you follow the guide at: https://github.com/KevinOConnor/klipper/blob/master/docs/Pressure_Advance.md

In particular, start tuning with pressure_advance=0.05 and slowly work your way up to 0.20 if needed. If you don't see a noticeable improvement at 0.20 then pressure advance is unlikely to improve results. (Technically, it's possible to go above 0.20 if one dramatically reduces max_accel, but the basic steps should be followed first.)

I don't doubt there are other ways to tune pressure_advance, but I recommend following the standard guidelines first. If those guidelines aren't working for you, please attach the full klipper log file (as described at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md ) along with some pictures of the standard testing square at PA=0.0, PA=0.05, etc.

-Kevin

[mmone]

• /docs/prints/square.stl sliced with Cura
• coreXY kinematics
• direct extruder
• pressure advance parameters set in config file
• slicer max speed 100mm/s

from top to bottom with lookahead time = 0.0 pressure advance: 0.0, 0.05, 0.1, 0.15, 0.2 A few of the walls are not completed on the last printed layer as I just aborted the prints.

[oderwat]

@mmone so what is your conclusion?

[mmone]

I was pretty happy with Klippers perfomance so far without it. I don't print with 100mm/s normally as you just can't produce nice prints at those speeds no matter what in my opinion. But It definitely changes something so I will keep it turned on with 0.15 for now and see how it performs in every day use.

[oderwat]

@KevinOConnor Would you please do me a favour and read more closely what I posted?

Pressure advance is configured in units of "mm per mm/s".

OK. So how is 0,02 mm at all related to mm/s ? What mm/s? If the 0,02 is a length and related to some speed one needs the speed. If the 0,02 is the speed (mm/s), where does the length come from.

But I did not even ask about the meaning of the parameter. I asked about how to change the speed the extruder uses for the retraction part and if that is supposed to be more than just some millisecond long click. On my system it basically just "clicks" slightly and there seems to be no difference in that with any pressure advance value I set.

I also did the standard guidelines days ago and "convinced" myself that "0,3" is a good value. But actually I could not really see any difference at all. Changing pressure advance does not really changed anything in my printing results. That is why I wrote code to make the tests easier and automatic. I also thought the one perimeter test needs to make changes visible. It does not. Why?

If your answer is "if it does not help from 0,05 to 0,2.. it will not help you" then this is a bit weak. I have made similar tests with linear_advance in Marlin and those do work in an easy to reproduce way.

[oderwat]

@mmone So you think it does change something. From the picture you sent I can't hardly see some change. When I compare that with the pictures from the guid https://github.com/KevinOConnor/klipper/blob/master/docs/Pressure_Advance.md there looks everything just the same in you picture.

BTW: It should also not be bound to printing with 100mm/s. The pressure in the nozzle builds up at any speed. So maybe I am thinking of that feature in a whole wrong way and it does not even do what I thought it should do.

[mmone]

The improvement is indeed minor but it is there, the pictures lie somewhat as you see the elephant-foot looking straight down. First layer was a little bit to thin. Also the PLA I used has a very low viscosity. A higher viscosity would probably create a more pronounced effect.

I would say the pictures in the docs show a signifikant improvement. The corner goes from having a buldge, to the two walls joining exactly with a radius at nozzle size, to the corner being clearly starved with a small chamfer.

I would describe the feature as follows. If you accelerate the head you need to spit out plastic at a faster rate. To do that you need to take into account that when you try to extrude faster the temperature of the melt sinks thus the viscosity of the melt increases and we need to build up pressure at the right amount in advance to extrude the required amount of material in the future. We are basically compensating for the impedance of the melting process as the hotend can't dump energy into the melt at an infinite rate.

*probably better to call it inductance not impedance.

[oderwat]

@mmone I think I do understand what it is...

Pressure advance is about the pressure which you need to put the filament through the nozzle. You need to "press a bit" until there is enough pressure build up that it comes out of the nozzle. So from "pressing" to "flowing" there is some time where nothing or "to few" filament comes out. For this to compensate pressure advance extrudes more filament in the begining of the move and stops before ending, to lower the pressure again. This happens again and again. The lookahead value tries to avoid strong de-restraction/retraction by testing if those happen close to each other and calculates how much change actually is needed. That can be near zero if the speed stays the same and the next line is continuing with the same speed. The main parameter for this is dependant of the springiness of the (optional) bowden-tube & filament (like PLA vs TPU) and is dependent on the heat and viscosity of the used filament.

What I don't understand is, why it seems that every value has the same effect on my printer, even extremes.

[mmone]

Yes basically. Thinking more about it the model of electrical inductance is probably a very good analog for whats happening. One probably obvious addition to above, we need to compensate for these effects when accelerating as well as decelerating. That again applies as well when thinking of the melt as current flowing through an inductor.

[KevinOConnor]

On Sun, Jun 03, 2018 at 09:31:25AM -0700, Hans Raaf wrote:

@mmone I think I do understand what it is...Pressure advance is about the pressure which you need to put the filament through the nozzle. You need to "press a bit" until there is enough pressure build up that it comes out of the nozzle. So from "pressing" to "flowing" there is some time where nothing or "to few" filament comes out. For this to compensate pressure advance extrudes more filament in the begging of the move and stops before ending. The parameter for this needs to consider the springiness of the tube/filament and is dependent on the heat and viscosity of the used filament.

Indeed. And the pressure_advance setting configures how much extra filament to push in at the start of a move in order to build that pressure. So, for example, a printing move at 100mm/s might result in an extruder velocity of 5mm/s. In this example, if pa=0.05 and the move started from 0mm/s then Klipper would push in .25mm of filament during acceleration to account for pressure (.05 * 5 == .25).

If you're not seeing good results, then post the log and pictures as previously described, and we'll take a look. Keep in mind, we know nothing about your printer (type, filament, software version, micro-controller, etc.) - without the log and pictures we have no way to meaningfully assist.

-Kevin

[oderwat]

@KevinOConnor I have the feeling that the ".25mm of filament during acceleration" part is what I wanted to focus about. You write "during acceleration" and I wonder how long this acceleration lasts and what speeds are involved (and yes.. 5mm/s is 5 mm per second. But thats a speed and not an acceleration).

I have a feeling as if the extruder can't follow and just kinda "clicks". This would explains why I can't hardly see anything happening. Basically that this part is "to strong / quick" whatever.

That also was the question I addressed to you: How do I change this acceleration (for my experiments)? Slower printing? Changing acceleration for XY? Basically: How can I make this part of the graph less steep so I can test if it is my hardware which cause the "nothing good happens".

I understand that you don't know about my printer details. Well I could expect that you know that I have an Creality3D Ender 3 which I use with Klipper, because I made the printer config PR :)

That it is modded with a titan extruder, the driver voltages are being watched and that I use a different hot end design and Capricorn bowden is probably not really helpful. The important part may be the titan extruder bowden setup. But I left that out, because I had the same results with the previous original extruder and this was part of why I changed to the titan for testing if that makes a difference.

But basically I try to ask the questions which I need to get answered to help myself. Checking out what gets send to the printer and maybe even following the code itself would not be unsolvable magic for me. I am doing hardware and software since 1982. Sometimes it is the language barrier, more often it is, that people are used to "stupid" questions being asked. I kinda know my stuff and be a quick learner anyway.

[hg42]

well, if you have an Ender this doesn't mean you couldn't have additional printers.

A bowden should usually benefit from pressure advance, but only if you see problems at all. If you print slow and the results are already perfect, you won't see improvements.

Long retractions and PA need a good extruder that has enough torque and doesn't skip, because both movements are faster than usual extrusion speeds (and acceleration).

I am not sure about a Titan extruder. The gear basically compensates the weaker motor (I think). From what I read about it, I got the feeling it might be a bit weak over all. In fact it was optimized to be light, not to be strong.

I got big improvements when I changed from a direct extruder to a geared extruder with a high torque motor and big gears and a ratio of about 5.

The hobbed bold also needs to dig deep into the filament to not skip in any situation. I found that this works best without a spring or tightened all the way. "Clicking" doesn't sound good.

[BlackStump]

I purchased a ender-3 recently and used your config @oderwat as it was no alterations ....what I found was I needed 6mm of retraction to stop stringing on the print ..to me that seems alot for a not so long bowden tube. I tried PA and to no real effect as it seemed the extruder acceleration/velocity was slow even tho I had fast 100/ms in the slicer for retraction. I will get to the point I needed to add this to the config to speed up retractions [extruder] max_extrude_only_velocity: 120 max_extrude_only_accel: 3000 I suspect that will have an effect on PA as well , tho not tested since making those changes but I can reduced retraction ....I am down to 4mm and can probably reduce it even more. On a side note the leadscrew was binding for me straight out of the box. you need to be able to twist the leadscrew with your fingers easily to raise or lower the Z axis

cheers

[oderwat]

The original firmware for the printer has 25 mm/s max speed for the extruder. I use a retraction length of 3 mm with 25 mm/s and have absolutely no stringing going on. After I changed geometry for the z-lead-screw my z axis is so smooth, when the motors are offline it even moves down itself when I push it down with a finger.

Just to make that clear: I have pretty much no problems with my prints. No binding, banding, layer shifts, clogging, adhesion problems or whatever. I just want to optimise a bit how seams and corners look by utilising PA.

[BlackStump]

fair enough.

[slipstreamliner]

I'm having a hard time following at this point. Is the issue that you aren't able to get pressure advance to cause any change in your prints? I just want to kind of clarify and clear to air here because I do not understand at this point... I also have multiple ender 3s, and other bowden driven printers... while they have required higher PA settings than direct setups to print at higher speeds, by following the guide for PA and going to a higher value for bowden I was able to see results immediately. You are asking about acceleration, which at this point you're simply getting into one of klipper's key functions. If you check the Kinematics document you'll find this:

snip->

It is also important to limit acceleration so that the stepper motors do not skip or put excessive stress on the machine. Klipper limits the torque on each stepper by virtue of limiting the acceleration of the print head. Enforcing acceleration at the print head naturally also limits the torque of the steppers that move the print head (the inverse is not always true).

Klipper implements constant acceleration. The key formula for constant acceleration is:

velocity(time) = start_velocity + accel*time

<=pins

Still, since I really don't know what you are asking... I have no idea what the implications would be of changing this, or how much alteration would be required as i've never looked at the structure of the movement hierarchy. Moving right along....

If you want to change your extruder's acceleration kinematics, you can find that formula in the same document and find a way to affect the code. You seem to understand the linkage... while you may have found something in your tests, which I'm guessing you are doing using something like simulavr? (This would also be helpful info, by the way.)

You must understand how complex pressure systems are, how difficult they are to model, and that people devote their entire lives to studying this phenomenon. mmone demonstrated quite well how pressure advance changes print quality... I've been able to tweak it same on all of my printers as well. So...

All I can guess at this point is that your machine is not mechanically tuned properly if you aren't seeing any changes from PA. How about some photos of the square? I would love to see PA worked on, but.... do you have any idea what to do to improve it? I mean at this point i really wouldn't know where to begin, but if you do... we're all kinda in this together. I know this has been basically

just me rambling but honestly I think you are really ahead of the curve as far as solving this problem... what do you propose?

~David

On Sun, Jun 3, 2018 at 11:05 PM, BlackStump notifications@github.com wrote:

fair enough.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/361#issuecomment-394222492, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQbxPlhnXqaHIOqx1ilHZe6RpWVk4ks5t5KP3gaJpZM4UPRD0 .

[hg42]

@oderwat I revisited the test you posted above (that with the first photo). I admit I have not looked close enough to the gcode.

I assume the code is more or less for one layer. A layer starts at X110, speed 1200 to X60, speed 600 to X10, spped 600 to X60, speed1200 to X110. For each line you reset E.

This looks like a working test.

Now, we don't know anything about timing and the linearity of your extruder or hotend.

First test: use 1200 on both sides, this should be seamless.

Second test: Do the same with 600 on both sides. Do both 9600 vs. 1200) walls look the same? You already see this on the test object in the photo. Both sides should look identical, same transparency, same thickness. On the photo the right side looks generally darker. The right side seems to be more transparent. This would mean less extrusion. However, the photo is very unsharp, and the camera doesn't look on the seam symmetrically. I would like to see two macro images of the seam at the bottom and the top. It should look exactly vertical, the background should be the same dark homogenious material.

Third test: use 300/600 instead of 600/1200 and compare both. Fourth test: use 1200/2400 and compare to both speed combinations above. May be the extruder/hotend combination is near a limit and test 4 makes this more visible.

However, the speeds are slow, so this shouldnkt be a problem for your ectruder/hotend combination. The photo shows some irregularities. There are darker layers (lower extrusion?), and you have some white spots (more extrusion). What about temperature? May be it's to low? perhaps there is some cold draft from a window or door etc.

About the clicking. If the hobbed bolt digs well enough into the filament, skipping usually generates grit that you can find in or around your extruder. You should clean it before a test, to remove older dust.

[oderwat]

@shoreliner I can't imagine how to be more clear about what I asks. I will print some squares for you later.

@hg42 Thank you so much for your time! I am already following your recommendations. Will post when I have done all the tests. There is for sure some air flow going on. I could close my enclosure for the tests. But I was not focused on getting nice layers for this test. What I thought is important, is to see the seam and how it changes (or not at all). Besides that. Printing 200 layers of a 0,4 mm line on top of each other is challenging. It will also change the look when I look at it and breath :)

It is one line printed vertically and it is hard to take meaningful photos with the iPhone. I may need to use a different camera. The seam is pretty identical from bottom to top for all of the PA values. And you are right: One side looks darker. I use the exact same amount of extrusion on both sides / speeds.

For the following tests I use 209 layers, starting with PA 0.0 and increasing this every 10 layers by 0.05. So it goes from 0.0 to 1.0. BTW: The printer reports the changed values. I also changed my code so my commentary outputs are all starting with "; ". I may implement, that I can export the GCode instead of sending it to the printer. This way you or somebody else could run the same test. Which would be very interesting.

Printed with 1200/1200 as expected there is no visible seam at all. Both sides are also 100% identical in thickness.

Printed with 600/600 also no visible seam at all.

The wall from 600/600 looks thicker when laying side by side to the 1200/1200 print.

But measuring it with a calliper shows they are pretty much the same thickness (with a grain of salt, because you can't hardly measure this reliable). But when I lay both prints side by side with the top layer facing, my finger can not feel a difference in thickness where they meet! I am pretty sure the different appearance has to do with the material reacting to different temperature/cooling. I may change filament later and redo some tests.

With the 300/600 print I already notice that there is nearly no (noticeable) retraction happening at low PA values. The extruder just changes speed in the middle of the line. For PA 0.4 and higher there is something happening for the extruder. But it happens super quick as if it does a retraction of 1-2 steps. But there are no noticeable changes in the print over the full length. It has a pretty much even seam again.

(TBC ... need to work for money)

[oderwat]

An (happy) update:

1. Getting those strange differences between the slower and faster part I compared my self generated GCode with S3D. This made me kinda happy because I calculated the same extrusion lengths for the same parameters! So my test program should work. I love my little gczip app :)

2. I changed the speeds for the test between the left and right part of the wall to 20 mm/s vs 100 mm/s. This gave me some noticeable changes for different PA values. But it also "broke" my titan (clone) extruder. Actually I could not get the tube staying connected so I (temporarily?) changed my extruder back to the original Ender 3 extruder setup. Then I re-run the same test and watch this:

So basically on one hand side there must be something wrong with that titan usage but there is also not a lot of effect when testing with low speed changes. From here on I will continue experimenting.

I already rewrote my gcwipz such that it can emit the gcode for something like the test wall on the picture. I am planning to create a more complicated shape for further tests.

What is seen in the image is what I was expecting from the beginning! Life is good!

Thank you for all your patience 👍 esp. @hg42 because if his post I came to the idea to make more extrem changes in speed for this test.

[hg42]

from my point of view, the titan extruder is designed to replace a standard direct drive extruder on something like a delta with a much lighter variant (reducing moving mass).

The motor is replaced by a much shorter version (pizza box!) and the lower torque is compensated by a gear box. So at the end the torque is similar.

For a bowden setup with a fixed extruder, I would choose a geared extruder (e.g. with 8mm hobbed bolt) and a standard nema 17. Where "standard" doesn't mean what cheap printers usually have.

Many printers come with weak 40Ncm motors, I would replace them with another model (~60Ncm).

When I did that for the direct extruder of my delta, I got much better prints. A geared extruder also works with the weaker model (5:1 = 5 x torque). Other benefits of the gear ratio are the motors running at higher speeds and the higher resolution.

[oderwat]

@hg42 I used the titan because for its possibility to transport flexible filaments more consistent. I am missing the possibilities my Anet A8 gave me with it's direct extruder. Using it with the bowden was trying to do a shortcut for medium TPU (not expecting something like FilaFlex to work). I also already have a sandwich stepper (pizza box :) and plan to build a direct extruder hot end and make it a exchange able part of my printer. I am not sure if I can use this stepper on the drivers of the 24V driven CR-10 board and maybe try it with a second board first and learn about using multiple MCU with Klipper at the same time.

I also have some bearings and mk8 + mk9 filament transport "gears". I don't know the correct names. I mean the ones with the concave area which transports the filament while a normal bearing is pressing against it. These are planned to be used with my current or another Nema17 (medium length) I have for experiments with those kind of geared extruders. I did not yet decide which of the designs I wanna try but have some in closer selection.

One other thing I had to debug was why my X stepper (and only this) made a buzzing noise when the head bed is active. It turned out that the MOSFET part on the board causes interferences in the driver for this stepper. When I change X and Y stepper. The sound moves to the other stepper. So I added a SSR into the formula and with the MOSFET of the board only driving the SSR, the noise is gone. Even when I use the same PSU for the bed heating still! I also used another PSU but that was actually not needed. There is still a very slight interference when the hot end is heated.

For testing if that effect is special to my board or a problem other CR-10 boards have, I will order an extra CR-10 board just to try that out. With that I also can try different steppers without risking to blow my motor drivers. I do have multiple other boards here (Rumba / Ramps) and plan to get a Duett WiFi or Smoothieboard or both in the next months.

I also still have some diamond hot ends here and may try to add two more extruders for a three filament mixing setup. I was also thinking about how to write software which can help with "mixing" colors by calculating the mix "in advance" based on extra input. This is part of why I am experimenting with generating GCode. Much to explore :)

For PA I just added a way to easily "zoom in" to a PA range such that one can get the best value. This picture is for:

; gcode made by gcwiz (c) 2018 Hans Raaf / GitHub: OderWat
G28
G1 Z5 F1500
; printing 10 sections for pa from 0.2000 to 0.6000 in steps of 0.0400
; first layer is 0.100 mm, other layers are 0.200 mm, total height is 40.000 mm
; changing pressure_advance every 4.000 mm (every 20 layers of a total of 200 layers)

Next I am going to add a 45 and 90 degree corner with and without speed change to this test routine and parametrise the remaining stuff (I already have layer height, nozzle, flow multiplier and more as variables which calculates the other stuff).

[slipstreamliner]

I am unsure if this was even discussed previously, but either way I missed it. Are you using S3D for all of your slicing? There have been issues reported in the past in which S3d generated gcode was causing "invalid speed" errors to be thrown while being processed by klippy. You can find this particular issue here: https://github.com/KevinOConnor/klipper/issues/173 -- Now, I've also seen people have absolutely no problem printing at high speeds with Klipper printing S3D sliced models. Anyways, perhaps when you slice your squares try not only different PA settings, but different slicers. I'm not sure if I'd use a proprietary slicer to perform anything I'd consider experimental, but it can't hurt. Maybe throw in Ideamaker for the hell of it.

On Mon, Jun 4, 2018 at 4:55 PM, Hans Raaf notifications@github.com wrote:

@hg42 https://github.com/hg42 I used the titan because for its possibility to transport flexible filaments more consistent. I am missing the possibilities my Anet A8 gave me with it's direct extruder. Using it with the bowden was trying to do a shortcut for medium TPU (not expecting simething like filaflex to work). I also already have a sandwich stepper (pizza box :) and plan to build an direct extruder hot end and make it a exchange able part of my printer. I am not sure if I can use this stepper on the drivers of the 24V driven CR-10 board and maybe try it with a second board first and learn about using multiple MCU with Klipper at the same time.

I also have some bearings and mk8 + mk9 filament transport "gears". I don't know the correct names. I mean the ones with the concave area which transports the filament while a normal bearing is pressing against it. These are planned to be used with my current or another Nema17 (medium length) I have for experiments with those kind of geared extruders. I did not yet decide which of the designs I wanna try but have some in closer selection.

One other thing I had to debug was why my X stepper (and only this) made a buzzing noise when the head bed is active. It turned out that the MOSFET part on the board causes interferences in the driver for this stepper. When I change X and Y stepper. The sound moves to the other stepper. So I added a SSR into the formula and with the MOSFET of the board only driving the SSR, the noise is gone. Even when I use the same PSU for the bed heating still! I also used another PSU but that was actually not needed. There is still a very slight interference when the hot end is heated.

For testing it that effect is special to my board or a problem other CR-10 boards have, I will order an extra CR-10 board just to try that out. With that I also can try different steppers without risking to blow my motor drivers. I do have multiple other boards here (Rumba / Ramps) and plan to get a detla or smoothie or both in the next months.

I also still have some diamond hot ends here and may try to add two more extruders for a three filament mixing setup. I was also thinking about how to write software which can help with "mixing" colors by calculating the mix "in advance" based on extra input. This is part of why I am experimenting with generating GCode. Much to explore :)

For PA I just added a way to easily "zoom in" to a PA range such that one can get the best value. This picture is for:

; gcode made by gcwiz (c) 2018 Hans Raaf / GitHub: OderWat G28 G1 Z5 F1500 ; printing 10 sections for pa from 0.2000 to 0.6000 in steps of 0.0400 ; first layer is 0.100 mm, other layers are 0.200 mm, total height is 40.000 mm ; changing pressure_advance every 4.000 mm (every 20 layers of a total of 200 layers)

[image: image] https://user-images.githubusercontent.com/719156/40941034-eb993be4-6849-11e8-92d6-718a5126425e.png

Next I am going to add a 45 and 90 degree corner with and without speed change to this test routine and parametrise the remaining stuff (I already have layer height, nozzle, flow multiplier and more as variables which calculates the other stuff).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/361#issuecomment-394496214, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQch-bfibvaV5Nq3YJ3D0tEJ8WlmDks5t5Z61gaJpZM4UPRD0 .

[oderwat]

@shoreliner I wrote my own program to create these tests and they drive the printer directly or generate actual GCode. I don't care much about the squares actually. I think they need to long to print.

My original problem is also already solved. The speeds for my test code where to low and my titan extruder sucked.

Besides that I am using S3D for my normal prints and got no errors with Klipper. I can imagine that you can generate GCode which will let Klipper error out. I actually had that happen with some hand generated GCode I used in a start script for over a year with Marlin. But Marlin just puts constrains onto the print, while Klipper stops with an error. I am not sure if I like the way Klipper handles this, but from a programmers point of view I think it is OK. I live the "warnings are bad and errors need to be solved" style of programming for my whole life.

[oderwat]

Before I close this issue I want to show what it actually all was about in the end. And why I didn't rest until I got my problems solved to continue working on my original idea:

Here three pictures of what my pressure advance test routine in my upcoming gcwiz tool produces, when I tell it to create a test for a 40 mm height wall with the range from 0.0 to 0.6 as pressure advance values. With the additional parameters of 0.4 mm nozzle, 0.4 mm line width, 1.0 extrusion multiplier, hot end on 210C, bed on 50C, 90% cooling fan (starting at the second layer), 0.2mm layer height with a first layer of 0.1 mm.

My app can also create a classic GCode file which can be printed with any host. The file generated for this test is here

A preview of how the GCode is previewd in S3D is here:

Sadly one can't print this GCode from S3D. It seems it stops at the Klipper specific commands. I didn't search for a workaround and don't know if something like that exists.

Using the GCode in OctoPrint does work and creates the same result as when gcwiz is directly driving the printer over the Klipper printer port (or USB Serial for me).

Printing the whole test "model" needs about 23 minutes, uses about 1.42m filament and needs no human interaction at all. It is also very easy to reason about and in my opinion the quickest way to find a good pressure advance value without even knowing what to do exactly.

One could cut the height of the test in half and still got a good result in about 12 minutes. Compare that to the manual work printing "squares", setting PA values and interpreting the results.

I may design a test for the lookahead value in the future. Not sure what is needed to test it yet.

[slipstreamliner]

You know, I'm trying to offer suggestions to you here that are in line with what Kevin has asked for as far as PA tweaking, and for some reason I sense you feel I am patronizing you or something. Let me assure you, I am not. I simply had a hard time understand the actual problem you were having; the photos you posted recently along with the description of gcwiz was very helpful. I only respond here to help.

That said,

We use that calibration square stl because it is a common model that we can use to relate, not just for ourselves, but for others in the community. Could it be an improved process? I'm sure, this is an ongoing project. As I previously had mentioned, S3D and Klipper have been previously documented as having some issues... if you check the link I put above, you'll see S3d generated some quite odd commands in some scenarios that caused those errors to be thrown.

Additionally, as It seems like you have quite a lot of experience in this realm, so I would love to see what you develop for lookahead var testing. I'd only like to assist you in this. I just hope that you have read the documents we've linked. You will notice in fact that one of the To-Do items is to finish/further develop the simulation system:

"Testing features

Complete the host based simulator. It's possible to compile the micro-controller for a "host simulator", but that simulator doesn't do anything currently. It would be useful to expand the code to support more error checks, kinematic simulations, and improved logging"

I can be of particular assistance here with the mathematics in question if you'd like to tackle this item.

[oderwat]

@shoreliner I don't feel like you are patronising me. I just think you didn't read closely what I wrote or I am not able to write it understandable enough.

You ask me in your current post to check the S3D issue #173 you posted yesterday. I already did this yesterday and even contributed to this thread. I could give a suggestion for a work around to the actual problem.

I also think that the problem from #173 is actually a Klipper problem and not a S3D one, because Klipper should try to be "as good as other firmware" even if that means it create "warnings" and interpret stuff. I already know that @KevinOConnor has another opinion and that is fine. It is his project. But I think he is to narrow minded in that respect. I am long time developer myself and understand why he thinks like that. I would have a hard time too. But in the end I may had convinced myself that I would better accept "bad" input, generate a warning and continue printing. Because that is what a user expects. I usually make software for users to use and not to render two programs (S3D and Klipper) unusable.

I don't want to use the calibration square, because it is wasting material, lasts a long time, needs a manual change of the parameters and the interpretation of the result is hard for me. But of course you can do what you want to test your printer.

For comparing results with other firmware I would prefer more complex models. I hate all these cubes, squares and benchy people print. And always there is the next person which asks how to change the steps because his 20x20x20 cube is 1 mm off. People need clear models where you can directly see if something is good or bad.

I don't feel like I have a lot of experience and I am do bad errors all the time. I have read all the docs multiple times but I eventually will read the code. Code is my friend :)

[oderwat]

BTW: My question is still not answered. How to change the timing of the red circled part in the graph I copied from the documentation. I mean like "where in the code" or "what parameter" needs to be changed to get different acceleration for this part. I understood that the "max" of it is defined by PA. I asked what defines the "duration" for this part.

[hg42]

gcode generator

@oderwat I like your approach to the problem by using a gcode generator. I did this myself before, when solving other problems and I like how I get much more control and complete independence from slicers.

I think using variation of parameters over geometry (e.g. height) is a good, fast and reproducible way for calibrating (see temperature towers). The only problem, why this is still a tool for experts is because you usually cannot use a slicer for this (without using advanced features like specifying parameter changes for layers) and directly distributing gcode to users doesn't work well, because the init sequences, position limits, speeds, accelerations etc. would not fit to everyone.

red circled part

(without looking at the code) Because the volume per length is a fixed relation extruder acceleration is always bound to the (xyz-)movement acceleration. The PA algorithm only changes the extra volume per length depending on the extruder speed: extra_filament = pressure_advance_coefficient * extruder_velocity So the acceleration is fully defined by these formulas.

pictures

I am not sure what I am supposed to see there. Apparently,

• even with PA=0 the print looks good.
• you are getting a seam when printing a line with a sudden speed change in the middle and this doesn't change much (or at all?) with PA (besides making everything worse above 0.3). I agree, this indicates a non perfect pressure algorithm (the formula may indeed be too simple for this case), but I think, the test doesn't represent a realistic case, because no one will ever suddenly change the speed in the middle of a line. Instead the algorithm aims at corners and ends.

[oderwat]

@hg42

1. "Everybody" will be able to use gcwiz for this and other stuff, as long as he can run the code and has either a gcode or serial target. You don't need a slicer. Just run the program or use the GCode somebody generated. The one I posted will actually work for a lot of printers. One may just change the temperature.

2. If that was not clear: I am going to release gcwiz. I may also release a black box Klipper RasPi unit and/or prepared image, which works by putting it between the printer and a computer without any special software setup needed by the user, as long as the printer is in an online database. But thats "future" and depends on how stable I get everything. Currently it works already pretty well.

3. This can't be the complete formula as it is just linear and the graph isn't showing a linear curve. The graph does explicitly say "extruder velocity" on the y axis. So it does push more for some time in the beginning and at the end it de-accelerates and even crosses the x axis which means it has a negative velocity. The extra amount of filament is not added linear over the whole time. I actually wonder over the "extra_filament" too. There should not be any extra filament as it stops pushing before the end (much like coasting). It just changes the distribution of the pressure. Everything else actually would not make sense to me at all. I don't think that I have understood that wrong. But I will look at the code when I find time for that.

4. Pictures are hard. You could just print one of those tests yourself and see what the seam really does. Check this picture:

BTW: The speed change in the middle of the wall is the actual test. It is not important that this is what happens in reality. It is important that it show what happens without much side effects. But I also added the corners with and without speed changes to make sure the effects are similar. While you also could say a single extrusion line is not "real" it is basically the foundation for the print. If your printer can do that very well, it will print other stuff very well. Of course there can be other effects like vibration and losing steps when the printer head mass inertia comes in the way. But that would be other tests. My goal is to create isolated tests which all in themselves have to be "good" for a overall good print result.

[slipstreamliner]

You know, after looking ahead at that prior S3D thread and being taken aback with the way some of the entitlement issues some individuals have... I wanted to respond with something that contained vastly more words than this. However, instead... man, this is a fairly small open source project that for most of us is a fresh change in architecture; it also produces great prints with a properly configured printer and slicer. S3D is closed in every way; there's no developer API, there's no good information on S3D's gcode generation routines, there's never been so much as a whisper of divulging any helpful information to firmware developers. Just the opposite in fact, S3D has went ONLY to printer OEMs in an effort to embed their software in rebranded versions... and I hear you saying, "But you could just generate a warning instead of throwing an error....". Of course you could, but given the experimental nature of this project and the fact that it controls a machine that spews hot plastic, I think its safe to say that we don't want to handle issues that could result in damage to someone's printer, hurting themselves, etc when the alternative is that they have to re-slice the print or use another slicer. Anyways. I wish you luck, but I don't have anything positive I can offer here at this point.

~David

On Tue, Jun 5, 2018 at 1:23 PM, Hans Raaf notifications@github.com wrote:

I actually wonder if I need to do a little modification for the gcode as the start and stop point for the mid part and the edges are actually the same coordinates currently. I think it would be more correct if it starts and stops halve the nozzle size before the actual coordinates. this would need a move without extrusion for positioning between the stop point and the next starting point. I think I saw something like that in S3D gcodes. This would then affect the seam considerably and the current "flat" point would be earlier. It would also probably make the seam go away or much smaller for the slower prints I did before.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/361#issuecomment-394792328, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQQx45IDEz8yr9GJCwp_JmjjmIxaSks5t5r52gaJpZM4UPRD0 .

[oderwat]

@shoreliner I don't know what this has to do with what I am trying to do here. Why are you bringing up the S3D thread here? I lover Klipper for it's great print results and try to contribute stuff. But everything I do is put down as it seems? I tell you what: S3D is a great working slicer and gave me very good results over the years. I don't regret the money I spent there. I do start to regret that I am contributing money, my time and enthusiasm here. I was running around telling everybody and his cat to try out Klipper for some time now. I guess I need to stop that.

There is still not an answer to what I was asking. No response to what I am demonstrating. All I got is you preaching to me about S3D and what they didn't do for firmware developers? I am myself struggling with them. I just today wrote again with their support for getting more possibilities to use Klipper with their software. Do they care? Maybe not. Do I care.. maybe not anymore.

But one thing I do wonder: What do you wish me luck for?

[oderwat]

@shoreliner Just one more thing: If you have nothing positive to offer... maybe just stay away from the keyboard. I am really upset about your way you handle me. This is ridiculous!

[slipstreamliner]

Just one more thing Hans: shrug

On Tue, Jun 5, 2018 at 6:53 PM, Hans Raaf notifications@github.com wrote:

@shoreliner https://github.com/shoreliner Just one more thing: If you have nothing positive to offer... maybe just stay away from the keyboard. I am really upset about your way you handle me. This is ridiculous!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/361#issuecomment-394885788, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQfwM8b7E0E3X4pmbi27svBEID9Q5ks5t5wv9gaJpZM4UPRD0 .

[BlackStump]

@oderwat I think your PA test is great, easy to use much better and easier to see then printing squares and could not agree more that squares are just a waste of plastic. Any other tests that you formulate that are simple and easy to determine results I for one would be happy to try. keep up the good work.

[BlackStump]

@oderwat I have already mentioned I have a un-altered ender-3. I have printed your PA test as is and the bulge smooths out around 0.6 for me which is not what you are seeing in your picture so I altered your gcode and changed the PA to 0.5 steps instead of 0.3 so I max out at 1.0
I wanted to see when too much was too much and for me that is around 0.7 so it seems to me hotends and bowden tubes must have a effect on the results. I will at some stage change over to a E3D hotend and retest to compare against the short little stock hotend. sorry my camera is not good enough to show the effect on the print.

[KevinOConnor]

On Tue, Jun 05, 2018 at 03:50:00PM -0700, Hans Raaf wrote:

There is still not an answer to what I was asking. No response to what I am demonstrating.

Hi Hans,

Your enthusiasm for Klipper is appreciated.

It is not clear to me which question you feel is unanswered. I believe both @hg42 and I addressed your acceleration question earlier in this thread (in brief, extruder acceleration is directly tied to move acceleration, move acceleration is controlled by max_accel).

It's also not clear to me what you are trying to demonstrate. You've posted a number of pictures, but I personally have no basis of comparison for those pictures. So, if by chance, you are looking for a response from me, then know that I do not have any feedback to provide.

If you'd like my feedback, I recommend you run through the standard pressure advance tuning steps, attach a klipper log file from at least one print, and post some pictures of the standard tuning squares. That will give myself (and others) a basis of comparison with which to evaluate alternative tuning processes. If you do not wish to take these steps, then that is fine. I understand that you have your own goals and only you know how best to allocate your time and resources. Please keep in mind though, that I too must allocate my time and resources. If you decide it is not worthwhile to follow these steps, please don't expect my feedback, or feel that you need my feedback.

Cheers, -Kevin