Resend requests (sometimes?) missing an "ok"

[foosel]

I've recently gotten a bunch of tickets (see foosel/OctoPrint#2285 and foosel/OctoPrint#2291) that hint at the firmware ("3.0.12 w/ linear advance" and 3.1.1 RC1 (?)) sending out resend requests without a trailing "ok":

Send: N66557 G1 X131.715 Y133.287 E0.0037*93
Recv: Error:checksum mismatch, Last Line: 66555
Recv: Resend: 66556

This should rather look like this:

Send: N66557 G1 X131.715 Y133.287 E0.0037*93
Recv: Error:checksum mismatch, Last Line: 66555
Recv: Resend: 66556
Recv: ok

A look into the source reveals that in ClearToSend you check for CMDBUFFER_CURRENT_TYPE == CMDBUFFER_CURRENT_TYPE_US:

void ClearToSend()
{
    previous_millis_cmd = millis();
    if (CMDBUFFER_CURRENT_TYPE == CMDBUFFER_CURRENT_TYPE_USB)
        SERIAL_PROTOCOLLNRPGM(MSG_OK);
}

However, taking a look at the get_command function (MK2 version, MK3 version) you only set the current type after having handled any potential resend requests.

Now, I haven't yet reproduced the issue myself (and it's tricky to reproduce intentionally anyhow), I've only looked at the logs provided by my users and at your source, but this might be the issue here. Or not. I'll leave that for you to judge, I'm not that familiar with this Marlin fork (yet ;)). In any case, something's up with the resend requests, so if you could take a closer look at that, that would be great and reduce the likelihood of more users running into this in the wild.

---

