LA 1.5 feedback

[wavexx]

For the MK3, after some initial testing, I determined the following factors while using the BMG extruder. Likely the values should be very close for the original extruder as well.

PLA (unbranded): K=0.06
PETG (T-glase): K=0.08

There are implementation differences between the original Marlin and this LA1.5 for the MK3. Factors should't change that much if at all, but it would be helpful to point at any difference.

[thess]

Thanks for the work! I'm looking forward to testing this.... I have some other ISR changes I want to merge with this which provides preemptive threading and more consistent handling of serial comms.

[wavexx]

I know the original ISR had extra checks for the serial. This was done in several parts while doing e-steps. Since I added several constraints for the number of e-steps and minimal rescheduling time, I hope this won't be a problem any longer.

As written before, the isr is quite consistently running at <50µs now, with or without LA.

[wavexx]

After doing some larger prints I noticed that the filament compression/decompression steps are not perfectly balanced. This is barely visible in the k-factor test prints, but the blob at the first mark is not as big as what it should be compared to it's respective gap during deceleration.

[Sebastianv650]

After doing some larger prints I noticed that the filament compression/decompression steps are not perfectly balanced.

Do you mean they are more unbalanced compared to the "original" LA implementation or in general?
There is a small difference for best acceleration K value and deceleration one, most times also visible on the test pattern. That's known, but up to now I have no real idea how to compensate for that in an elegant way.

I will have to look at your ISR smoothing changes when I find time :)

[wavexx]

Didn't know this was a known effect. Admittedly, I never went through patterns looking explicitly for this sort of stuff so I didn't pay close attention before.

My though was this due to how I skip some advance steps in order to limit instantaneous changes, resulting in an effective speed which is slightly lower than what it should ideally be. The compression is still accounted for, but not soon enough. I don't know if this is significant, but I'll try have a look at what happens if I force the speed on the other side of the spectrum (by always being at least faster than ideal).

[wavexx]

I decided to try give it a go by spending more time calculating a perfect distribution or advance steps by keeping track of the accumulated error.

Simulating an acceleration loop, you get something like this:

Pardon the noise, but aside from some debugging metrics, the vertical full-length yellow lines are the acceleration stepper pulses with the dark green line being the original speed. The dots are the newly inserted advance steps, with the light-green line being the effective resulting speed.

Of course, we cannot perform an ideal shift without changing the underlying acceleration curve, but it's close enough. In fact, I can barely hear any difference now with or without the advance steps, and by choosing the initial error term correctly the initial e-jerk is reduced as well. I'm waaay more happy with this, to the point that I'm going to replace the current method.

The resulting print changes quite a bit though. I mentioned that the initial acceleration phase seemed to be skewed, well, not any longer:

This is a ramp from 0 to 0.2 in 0.02 steps, going from right to left, focusing on the first acceleration mark. You can clearly see that after the LA steps, in almost all rages, the line still seems to be partially starved.

Quite tired now to draw conclusions. Leaving this as "food for thought".

[wavexx]

Turns out it was just interger overflow ;)

I now committed an update that improves, as described above, the way the advance steps are scheduled. To summarize, the biggest difference is that in the main isr we calculate the number of la-steps to deliver within the next and distribute them equally, carrying over the rate error. This results in a significant reduction in instantaneous speed changes a much smoother operation. By tweaking the initial term we can also err by defect on the first few pulses, which also reduces the effective e-jerk.

Although the overall computation is roughly the same, stuff that was done in the advance ticks now runs in the main isr, stalling up to ~54µs. But I do believe that there's margin to improve.

[wavexx]

For wider testing, here's two precompiled versions:

MK3: https://www.thregr.org/~wavexx/tmp/la15/FW371-201905220044-1_75mm_MK3-EINSy10a-E3Dv6full-EN_ONLY.hex
MK3S: https://www.thregr.org/~wavexx/tmp/la15/FW371-201905220044-1_75mm_MK3S-EINSy10a-E3Dv6full-EN_ONLY.hex

I can only test the MK3 currently, but the MK3S should be similar enough.

Things to look for:

• Perform a k-factor calibration
• the default extruder jerk for the mk3 is low, start by ramping it up slowly and see what's the limit in terms of speed and perceived quality (and post the results please). The k-factor pattern is a good test piece for this as well (although please take the time to fill-in all the parameters correctly!)
• Once the new K factor is found, you'll have to replace the value in the Filament -> custom gcode settings.

