Resend requests (sometimes?) missing an "ok"
Closed this issue · 75 comments
I've recently gotten a bunch of tickets (see OctoPrint/OctoPrint#2285 and OctoPrint/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.
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.
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
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.
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:
OctoPrint/OctoPrint#2342 (comment)
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:
OctoPrint/OctoPrint#2285 (comment)
@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 😳
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.
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...).
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.
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.
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.
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:
To go on from there I'm wondering if there is also an additional firmware bug causing the wrong line number to be reported.
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 OctoPrint/OctoPrint#2285).
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 #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).
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.
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...
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.
@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.
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.
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.
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.
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.
- 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.
- 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.
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.
Thanks @Sebastianv650, I will review your new implementation of LA.
@JohnOCFII Thanks for heads up, I will review the commits after 3.0.12.
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.
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.
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
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)
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.
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 /
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).
FormerLurker - interesting post! How did you replace the start gcode - manually for each print?
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 :)
- Select the 'Filament Settings' tab.
- Select 'Custom G-code' from the left menu.
- Remove the existing Gcode (M900 K{if printer_notes=~/.PRINTER_HAS_BOWDEN./}200{else}10{endif}; Filament gcode)
- Replace with this: M900 K0
- Click the save icon.
- Rename the profile so that you know you've disabled linear advance, for example: Generic ABS 1.75mm - Linear Advance Disabled
- Return to the 'Plater' tab
- 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.
Prusa merged the M110 fix #283 on 22. December 2017 to the MK2 branch and the #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.
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.
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
@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.
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.
@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!
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.
@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
@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...
@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.
@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/ )
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!
Thanks a lot Sebastianv650 ! Downloaded the *.hex file - will update my Prusa MK2 MMU tonight and get back with results!
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!!!
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?
Nope - kept the M900 K value where it was. I believe K is 200 per default, at least for the MMU version.
@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.
@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.
Thanks guys / will check. Didn’t change anything-assumed it would be 200. But ok-will check!!
Printed the K factor calibration from 0 to 2 tonight. Not sure how to judge. Printed the pattern 3 times with slight different results each time. Will increase the pattern range from 0 to 3 next.
Not sure too how to check the current K value. Just sending a M900 command without parameters resulted in a unkown command (or similar).
@Johncoffee2017 - Here is an image I found of a K factor test print. Line 6 (from the top) appears to be the correct value here. From my understanding, the straightest line, without deviation in width, is the one with the proper value. It might be hard to tell which one is better, but you can use a straight edge to compare (when in doubt, pick the one in the middle). Please someone let me know if I'm wrong about any of this.
I too am having a hard time figuring out how to query the current setting! Just put your final k value in your start up or filament gcode, that way you can be sure it's using the right one (M900 K2.1, or whatever you find).
If you let me know what value you find that will give me a good starting point for my tests. Thanks again for being the first to try this on an MMU!
@ FormerLurker
Sure - pleasure.:-) Thanks for your explanation. The result image you’ve posted looks much better than mine. Look what I’ve got: https://ibb.co/cS0JtH
Will increase K now.
Hmm, looks like it gets worse as the k value goes up. I'll post my results this weekend. If you can, post the GCode file. Maybe something is off with it?
Sure - here you are.
kfactor_gcode.txt
Ah, is that the K-Factor Calibration Pattern generator code? Looks good to me.
@Johncoffee2017 I'm getting used to see calibration patterns like that from bowdens. There is something going on on this kind of printers which isn't covered by LA. The most likely theory I have at the moment is that the filament kind of jams inside the bowden tube as it starts buckling. When this happens, pushing even harder will not improve anything as this will only increase friction and the resulting jam even further.
This would explain why you (and other bowden users) can't see an improvement with increased K. In fact your fast line part isn't recovering to nominal extrusion width at all during the whole length.
Maybe the parameters for the calibration print has to be altered for bowden printers to eleminate this jamming effect from the equation and visialize the LA effect better. I'm thinking about reducing the speed delta and / or reducing the maximum speed. I would suggest to do the follwing:
Given your photo and looking at the line ends, we can see that pressure depletion has a visible effect. Based on this area, comparing the extrusion width from 1st slow part and end of second slow part of each line, I would seek K below 0.6.
- So try to print a test pattern with K ranging from 0 to 1. Use an acceleration of only 500mm/s² to give the filament inside the bowden tube time to relax. Use a slow speed of 40mm/s and a fast speed of 60mm/s to keep the speed differences low.
- If the result isn't more explicit now, it would be intresting if it becomes better with a test acceleration of only 200mm/s². The idea behind this is that the needed extra extruder speed decreases with decreased acceleration. If the extruder speed is kept low, the jamming effect should be minimized. And the test acceleration isn't affecting the found K value, meaning a calibration with 200mm/s² is also valid for 1500mm/s².
@ Formerlurker: Yep. From here: http://marlinfw.org/tools/lin_advance/k-factor.html
@Sebastianv650 : Did your first recommendation already, doesn't seem much better.
We talk about this acceleration here, right?
; Settings Speed:
; Slow Printing Speed = 2400 mm/min
; Fast Printing Speed = 3600 mm/min
; Movement Speed = 7200 mm/min
; Printing Acceleration = 500 mm/s^2
; Jerk X-axis = firmware default
; Jerk Y-axis = firmware default
; Jerk Z-axis = firmware default
; Jerk Extruder = firmware default
Will post my results later, need to go to my building site now :-)
Here the result of the first test with 500 mm/s^2:
made with this Gcode:
Will repeat now with 200mm/s^2
...and now with 200 mm/s^2:
kfactor_gcode3.txt
Guess I'll try with higher K values as well
Yes, the standard print acceleration. So it looks like lowering the acceleration solves the issue that the fast part of the line stays thin? If so, that's good information.
If you can continue with the tests, it would be intresting to know if there is a value of acceleration which acts as a border, below it the line stays thick and above it jams and keeps thin or is it a gradual thing with no more or less sharp transition.
I'm also looking forward to see which K is the needed one. A hint to judge the lines: With the print on the bed, use a caliper to measure the width on slow and fast part. It should be possible to not loosen the lines when you do it very carefuly. Search for the one where the transition between slow and fast has to most consistent true one width.
This weekend I tried to find the best settings for the acceleration & K value for my Prusa MK2 MMU printer (bowden). I failed miserably. All the settings I tried gave me values which were not really good. I never got consistent width for any setting. Tried down to 75mm/s^2 with values from 0 ~ 1.6 for K. I then tried to print the XYZ 20mm calibration cube - 11 times with different settings again. Almost all settings gave me a similar result. Only the extrem values for K = 0.1 had stronger konkave sidewalls - but all tests showed similar results despite the large difference in my settings. Also the egdes with too much material. Have a look below.
First the result with 200mm/s^2 and K=0.1:
Now a overview over all 10+1 cubes: K = 0.1 -1.6 for Sebastianv650 FW / and 200 for Prusa's FW 3.1.
on the bottom right.
The results infact are not too bad - but it seems that the bowden design of a extruder doesn't react as one would wish. Again some more details here - total different values (K=0.4 / acc=200 mm/s^2 and K=1.4 / acc=800 mm/s^2) but similar results:
I even went back to Prusas FW 3.1 and tried with the suggested value of 200 for K - again same result. To top that, I've tried without any LA (K=0) - the result was the same.
(Top right on the above 11 cubes image)
Conclusions for me at the moment:
- Sebastiansv650 FW allows me to use Octoprint again on my Prusa MK2 MMU - compared to Prusa's FW3.1.0.
- LA for the 20mm cube doesn't give me results as Prusa got on the MK2 (without bowden)
- Not sure if LA is worth it on bowden. I need to compare other models for that. Maybe real world models could be better.
Sorry to hear that, but a little voice in my brain expected that already. But it's sad nevertheless, your 200mm/s² test pattern was looking promising.
Most likely there are so many things going on inside a bowden (friction, buckling, uneven compression of filament, ..) that compensating for pressure as LA does is just not enough. I don't think there is a way to compensate that in software, due to the fact we see here that pressure adjustments are not reaching in the nozzle as they should.
One point more for my opinion that bowden is just a bad idea for a printer. It's like painting great art with a cooked noodle instead of a pencil.
I may postpone my testing since #Johncoffee2017 has done such a thorough job (thanks man!), and because Prusa announced a new MMU design that gets rid of bowden entirely. @Sebastianv650 , if you'd still like a second opinion, let me know and I will work it in anyway. Otherwise, no troubles from octoprint, even if LA isn't helping the bowden setup too much.
and because Prusa announced a new MMU design that gets rid of bowden entirely.
Just read it, that's good news! Looking forward to see it, now I'm glad I didn't developed such a system on my own this winter - most likely their solution will be better :)
I also keep Sebastianv650's firmware on my Prusa until the new MMU upgrade will be available in May. To run it via Octoprint is definitely preferred compared to the new established Toshiba Flashair solution I was using after Octoprint failed.
I have to point out that my MMU upgrade works very good - in comparison with other users. It almost never fails to swap my filaments. So the new upgrade of Prusa in May will mainly help me to run it without bowden. Of course LA will be then a benefit again for that new setup.
after Octoprint failed
Just for the record, it wasn't OctoPrint that caused the failure here.
So the new upgrade of Prusa in May will mainly help me to run it without Bowden.
Just to clarify: MMUv2.0 will only be available on an i3 MK3, not on MK2 or MK2.5 (asked Prusa support just today)
The title in the blog (https://www.prusaprinters.org/original-prusa-i3-mk3-3-months/) is very precise:
"Multi Material 2.0 for MK3 and MK2.5"
and also:
"... and existing orders of Multi Material upgrade kit – from MK2 to MK2.5/MK3 will receive version 2.0 even that it will be more expensive. "
Yes, I just again talked to the support - they are releasing info later this week or next week. They're still saying no MMUv2 for MK2.5 even though I showed them their own blog post m(
@foosel : sure - you are correct. Octoprint didn't fail at all. It was / is Prusa's FW 3.1.0 on the MK2 that fails.
@brandstaetter @Panayiotis-git : Thanks for pointing this out. I'm asking myself how this fact is being received by the community - or at least all the MK2 MMUv1 owners....
I think this issue have been fixed and we should close this issue.
[stale]
I'm closing this issue as stale, thanks for understanding.