Note: There does exist a workaround in OctoPrint for this (since it's happened in the past with other firmware variants), users can tell OctoPrint to "simulate" an ok after resends by enabling Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests, but that has to be done manually.

[sbts]

To go on from there I'm wondering if there is also an additional firmware bug causing the wrong line number to be reported. Looking at a slightly longer excerpt from the serial log....

Send: N66555 G1 X131.338 Y133.349 E0.0091*91
Recv: ok
Send: N66556 G1 X131.574 Y133.428 E0.0046*92
Recv: ok
Send: N66557 G1 X131.715 Y133.287 E0.0037*93
Recv: Error:checksum mismatch, Last Line: 66555
Recv: Resend: 66556
Recv: Error:Line Number is not Last Line Number+1, Last Line: 66555
Recv: Resend: 66556

• Line 66555 is received OK
• Line 66556 is received OK
• Line 66557 has a checksum error.

That suggests to me that line 66557 is actually the line that should be being requested resend, however, the firmware is requesting 66556

If I'm correct and the wong line is being requested, I'd expect a physical print error as the last line will be duplicated.

[Firebug24k]

Yes, I'm having the same problem I think - latest failed print excerpt below:

Send: N245945 G1 X73.662 Y61.664 E0.0166790 Recv: ok Send: N245946 G1 X73.280 Y61.837 E0.0166789 Recv: ok Send: N245947 G1 X72.934 Y62.063 E0.0164785 Recv: ok Send: N245948 G1 X72.632 Y62.332 E0.0160895 Recv: ok Send: N245949 G1 X72.381 Y62.633 E0.0155794 Recv: Error:Line Number is not Last Line Number+1, Last Line: 245945 Recv: Resend: 245946 Send: N245946 G1 X73.280 Y61.837 E0.0166789 Recv: ok Send: N245947 G1 X72.934 Y62.063 E0.0164785 Recv: ok Send: N245948 G1 X72.632 Y62.332 E0.0160895 Recv: Error:No Line Number with checksum, Last Line: 245945 Send: N245949 G1 X72.381 Y62.633 E0.0155794 Recv: ok Send: N245950 G1 X72.169 Y62.979 E0.0161182 Recv: Full RX Buffer Recv: ok Send: N245951 G1 X72.009 Y63.358 E0.0163689 Recv: Error:checksum mismatch, Last Line: 245948 Recv: Resend: 245949 Send: N245949 G1 X72.381 Y62.633 E0.0155794 Recv: ok Send: N245950 G1 X72.169 Y62.979 E0.0161182 Recv: ok Send: N245951 G1 X72.009 Y63.358 E0.0163689 Recv: Error:Line Number is not Last Line Number+1, Last Line: 245948 Recv: Resend: 245949 Send: N245949 G1 X72.381 Y62.633 E0.0155794 Recv: ok Send: N245950 G1 X72.169 Y62.979 E0.0161182 Recv: ok Send: N245951 G1 X72.009 Y63.358 E0.0163689 Recv: Error:No Line Number with checksum, Last Line: 245948 Send: N245952 G1 X71.907 Y63.762 E0.0166080 Recv: ok Send: N245953 G1 X71.868 Y64.180 E0.0166783 Recv: Full RX Buffer Recv: ok Send: N245954 G1 X71.893 Y64.598 E0.0166793 Recv: Error:Line Number is not Last Line Number+1, Last Line: 245951 Recv: Resend: 245952 Send: N245952 G1 X71.907 Y63.762 E0.0166080 Recv: ok Send: N245953 G1 X71.868 Y64.180 E0.0166783 Recv: echo: cold extrusion prevented Recv: ok Send: N245954 G1 X71.893 Y64.598 E0.0166793 Recv: Error:Line Number is not Last Line Number+1, Last Line: 245951 Recv: Resend: 245952 Send: N245952 G1 X71.907 Y63.762 E0.0166080 Recv: ok Send: N245953 G1 X71.868 Y64.180 E0.01667*83 Recv: start Printer sent 'start' while printing. External reset? Aborting job since printer lost state. Changing monitoring state from 'Printing' to 'Operational' Recv: echo:echo: Last Updated: Oct 30 2017 10:24:26 | Author: (none, default config) Recv: Compiled: Oct 30 2017 Recv: echo: Free Memory: 2217 PlannerBufferBytes: 1360 Recv: echo:Stored settings retrieved Recv: echo:SD init fail Recv: Error:Line Number is not Last Line Number+1, Last Line: 0 Recv: Resend: 1 Printer requested line 1 but no sufficient history is available, can't resend Recv: echo:SD init fail No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves. Changing monitoring state from 'Operational' to 'Offline: Too many consecutive timeouts, printer still connected and alive?' Connection closed, closing down monitor

[rnldnkp]

I came to the same conclusion as @foosel, tested on both Octoprint 1.3.5 and 1.3.6

Using Prusa firmware 3.1.0, 4 out of 5 prints get stuck, waiting for an OK. After downgrading to firmware 3.0.12 (final), 5 out of 5 prints finished just fine.

All tests were performed on a Prusa i3 MK2(S) with MMU (testing single mode prints though), using latest software/settings (30 dec 2017). Did not try yet on my MK3.

Please fix this as the printer is useless with such a high 'fail' rate. Also, the heatbed and nozzle stay on, might be dangerous as well.

[henrikkoch]

I completely agree ! useless!

On Sun, Dec 31, 2017 at 1:51 PM rnldnkp notifications@github.com wrote:

I came to the same conclusion as @foosel https://github.com/foosel, tested on both Octoprint 1.3.5 and 1.3.6

Using Prusa firmware 3.1.0, 4 out of 5 prints get stuck, waiting for an OK. After downgrading to firmware 3.0.12 (final), 5 out of 5 prints finished just fine.

All tests were performed on a Prusa i3 MK2(S) with MMU (testing single mode prints though), using latest software/settings (30 dec 2017). Did not try yet on my MK3.

Please fix this as the printer is useless with such a high 'fail' rate. Also, the heatbed and nozzle stay on, might be dangerous as well.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware/issues/331#issuecomment-354602139, or mute the thread https://github.com/notifications/unsubscribe-auth/ADpAeLYmyKyqHkE5Bds9PIezHzw7KTzdks5tF4NogaJpZM4RFste .

--

Med venlig hilsen / Kind regards

Henrik Johansen KochHans Erik Nielsens Vej 7, DK 3650, Ølstykke, Denmark

T +45 4710 0305 F +45 7734 0307 *M +45 4068 0305*E-mail henrik@koch-engineering.com henrik@koch-engineering.com

[cellardoor]

I have the problem aswell...

My Setup:

• Prusa i3 MK2S with MMU with Firmware 3.1.0
• Octoprint (on RaspberryPi) V1.3.6 / Octopi V0.14.0
• Slic3r Prusa Edition V1.38.6-prusa3d-win64

Here is what i noticed until now: When i use Slic3r in "Multimaterial" Mode to postprocess my gcode, its all fine... until now no Problems with printing from SD or via Octoprint. When i use Slic3r in "Single" Mode (Orginal Prusa i3 MK2 MM Single Mode) to postprocess my gcode and i print that gcode via Octoprint 4 from 6 parts fail with error: Line Number is not Last Line Number+1 (2 Parts printed well... till end). A reprint via Octoprint from one of that 4 Parts throws the same error, but when i put the same gcode file on SD it prints well.. till end.

4 me it seems like a FW issue aswell only when printed with serial transmission, but I have no idea, iam no programmer.... i hope my little study hels some experts... enclosed some files to reproduce the error LOG_MMU_Singemode_Octoprint_issue.txt MMU_Single_Mode_Fails_on_Octoprint_gcode.txt MMU_Multimaterial-Mode_successful_via_Octoprint_gcode.txt

But what i rly dont understand is, when u compare the 2 files at the section where the error appears... the files are identical at this point, see

I dont rly know how it works with Quotes here... but @foosel posted here: https://github.com/foosel/OctoPrint/issues/2342#issuecomment-356873302

Note: There does exist a workaround in OctoPrint for this (since it's happened in the past with other firmware variants), users can tell OctoPrint to "simulate" an ok after resends by enabling Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests, but that has to be done manually.

but what means?

should work, but it's tricky to test.

is it risky for my printer? xD or tricky for you @foosel because u use a virtual printer? that i saw there: https://github.com/foosel/OctoPrint/issues/2285#issuecomment-356887193

[foosel]

@cellardoor tricky for me because I forgot that I can also easily trigger a resend request by just sending a wrong checksum. Why I didn't think of that a month ago when reporting this I have no idea :flushed:

[FormerLurker]

I'm having the same issue with my MK2S with multi material upgrade. I get random freezes anywhere from 1 to 24 hours into a print. I'm going to try the workaround now, but it looks like the resend request is both requesting the incorrect line AND not returning an OK.

[foosel]

Short update from my side - I cannot reproduce this intentionally (by sending a wrong checksum or a wrong line number) against 3.1.1 RC2 or 3.1.1 RC5. Both firmware do always send me an ok after the initial resend request. However it's too consistent a behaviour reported by quite a large number of users (made worse by the serial communication issues in 3.1.0 and 3.1.1 up until recently(?)) to make me feel comfortable by not being able to easily reproduce this...

Could there maybe be some kind of race condition at play here? I did my manual tests against an idle printer, might it be that the code I suspected in my original post only causes the ok to not be sent when hammering the printer with commands over serial during an actual active print? Or could it be the serial communication issues after all (but then, why would it ONLY be the ok that was consistently missing from the resend requests in all reports? A bit too much of a coincidence...).

[FormerLurker]

Did you notice that there were some recent changes to get_command (4 days ago)? It looks like they added a MYSERIAL.flush() line if the buffer is full, and removed some code that was adjusting the tail of the buffer. I wonder if this is related.

[foosel]

Doesn't explain I couldn't reproduce on RC2 from December either. Would need to test against a vanilla 3.1.0 (which most reports were made on) but I don't think that even runs on the MK3.

[brandstaetter]

There is a possibility that it's not reproducible on a MK3, as it has a different board? I've switched to printing directly from SD for now, as the workaround in Octoprint might also cause problems. I hope this issue is found and fixed soon.

[foosel]

Hm, I think I also saw reports from MK3 users that had the familiar lacking ok visible in the log. But I might be mistaken.

In any case, just looking at the code it looks like if a command is injected from firmware side and a GCODE command read from serial after that happens to cause a resend, it will wrongly be treated as a not-USB-command because the flag that determines the command source is only set after resend processing and that would cause the ok to be suppresed in ClearToSend that's triggered by FlushSerialRequestResend. Definitely looks like #364 would address this, so even if this stays unreproducible, I'd strongly suggest to look into merging this (or create something similar) since the current code simply doesn't make sense from a processing order perspective.

Maybe @PavelSindler, @bubnikv or @XPila have an opinion on this? :)

---

I've switched to printing directly from SD for now, as the workaround in Octoprint might also cause problems.

Only if you enable it. Which is why it's disabled by default.

---

Finally just to clarify something that's been mentioned here twice now:

@sbts:

To go on from there I'm wondering if there is also an additional firmware bug causing the wrong line number to be reported.

@FormerLurker

it looks like the resend request is both requesting the incorrect line AND not returning an OK

It's not requesting an incorrect line number, the oks are offset. If you get something like this (bogus checksums btw):

Send: N123 Foo*123
Recv: ok
Send: N124 Bar*124
Recv: Error: checksum mismatch
Recv: Resend 123
Recv: ok
Send: N123 Foo*123
Recv: ok

That doesn't necessarily mean that this ok right after N123 there belongs to line 123. Chances are actually not that slim that it belongs to 122 or maybe even 121 or 120 or... . The ok however tells OctoPrint that it shall send the next line (124). Then the firmware actually parses 123 and realizes there's an issue with it and requests 123 again. If it sends an ok along with that resend request, all's well and OctoPrint will just directly send out line 123 again. But if the ok is missing, OctoPrint will run into a timeout during an active resend request. Which - for reasons of compatibility with some firmware (variants) out there if I remember correctly - means it will now send the last line it sent to the printer before the printer requested a resend request, to attempt to tickle it into acknowledging. This specific behaviour is something I have to look into on my end (see foosel/OctoPrint#2285).

[PavelSindler]

Hello, first of all, sorry for not being able to answer sooner. Thank you for your comments and for your patience. Issue with missing OK, has been fixed on MK3 firmware https://github.com/prusa3d/Prusa-Firmware/pull/341 so this particular issue should be ok, since RC3 fw version release. There was also issue which causes that there were checksum errors and missing lines very very often. This was caused by linear advance which led to high CPU load and thus communication errors. In current (RC5) fw version, printing over usb should be reliable once again. See also release notes: https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.1.1-RC5. We are currently exploring if we are able to readd linear advance in near future or if we will leave it temporarily without this feature (we do not want to sacrifice reliability).

[Sebastianv650]

In Marlin I solved this issue by allowing serial ISRs with the stepper ISR. Also without LIN_ADVANCE, Marlin had this serial errors under certain circumstates. During the creation of the PR for LIN_ADVANCE, I wanted to keep the changes minimal and I never got a single com. error with my MK2, therefore all the ISR patches were not included.

I'm thinking about a next version of LIN_ADVANCE, speed is one point for that but I'm not sure up to now if there is room for more speedups. Beside this, at this moment I see only the ISR thing as a solution.

I even did time measurements during the development of LIN_ADVANCE. In this days, Marlin needed 50µs for an accelerating stepper loop. With activ LIN_ADVANCE it was 63µs. So while it's true LIN_ADVANCE added some time (unavoidable), I don't have the feeling it's a hughe delta. It's just the little bit more that inside an already too long ISR that changed things from barely working to not working.

[rnldnkp]

Thanks for the update for MK3, but what about MK2/S/MMU? Last firmware update is of nov 12 2017 This is were most of the issues started (also Linear Advantage included), lots of people are using a SD for now...

[PavelSindler]

As soon as we will find the best solution for MK3, I would like to make some quick patch release for MK2 (missing OK + missing chars/checksum mismatches). MK3 has probably higher priority as we advertised it as "ready to use" with PI Zero and communication errors were more frequent and usb prints were failing very very often on MK3. But we are now doing some tests with MK2 also, so it is definately high priority now.

[hoegge]

@PavelSindler There are lots and lots of current MK2(s) customers useing Octoprint/OctoPI that now gets prints ruined daily. Most of them you have probably not hear from yet, since they believe it is their Pi or cables etc. that is the problem and never find their way here. This should have super high priority to get fixed now and it should not await any MK3 issues. Please - it is not a small bug but a broken communication protocol.

[foosel]

Shouldn't it be fairly fast to just provide a build for MK2 without linear advance enabled until a better solution is found? Or are test cycles or something like that the problem here?

Considering the amount of tickets I get on the OctoPrint bug tracker related to the general serial communication issues also on MK2 it certainly feels like a quick hot fix now combined with a better solution sometime down the road would be preferable.

[bubnikv]

I am currently looking into the linear advance feature. The issue with the linear advance is, it will insert additional steps in between the usual steps, and if these additional steps are going too quickly, they cannot be ticked in a timely manner by the underpowered 8 bit CPU. Also it is quite possible, that the motor driver and the motor cannot be physically ticked that quickly.

So @Sebastianv650 implemented a valid workaround: There is a minimum time for a single tick of the inserted E steps, and @Sebastianv650 also reworked Marlin to enable serial interrupt inside the stepper interrupt routine. These are all valid solutions, and the only difference to the MK2 firmware is, we do not have the serial interrupt overlap modification. A not so elegant, but a simple and safe patch for the MK2 firmware would be to check the serial line HW buffer at each linear advance tick.

The linear advance as implemented today may have a negative effect on the smoothness of the Cartesian moves: If too many additional E-steps are inserted, the Atmel chip has no chance to tick them on time, @Sebastianv650 's code applies a minimum time interval between the E ticks and this may slow down some of the phases of the acceleration and deceleration ramps. I will look into this with a logical analyzer to get a feeling of the magnitude of the problem. I am thinking of following tricks to tame the Linear Advance: 1) to put cap on the maximum additional E-steps inserted, 2) additional grouping of the LA E-steps. Let's see what the experiments tell me.

[bubnikv]

@foosel

Shouldn't it be fairly fast to just provide a build for MK2 without linear advance enabled until a better solution is found? Or are test cycles or something like that the problem here?

I believe just disabling the linear advance by removing a line from the start G-code will solve the missing serial interrupt issue.

[Sebastianv650]

This one still puzzles me as I'm nearly always printing over USB on my MK2s, never got a single communication error. I'm still using the FW version I created the initial PR with, maybe something has changed since then that made it worse..

@bubnikv I did a lot of research about in-detail planner behaviour and also step distribution with / without LIN_ADVANCE since new year. I also tried to improve LIN_ADVANCE using the actual implemented way of working along with 2 or 3 other technics, non was a real improvement. I realized a lot of things like step distribution looks well in theory, but are an awful mess in reality. I even came to the point at which I was wondering why it's even working with all that inconsitent step rates.

1) to put cap on the maximum additional E-steps inserted