You can actually put both values for convenience:

• The new (LA1.5) factor first: M900 K0.*
• The old (LA1) second: M900 K30

The new firmware will effectively ignore the second, while the old will overwrite the first.

• One thing that I'm very interested in is the serial operation. I'd like to know if there are issues (such as octoprint disconnecting) when printing complex pieces over the serial. I didn't like the old placement of the serial checks and, if necessary, I'd like to carefully place one square in the middle of the isr.

As usual, consider this experimental with all the caveats.

[Sebastianv650]

Should this also run on other MK* (2, 2.5) with the variant files or is there some backward incompatibility in the MK3 FW?

[wavexx]

On Wed, May 22 2019, Sebastianv650 wrote: Should this also run on other MK* (2, 2.5) with the variant files or is there some backward incompatibility in the MK3 FW?

I'm not fully sure how Prusa builds for the MK2, but looking at recent commits and the official changelog it does seem that's exactly the same code base (I was under the impression that the MK3 branch was for the MK3 only). There's nothing specific to the TMC drivers that I've changed, the filament sensor support is still optional and it does build fine. There are no delays when pulsing e-steps, which is fine for the TMC drivers, but other drivers might actually require some. But the original code didn't have any anyway, so I suspect it's still fine for the MK2.

[vertigo235]

@wavexx if I wanted to compile my own firmware should I use the MK3_LA15 or your MK3 branch, it looks like you have merged your MK3_LA15 into the MK3 branch now. I have automated builds for a bunch of community configs here https://github.com/vertigo235/Build-Prusa-LA-15/releases and a few folks have tested, even on an MK2.5S

[vertigo235]

Also the Prusa MK3 branch is actually for both MK25(S) and MK3(S), MK2 has it's own branch.

[wavexx]

On Wed, May 22 2019, Josh Jones wrote: @wavexx if I wanted to compile my own firmware should I use the MK3_LA15 or your MK3 branch, it looks like you have merged your MK3_LA15 into the MK3 branch now. I have automated builds for a bunch of community configs here

MK3 it's the firmware that I'm using, it has LA15, but also includes also a number of other fixes I'm trying to push to Prusa (see prusa3d#1768 for one example). MK3_LA15 is vanilla MK3 + LA15. For testing LA15 this is the one I recommend to make debugging easier.

https://github.com/vertigo235/Build-Prusa-LA-15/releases and a few folks have tested, even on an MK2.5S

I'll check this out later. Is the commit id embedded in the build? This is something that I would love PF-build.sh to do (ping @3d-gussner). Put the output of `git describe` somewhere into the build, so that when you go to the LCD -> Support you see the exact commit info you need to reproduce the issue. If there's a build bot and people start testing, getting accurate version info is important. Right now the only useful part is the date and time. The commit number is meaningless except for official builds.

[vertigo235]

For my automated build I replace the commit number with EPOCH time , I'll rebase on your MK3 branch and build that.

[vertigo235]

Actually I'm still not sure which branch you prefer, hah, You said MK3 branch, then you said the MK3_LA15

I have an automated build process that uses PF-Build.sh to build multiple variants in the variant folder.

[vertigo235]

I tried the build pipeline on your MK3 branch and it looks like the build failed on the MK3S variant.

https://drone.blubeacon.com/vertigo235/Build-Prusa-LA-15/16/1/3

[wavexx]

On Wed, May 22 2019, Josh Jones wrote: I tried the build pipeline on your MK3 branch and it looks like the build failed on the MK3S variant. https://drone.blubeacon.com/vertigo235/Build-Prusa-LA-15/16/1/3

I'll check this out, but stick to MK3_LA15 to help testing LA15 alone. Otherwise there might be multiple issues building up at the same time.

[3d-gussner]

I'll check this out later. Is the commit id embedded in the build? This is something that I would love PF-build.sh to do (ping @3d-gussner). Put the output of git describe somewhere into the build, so that when you go to the LCD -> Support you see the exact commit info you need to reproduce the issue. If there's a build bot and people start testing, getting accurate version info is important. Right now the only useful part is the date and time. The commit number is meaningless except for official builds.

You can add "git describe" to the PF-build.sh so the script will add "FW_GIT_COMMIT" to the Configuration.h and add this additional info to be shown via LCD

• ultralcd.cpp behind

  MENU_ITEM_BACK_P(PSTR("Firmware:"));
  MENU_ITEM_BACK_P(PSTR(" " FW_VERSION_FULL));

