Let me ask you a question - I’ve noticed on my prints that on the layers where the infill is 100% - the bottom layers of a print mostly where it uses 100% infill 100% of the time for the first few layers - that it almost seems as if it is “blobbed” on the sides of square structures. It is only on the first few layers - almost like there is too much infill and it pushes the perimeters out a little bit. On the rest of my prints I have infill at 20% and I don’t see this issue. I thought that it was an overlap issue. Is this the problem you are trying to address? I was thinking it was a Cura slicing issue and I’ve been playing with the overlap parameter without success. It’s been driving me nuts.
If this happens only with my release from yesterday, it’s verly likely the problem I fixed now!
I should have been more clear - I have seen that problem on the stock Marlin firmware. I haven’t had the chance to try out your version yet. Specifically, it was the version provided by Lulzbot for Taz 5 (Marlin 1.0? With Lulzbot modifications?). I never thought about the problem being part of Marlin - I was stuck thinking it was the slicer.
Like this one on the left? A little bit overspilling the first perimeter line and squished?
That’s what’s healed with advance.
I don’t know if this shows it really well because it is a white print, but this is what I’m talking about. The lower right area near the bottom layers kind of “blobs” out. This is pretty consistent from what I saw. I thought it was an overlap issue.
Not the best picture, but I’m quite shure its not an advance pressure thing. I guess flow rate calibration together with precise Z-height measurement is what you want to heal this.
Cool! Thank you!
Hi,
I’d love to test out the advance feature in this firmware. I don’t have a build environment set up on my computer rigt now though. Is there a pre-compiled version I could load to test? I guess I’d need the version with the correct acceleration for an unmodified TAZ5.
If anyone could post this, I’d be quite appreciative!
Best Regards,
J
I wasn’t including the .hex file intentionaly… This feature is still in development, and I think it’s not good to make it too easy for “end users” to experiment with maybe not fully debuged code. This way, I know everyone using it has a basic knowledge about the firmware that may help to understand what’s happending if something goes wrong and how to revert to stock if necessary.
Maybe I’m too careful?
I did the same thing with the firmware I worked on for my TAZ 6 updates. Since I have different hardware from upgrading since a TAZ 1, I did not want anyone ripping their expensive printer apart with my settings. Therefore I provided the source code for compilation. It is only a couple of button clicks to compile it and should not be too hard for someone that wants to experiment, or improve upon my work.
Your points make sense! I can set up the compile environment, I’m just being lazy 
Sebatian,
I loaded up your code tonight. A few issues I am having:
-
It retracts and forward in very tiny increments at incredibly high rate. Sounds like I’m grinding the extruder gear, because of how often it is trying to. (Using same STLs I did before which did not do this.)
-
I stops printing for anywhere from 10 seconds to 2 minutes randomly. (maybe bug #3287 or #3284)
This message shows when it stalls out:
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing -
Seeing alot of checksum mismatches, and it not receiving lines:
Send: N98630 G1 F3000 X135.789 Y164.683 E8608.87939*54
Recv: Error:Line Number is not Last Line Number+1, Last Line: 98629
Recv: Resend: 98630
Can you merge your changes into RC5 or RC6?
I guess your problems are related to a bug I fixed a few days after I posted the code here.
You can find the latest code here: https://github.com/Sebastianv650/MarlinRC_LIN_ADVANCE/tree/MarlinRC_LIN_ADVANCE-2ISR
I’m in the process of a re-implementation to the latest Marlin RCBugFix, but it takes some time. It’s very bad for me that they made bigger changes to stepper.cpp and planner.cpp with the last commits - now they use objects. I have nearly no practice in coding, I need it only once a year or so, so it’s a hughe effort for me to read through all the changes and make it working again. And I’m afraid I will do it at least once more when they introduce the extruder mixing feature… 
Thanks for the status update. For now, I jumped to the RCBugFix branch and your config files.
It should be safe now to use the code from my Fork on Github. I changed the behaviour of the extruder interrupt. It’s now distributing the esteps instead of firing up to 4 in a batch. I get nearly no communication errors now during print, seems to be quite perfect now.
By the way, the communication errors are due to a bug in Marlin, the advance thing makes it worse but it’s not the source. That’s why the link points to the RC4 code base and not to the latest RCBugFix that’s also available on my repo. The changes they did in RC6 and later slow down the ISR routines which leads to much more errors than in RC4. One important function from the serial communications seems to get interrupted by the ISR…
Your last link in the post before this one is not setup for a Taz 5. Do we just overwrite the configuration.h and the configuration_adv.h with your Taz 5 firmware from your previous version? Are there any other reqiured files? Or is this one not ready for Taz 5 use? Sorry I only have enough knowledge to be dangerous.
The version on github.com is a stock marlin config. You can take you current taz config files as a reference and edit the new ones with your values.
Or you wait until mid next week. I got advance to stabile also in RC6 and will provide a configured download for all the users here who wants more 
I will wait, thanks again for all your hard work!
Time to wait is over: https://forum.lulzbot.com/t/latest-firmware-for-taz5-advanced-development-version/3451/1
Thanks for all your hard work. I was going to create a version so I could use Mesh leveling, but now I don’t have to. Glad I checked the forums. 