I tried this also in the early days of development. Failed completely: If you just delay the overflowing steps, in the next loop it gets worse as the time avaiable is decreasing. If the excess amount is deleted, the pressure advance is not longer in sync.

2) additional grouping of the LA E-steps.

Also tried and failed on my side. If we have a spike like it may happen on junctions, it's too much in every way.

But I want to add also something positive. I'm working on a different approach which is available as a draft here: MarlinFirmware/Marlin#9379 While it's leaving the perfect in-sync way LIN_ADVANCE 1.0 tried to follow (and failed in some cases), this will add nearly no overhead compared to LIN_ADVANCE disabled and test prints looks as the not "calculated" advance steps are not problem at all. See PR for more informations. You can also find more informations in MarlinFirmware/Marlin#9048

If this approach is finaly done and stable from my point of view, I could create a PR to PrusaFW if wanted.

[JohnOCFII]

This one still puzzles me as I'm nearly always printing over USB on my MK2s, never got a single communication error. I'm still using the FW version I created the initial PR with, maybe something has changed since then that made it worse..

I just wanted to add that I know of a number of people (including myself) using 3.0.12 with the Linear Advance feature as implemented by @Sebastianv650 without issue on MK2/MK2S. Something that came in AFTER 3.0.12 and Linear Advance seems to have tipped the scales and started to cause issues. I'll happily stick with 3.0.12+LA for now.