something like
MENU_ITEM_BACK_P(PSTR(" " FW_GIT_COMMIT));

To show it via serial communication

• Marlin_main.cpp behind

    case 115: // M115
      if (code_seen('V')) {
          // Report the Prusa version number.
          SERIAL_PROTOCOLLNRPGM(FW_VERSION_STR_P());

SERIAL_ECHOPGM("Firmware git commit number:");
          SERIAL_ECHOPGM(FW_GIT_COMMIT);

Only issue i can see is that the git describe value could be longer than 20 chars and show strange things on the LCD.
v3.7.1-65-gd570bbe9 is already 19 chars long

Like the idea but i would not add use it for the GOLD version.

[wavexx]

Only issue i can see is that the git describe value could be longer than 20 chars and show strange things on the LCD.
v3.7.1-65-gd570bbe9 is already 19 chars long

Not perfect in every condition, but IMHO good enough.

Like the idea but i would not add use it for the GOLD version.

There's also FW_REPOSITORY which is enabled when the release is not GOLD.
This could be similarly set to git config --get remote.origin.url.

[wavexx]

Prusa fixed some of the menus issues. I would rebase the current branch on top of the new firmware, unless somebody started to develop on top of it. @thess I didn't have a chance to look at your code yet :(

[wavexx]

Aside from the jerk, the maximum extruder feedrate also needs to be respected, as it does go above the nominal speed at the end of acceleration move or at the beginning of a deceleration.

[Sebastianv650]

@wavexx

Aside from the jerk, the maximum extruder feedrate also needs to be respected, as it does go above the nominal speed at the end of acceleration move or at the beginning of a deceleration.

Yes and no. As we are checking for jerk, that should cover also the max. feed rate. The max. feed rate will always be >> jerk, else the jerk speed makes no sense. Then whats left is the extruder print speed, as the extrusion speed will be LA speed + extrusion print speed. But as the extrusion speed for printing is incredible low, it should be safe to ignore that. Keep in mind that the max. feed rates are not to be taken exakt on any printer I know of. It's more a "sounds reasonable" value.

[wavexx]

On Fri, May 24 2019, Sebastianv650 wrote: But as the extrusion speed for printing is incredible low, it should be safe to ignore that. Keep in mind that the max. feed rates are not to be taken exakt on any printer I know of. It's more a "sounds reasonable" value.

That's a good point. As I was experimenting with filament ramming with the BMG 3:1 extruder and a 0.9' stepper I *did* manage to run into overstepping, which prompted me to find exactly the maximum feed rate I could achieve. But as you say, such speeds are never reached in a normal setup. (although if you combine a fast core xy bowden printer with a large vocano nozzle things start to get tight...). Meanwhile I did manage to create a reproducible test case that causes the serial to loose sync. I'm going to tackle that next.

[wavexx]

@vertigo235 do you think we could make the standard variant builds publicly linked somewhere?
After further testing and tweaks today I don't think there's much missing.

[vertigo235]

Yes we can do that as soon as I get a build together. The latest with live K adjust was too large. I was basing on 3.7.1 to avoid any bugs in the prusa head.

[wavexx]

Rats. You can try to revert the live K commit to see if it would otherwise fit. If it does, I can make it conditional for now.

[vertigo235]

I had to step away again but I’ll try some things in a bit.

[wavexx]

On Sat, May 25 2019, Josh Jones wrote: I had to step away again but I’ll try some things in a bit.

I should be able to reorganize some calls to save some extra space, but I need to test the performance impact. I'll try tomorrow.

[leptun]

I just tried LA1.5 on my MK3 and the results are as follows:
Did a K factor calibration test and ended up somewhere between 0.04 and 0.06, so I chose 0.05 as my K factor. Also increased the extruder jerk to 4mm/s.

The tests I did were using Colorfabb Economy PLA.

I can see drastic improvements on my fast speed profile where I had quite some underextrusion at the walls. Now it just seems I have some ringing and lack some cooling.
I'll also test Colorfabb Economy PETG, Prusa PETG, DevilDesign TPU and maybe even some Polymaker PC-MAX when I have more time.

These changes look very promising and I hope Prusa will merge them in the main branch soon.

[jryer]

Reporting an issue I'm having with a firmware found here:
https://github.com/vertigo235/Build-Prusa-LA-15/releases/tag/MK3_LA_190528_01

specifically:
FW371-Build1559064897-1_75mm_MK3-BMG-16-EINSy10a-E3Dv6full.hex

Source code: https://github.com/vertigo235/Build-Prusa-LA-15/commits/MK3_LA_190528_01

I am printing a large circular object. On the second layer, when the printer gets to roughly the center of the circle it pauses, starts up again, and then crashes into the edge of the printer. It resumes with a pretty significant layer shift. This is running in stealth mode so crash detection is disabled.

Video
Gcode
Printer Settings

It is reproducible for me and happens at roughly the same spot every time

[wavexx]

On Fri, May 31 2019, jryer wrote: I am printing a large circular object. On the second layer, when the printer gets to roughly the center of the circle it pauses, starts up again, and then crashes into the edge of the printer. It resumes with a pretty significant layer shift. This is running in stealth mode so crash detection is disabled.

Thanks a lot for the report. I think there's everything I need to try this. From the description yesterday I though this could have been an issue with the filament sensor, but looks more like an overflow (I can barely see the extruder moving before XY motion is resumed). I'm finishing a print now, I'll have a look ASAP.

[wavexx]

On Fri, May 31 2019, Yuri D'Elia wrote: > I am printing a large circular object. On the second layer, when the > printer gets to roughly the center of the circle it pauses, starts up > again, and then crashes into the edge of the printer. It resumes with > a pretty significant layer shift. This is running in stealth mode so > crash detection is disabled.

Just to be sure, you have the default 1.8' stepper on the BMG?

[jryer]

Correct. Esteps set to 415

…

On Fri, May 31, 2019, 8:29 AM wavexx ***@***.***> wrote: On Fri, May 31 2019, Yuri D'Elia wrote: >> I am printing a large circular object. On the second layer, when the >> printer gets to roughly the center of the circle it pauses, starts up >> again, and then crashes into the edge of the printer. It resumes with >> a pretty significant layer shift. This is running in stealth mode so >> crash detection is disabled. Just to be sure, you have the default 1.8' stepper on the BMG? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AEEBCLD5GOBNHEETRVGH3GDPYER3ZA5CNFSM4HN4OO62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVG7UA#issuecomment-497709008>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEEBCLE6M3ZC4FRIJAWT7HTPYER3ZANCNFSM4HN4OO6Q> .

[wavexx]

As an update, I managed to reproduce the issue. It's caused by the
optical filament sensor in the MK3 being confused by LA. Turning off the
filament sensor in the menu will fix this (for now).

But there is also an underlying bug in the MK3 filament sensor recovery code which is uncovered by this issue, not related to LA at all. I didn't look deep, but it looks like that after trying to move the filament, it reschedules the entire last move. As you can see in the video, it shoots in the same direction/speed/length as the last fill but from the current position.

The next move will partially fix that as is seems that the stepper state is not broken, but since the carriage crashes into the frame the absolute position is now incorrect, causing a layer shift.

This is less than "ideal" to say the least.
I'll need to see if there is an easy way to report this to Prusa (they should be already aware of this).

[wavexx]

FYI, this should be fixed with the latest commit. @vertigo235 has already made a new build.
Please test with the filament sensor on.

[eowindel]

i'm running the firmware since 13 days and update each time Josh make a build. I don't have issue, the runout filament trigger once in 150hours of prints, and i was able to resume. I will try the latest commit. I'm on a MK3 bear frame with skelestruder and 0.9° LDO pancake.

[wavexx]

How did you know there was only one? Were you there to watch it?

In my tests the sensor would always recover, but leave a molten spot on the surface while the the optical sensor is checked. The "fail stats" includes a filament runout counter, but it's just for cases where the filament cannot be detected any longer (likely a true runout).

I'm temporarily using this change:

127dfe6

which includes a counter of "soft" fails in the third row:

I'm using this together with tighter error margins:

3760dee

in order to test how reliable is it. Since I've added the counter I didn't have any false triggers, but I've only used regular PLA with it.

[wavexx]

@vertigo235 could you do another rebuild with the latest changes? It's mostly cleanup, but unless something happens, I believe this is what I'm going to push to Prusa during the week.

[vertigo235]

Yes I'll build tonight or in the morning.

[wavexx]

Has anybody ever experienced a power failure + recovery on the MK3?
I suspect the LA K factor is never restored in such cases (but it should probably be..?)

[wavexx]

Well, it now it's corretly restored.

[wavexx]

@jryer I was able to find an easier way/pattern to trigger the random runaway that you had when testing for the power crash and recovery today. Which is good news, I guess ;).

[jryer]

Cool! If you want to share the gcode I can test it when I have some printer free time. Probably wont be until tomorrow.

[wavexx]

It's not that easy, you need to trigger a failure through the LCD as the printer is going.

Sadly this seems to be a pre-existing issue which I can get even without LA. If the current plan is aborted, discarded and immediately resumed with the first move being an extrusion then hell ensues.

However I suspect it's the internal pause/resume function in itself which is broken. Searching through Prusa's issues I've found multiple reports of layer shifts just after resuming. The filament check indirectly make this happen internally.

[wavexx]

I pushed some extra changes that should iron out a few corner cases. First, the state after a pause/stop condition is now properly reset, avoiding an incorrect e/D just after a resume, which again is triggered by a filament check condition.

There are other issues with the filament check code, but it seems that prusa is already working on it on another PR. Furthermore, I found/fixed another bug with the LCD pause handling which is triggered more frequently with LA (although it has nothing to do with it), which I hope that will be merged independently.

[MarcoZ76]

Hi! Do you think is possible to integrate in your fork LA1.5 also the Live EM (Extrusion Multiplier) like the Live K?

[wavexx]

That would be nice to have indeed. But would prusa take it? :(
Live K takes a surprising amount of space for what it does (I guess for translation tables?).
I could make an independent branch for it though.

[wavexx]

I think it's time to to put a bow on it. It's not the end of line in terms of changes, and the obvious next step is to remove the checkRx calls, but I'm just being deliberately conservative here. I think the current status is still miles ahead of the official branch.

I'll turn off LIVE_K by default (just comment the define) and the stubs for 3.7.1 for the official PR. I want to see what sort of response from Prusa we get.

I think that with some tweaks we can massively shrink and improve the menus so that we can include both live K and the EM without having to waste all that space, but we need some cooperation from Prusa here so that it doesn't result in a hack.

[wavexx]

Wow, looking at this after one year and a ton of prints later, is that LA has still room to improve.
Many implementation bugs later aside, there are still many things to do to improve extrusion that we need to work on.

I'll outline here what I've learned:

• LA1.5 tends to over-retract.

You can spot this in the standard k-factor pattern: no pattern is ever balanced - you need need to pick an average. Once you know where to look, this shows up everywhere. The spring model in LA1.0 definitely did better in this area, probably helped by fact that ignoring E-Jerk left less time for the extruder to reverse. While LA1.5 does better, not every model comes out better than the MK3 LA 1.0 implementation, which is bothering me.

• LA needs better planning / separate E axis

Probably not news to most, but the LA handling in Marlin 1/2, essentially pushing extra-ticks on top of the extruder curve works OK on average, but after having received tons of weird corner-cases I can say that this approach doesn't cut it as we try to print faster and faster. The compression factor also needs to be calculated correctly accounting for jerked moves (jumps in speed), which is something that in some situations can lead to systematic over-extrusion if the problem is ignored, or massive under-extrusion if not.

Ironically, as LA1.0 did ignore E-jerk, it also prevented these small over/undershots. With proper e-jerk, especially combined with the higher torque of geared extruders, we need to be more precise. I don't want to see discontinuities and ringing due to the steps destroying a smooth acceleration ramp of the motor.

• LA doesn't play too well with some materials, notably ABS/ASA

You can print a calibration pattern with ABS/ASA and discover it's not too dissimilar to PLA, and it also mostly works, except when you try to perform series of fast compression/decompression cycles, as done in solid infill. Somehow ASA doesn't like this, and tends to flow despite the retract. Maybe the material gets too soft due to heatcreep, loosing it's properties?

PC is printed at a higher temp, and does show this effect as well, but a lot less than ABS/ASA.

• LA K varies too much

K changes with layer height, with temperature, with speed, nozzle size and probably by the mood of the printer too. All understandable, however LA1.0 did seem to respond more homogeneously over a wider range of scenarios. You can argue that a proper K factor can be always tuned, but in the same print we can have huge variations nowdays. Just think about the difference in speed between solid infill and gap fill, when using the mighty combined infill, or with variable layer height.

It's hard to get consistently good results across the board.

It's clear that there's a limit of what we can fix when planning real-time on a 8bit board. Still, I'm still not 100% satisfied.