[bubnikv]

Thanks @Sebastianv650, I will review your new implementation of LA.

@JohnOCFII Thanks for heads up, I will review the commits after 3.0.12.

[bubnikv]

@JohnOCFII

I just wanted to add that I know of a number of people (including myself) using 3.0.12 with the Linear Advance

Do you use our 3.0.12 build, or do you use Sebastian's build? Because we introduced the @Sebastianv650 's linear advance first with 3.1.0-RC1.

[JohnOCFII]

Do you use our 3.0.12 build, or do you use Sebastian's build? Because we introduced the @Sebastianv650 's linear advance first with 3.1.0-RC1.

Here's the version we are using: https://github.com/PrusaMK2Users/Prusa-Firmware -- looks more closely aligned with @Sebastianv650's build.

[Muehsal]

What the..... The nozzle of my printer was hot over the whole night without printing thanks to this bug (using MK2S/MMU with Octoprint). There should be at least some warning not to use Octoprint + MK2S/MMU 3.1.0

[hoegge]

Is there now way for Octoprint to re-establish the communication when everything stalls, now that the Prusa printer firmware does not seem to work as it should? ( I know it is bad to compensate for other components' bugs)

[foosel]

No, because then stuff would break for every other printer out there. There exists a workaround in OctoPrint (mentioned above) for missing ok on resends, but since this particular issue doesn't always happen, that can apparently also introduce problems.

The actual solution would be to flash a fixed firmware build considering that the issue itself is solved in the current source. It would therefore be great for a lot of users currently running into this if there was a build of the 3.1.1 firmware for MK2/MK2s/MK2 MMU, but as far as I know that's currently not the case.

[patrick3463]

Great. It seems like everyone is having this issue. I wonder if prusa will do anything about this as its so ridiculous. The last update they had was in november last year. And the octoprint for mk3 was resolved in few days, why cant they just release an update for this issue /

[FormerLurker]

Patrick3463 - I've been printing without the linear advance profile, and just in case I've been replacing the standard filament start gcode with the following:

M900 K0

Since it appears to be linear advance that is causing the bulk of these issues, disabling it makes the issue go away, at least for me. I went from a lockup nearly every print to 0 lockups after many many prints. It's too bad, because I was getting some really exceptional results printing with LA enabled.

Also, I've heard that the MK3 has been getting all of the attention because it was advertised to work with OctoPrint, while the MK2/MK2S was not. It is sad that we have to wait, but I'm pretty sure they will get around to it once they finish fixing the MK3 firmware (there are still lots of bugs to be worked out apparently, due to all of the new fancy features).

[Johncoffee2017]

FormerLurker - interesting post! How did you replace the start gcode - manually for each print?

[FormerLurker]

It's easy! I'm assuming you are using Slic3r, else these instructions will change. Also, I am not sure this is even needed, since you should not be using the linear advance profile (do not select the '0.20 100mms Linear Advance' or '0.15 100mms Linear Advance' print settings profile). Also, I don't know your level of proficiency with Slic3r, so I'm going to explain every step. Just ignore what you already know :)

1. Select the 'Filament Settings' tab.
2. Select 'Custom G-code' from the left menu.
3. Remove the existing Gcode (M900 K{if printer_notes=~/.PRINTER_HAS_BOWDEN./}200{else}10{endif}; Filament gcode)
4. Replace with this: M900 K0
5. Click the save icon.
6. Rename the profile so that you know you've disabled linear advance, for example: Generic ABS 1.75mm - Linear Advance Disabled
7. Return to the 'Plater' tab
8. Select this filament in the dropdown.

Step 6 is optional, but if LA comes back, or if this bug is fixed, it might be good to know which profiles have LA disabled.

You should now be good to go. I can't promise this will work for everyone, but it seems like a logical work-around, and has worked for me well enough.

[3d-gussner]

Prusa merged the M110 fix https://github.com/prusa3d/Prusa-Firmware/pull/283 on 22. December 2017 to the MK2 branch and the https://github.com/prusa3d/Prusa-Firmware/pull/343 on the 23.December 2017 to the MK3 branch.

The MK3 firmware hex files have that fix since FW 3.1.0-RC5.

BUT the latest MK2 firmware hex files are are from 12.November 2017, so they merged the fix BUT didn't publish new firmware hex files yet.

I compiled and published the MK2/s and MK2/s MMU firmware hex files on my github.

[thess]

With respect to the issue of missing "ok" on broken (checksum mismatch & line number errors) command lines - see PR #364. Works for me! The main issue is RX overruns occur when the stepper tick has interrupts off.

To that end, I have a different scheme for interrupt / stepper processing which allows RX interrupts to have priority over all other processing (no need for checkRx). In addition it makes the stepper processing have priority over the "other" (temperature, etc) timer processing. So far it looks good though the extra LA ticks causing timer overruns still need to be handled without too much penalty. Current timer overflow workaround seems to be adequate.

[hoegge]

Well, turning of LIN ADV is not an acceptable workaround for the average user, that are not into those kinds of details. Prusa should fix the firmware ASAP

[3d-gussner]

@thess Same her, your Pull Request fix some issues and got also no complains about it yet. Thanks again! And as said Prusa approved the pull request in December 2017 but didn't updated the firmware hex files for the MK2 since November 2017. @hoegge Prusa and @Sebastianv650 are busy with the LA issue. Sebastians LA 1.5 just made it few days ago to Marlin firmware hope it will make it to the Prusa firmware too. Let's see.

[Sebastianv650]

I will do a PR for Prusa FW, but after a hopfully successful Merge into Marlin and after a test period on my MK2s.

For me it's realy not a good feeling reading that LA is the cause of this issue, as I know this problem wasn't present in my PR version (which I'm still using nowadays). I know LA adds some load to the stepper ISRs, but it's possible to live with that. I hope changes made to a version with LA 1.5 will not end up like this, or I will have to create a hex file with an own FW version for MK2s which I can support on my own so I know no bad changes are made to this one..

Sorry for all the problems anyway, LA 1.5 should be also more robust to changes as it's not loading the CPU to the same amount as v1.0 did.

[FormerLurker]

@Sebastianv650, I think a lot of us know what it's like to have issues with new features (and this is truly is a GREAT new feature). It's even worse if the fix is out of your hands.

Sounds to me like people LOVE LA, and that's why they are upset about the problems. Thank you for your efforts!

[MartinMajewski]

Interestingly enough, that I run my MK2S without an issue with LA activated, but my MK2S MM version refuses to print anything to the end. :-( Hope that there is a fix underway as I don't want to fiddle with unofficial FWs nor I have the time to deep into more advanced settings.

[patrick3463]

@MartinMajewski i have mk2s mmu and my prints using octoprint reaches no further than half way but if you slice using slic3r, save to SD, and eject card. I havent had any issues yet. It works xD now that i said it, it will fail haha. Ive had problems such as random restarts, full buffer, random extrusions not visible in gcode, stepped motor disabled, incorrect line with printer stopping and cooking filament. All sorts of things. Ill let you know if my list expands xD

[MartinMajewski]

@patrick3463 Yay! \o/ Looks like we have a very expensive random nonsense machine. Just missing the cat's paw that pushes the power-off switch every time...

[FormerLurker]

@MartinMajewski - I too am using an MK2S MMU and have experienced this problem most of the time if I have LA enabled. My brother uses MK2S without MMU and has told me he's not had any freezing problems, and he prints exclusively from Octoprint, always locally (not SD). That is really odd, and I'm glad you pointed it out.

[MartinMajewski]

@FormerLurker You're welcome. However, I would be gladder if the Prusa team would react to this. I wonder if the MMU upgrade is a success on the market or used by only a few enthusiasts, as I wonder why there is so little noise about this issue on the MMU and if I am doing something wrong?This issue is a show-stopper in my case, as my 3D-printer farm runs at 100% OctoPi-fuel.

I hope that Prusa Research has not misestimated the workload for maintaining all the different printer versions they have out there by now. The last FW upgrade (3.1.1) was solely for the MK3 (even if you can get a generically named one from this official source: https://www.prusa3d.com/downloads/firmware/ )

[Sebastianv650]

I just finished the Linear Advance PR for the Prusa MK2 branch: #504

While this should solve the serial issues, it's untested for MMU printers. Read the notes carefuly before testing!

[Johncoffee2017]

Thanks a lot Sebastianv650 ! Downloaded the *.hex file - will update my Prusa MK2 MMU tonight and get back with results!

[Johncoffee2017]

Tried tonight my first print with your new FW Sebastianv650 - worked like a charm! No errors in the log file of Octoprint!! Pheeeew - at least it works again. Thanks a lot for your hard work Sebastian!!!

[FormerLurker]

Johncoffee - Thanks for being the first to test this! I'm excited to have some free time to try it out. Did you modify slicer M900 K values at all?

[Johncoffee2017]

Nope - kept the M900 K value where it was. I believe K is 200 per default, at least for the MMU version.

[Sebastianv650]

@Johncoffee2017 you have to change the K value, 200 is not the right one! Please read the text inside the PR and also the documentation page http://marlinfw.org/docs/features/lin_advance.html.

[FormerLurker]

@sebastianv650 @johncoffee2017

I'll run a k test print this weekend and will report back with my findings. The ideal value is likely over 2.0 for the mmu, though.