Problems if try to print a file, just after print the previous one #1421
Comments
Glad you like it, thanks a lot.
Could you please paste some of those errors? Also, what's your OS? |
|
Sorry, for the late answer, I found your message just now, OS is Windows 10, I was sending this gcode now: Normal status printing the first file after reset or connect: Status once printed: Behaviour once printed the first file, and trying to print the second once finished the first, simply after click on print button again: The messages on Pronterface are scrolling, showing same kind of error, at end nothing happens, the heating don't start, and the printer still shows the text "Finished print!" |
|
Hi, |
|
I can confirm this error. During my test I was able to see this as well for Smoothieware and an old Marlin version for both printing direct with Printrun and via SD card. It looks like Pronterface do not clear the buffer when it finish or cancel a print. I haven't a solution for now. @rockstorm101, any idea's? |
|
Hi, sorry for the delayed response, I'm abroad these months so I can't really test for myself with a physical printer. I'm not able to reproduce this at the moment. Those errors sound familiar though, see #1341. It's an error sent from the firmware, hence why it can't be reproduced with a mock-up printer I guess. Could you go in verbose mode and check that the "M110 N-1" command is being sent and received ok when the print starts and finishes? |
|
Hi, |
|
Hi @Escrich, The problem started with the implementation of a workaround for Prusa printers and their firmware update to version 3.12.2 where they changed a behavior that was common for all firmware manufacturer in the past. I don't want to repeat the story here, you can find the discussion here: #1341 and #1378. Anyway, with this change we introduce a compatibility issue for other firmware manufacturer than Prusa and user of older firmware, that do not support the change. I revert this change for a test with two printers that runs Marlin 1.x and Smoothieware 1.x firmware and can then repeat prints without any problems. I have one last question: Had your printer an older firmware version from before 3.12.x when you report this issue? @rockstorm101, |
That's weird, at least for Marlin. According to (some) documentation [1] [2] the command On configurations which trigger errors, if you look at the logs:
Ideas that come to mind rather than trying to split the behavior based on firmware:
As you see I would avoid customizing the code for particular firmwares as much as possible, but if we get to that, I agree that a GUI toggle/checkbox does sound like the way to go. |
|
Hi @rockstorm101, yea, I saw this as well. I don't know if I remember correct, whether that was valid for older versions of Marlin too. I had vaguely in mind that there was a discussion long time ago for this topic like e.g. here: Smoothieware/Smoothieware#1228. I found several discussions about this topic and the attempt to change the behavior, but in the past it was common understanding not to change it because of not breaking older implementations.
yes it will be send for both Actual second print attempt (with M110 N-1), not working: Show log...Modified second print attempt (with N-1 M110), working: Show log...
Yes, it have checksum included
No for actual behavior, Yes for modified behavior (see log snippets)
No, this is actual a great idea. I have tested this for Smoothieware and it works fine. 👍 Show log...I think we should implement this as that way it will not break older firmwares. I like to test this in addition with an old Marlin firmware implementation. That printer will come back tomorrow or the day after. I will push an update for this after the test if you are ok with the change. |
|
Hi, I need a tester with a Prusa printer and firmware >=3.12.x. Other printer firmwares for testing are as well welcome. Long story short, I found in my test an additional firmware from Marlin v1.0.0 that behave different to newer Marlin versions.So we have now 3 variants:
My solution for this is adding back the old behavior and combine this with the actual implemented Prusa modification: Link for Pronterface test version in my repository: In addition here is a little gcode file for a quick test (area needed from homing position: x78 y70 z10 mm) that will run only a half minute and prints above the print bed (z=5 mm) w/o heating and extrusion: Best regards, |
I agree with @DivingDuck I have an old Marlin based Velleman K8200, and the change has caused issues, particularly the lack of the checksum flag being set to True which means the M110 command now errors and gets stuck in an infinite loop unless the printer has been fully powered down between prints. |
Hi, sorry I was AFK past weeks, let me see if I get where we stand on this. Do I understand correctly that the solution below works well for variants 2 and 3 but we still need to test if it works on variant 1? diff --git a/printrun/printcore.py b/printrun/printcore.py
index f0f3da8..042c94e 100644
--- a/printrun/printcore.py
+++ b/printrun/printcore.py
@@ -416,7 +416,7 @@ class printcore():
return True
self.clear = False
- self._send("M110 N-1")
+ self._send("M110 N-1", -1, True)
resuming = (startindex != 0)
self.print_thread = threading.Thread(target = self._print,
@@ -675,7 +675,7 @@ class printcore():
if not self.paused:
self.queueindex = 0
self.lineno = 0
- self._send("M110 N-1")
+ self._send("M110 N-1", -1, True)
def _send(self, command, lineno = 0, calcchecksum = False):
# Only add checksums if over serial (tcp does the flow control itself) |
|
Hi @rockstorm101, A test for Klipper and Reprap would be nice too. I don't expect problems there but a test would be a benefit. That's why I build and link the test version in my repository before pushing it here. Edit: Test for Marlin 2.x is also a good idea, just in case... |
|
All
The issue for the Marlin is the lack of the checksum. Isn't that covered by
the code in the _send function. Why is this only call that has been
introduced that does not pass True and let _send sort this out. Then we are
back to one variant.
Justin Saunders
…On Sat, 5 Oct 2024, 14:33 DivingDuck, ***@***.***> wrote:
Hi @rockstorm101 <https://github.com/rockstorm101>,
welcome back and you are well 🙂
Yes, all what is missing so fare is a test with a Prusa printer and
firmware >3.12.x which I don't own.
A test for Klipper and Reprap would be nice too. I don't expect problems
there but a test would be a benefit. That's why I build and link the test
version in my repository before pushing it here.
—
Reply to this email directly, view it on GitHub
<#1421 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAUYUIBPVXCXLGI24A5AINLZZ7TDRAVCNFSM6AAAAABF5KTTHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGA3DANBQGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Dear @dMAC95, long story short, the change we introduced in #1378 did not play nice with older firmwares and has brought up issues like this one. Error occurs when trying to print one print right after another. So we would need someone who uses Prusa's firmware to test this change. Could you give us a hand here? Thanks in advance |
The issue was some firmware did not accept |
|
@rockstorm101 I'll see what I can do, might take a day or two. |
|
I pushed PR #1454 as fix for this issue. For testing you can use this artifacts: |
|
@dMAC95, You can use one of the Pronterface artifacts above and "print" this file for a quick test: Best regards, |
|
@DivingDuck apologies, work has been busy. I'll do it tomorrow and report back |
|
|
|
Edit: I see the original issue arose with firmware 3.12 - I'll upgrade the printer firmware to 3.12 and test with that. Also will test with the most recent firmware version.
|
|
Thank you very much for taking the time, @dMAC95. I do very much appreciate this. |
|
Figured out all the testing I've done was through the pip package printrun instead of the downloaded repository printrun, so none of my tests were affecting anything (used requirements.txt command for package install) Fixed test environment, uninstalled printrun package and working from printrun pull #1454 Recreated original error with firmware 3.12.2: (Changed M110 line strings to "N-1 M110")
Printing with restored printrun fix on 3.12.2:
Test with most recent Prusa firmware version 3.14.0:
Only modified self.loud and logging against original pull Testing conducted on Prusa MK3S+ printcore.log |
|
This looks good. I guess we can merge the change. Again, thank you very much for your help |
|
Everything checks out on my end, if you need more Prusa testing feel free to give me a shout 👍 |
|
I have an MK4 and XL available for testing as well. |
|
This is very kind. I do not expect a problem, but a quick test on those printer would be nice too 😇 |
Sorry, I do have to get to work now, but if you need the testing for those printers I can find time again this weekend |
|
No problem, this is life. Thank you for taking the time. |
Dear all, first of all congratulations by create Pronterface, I'm using it from years ago, and I love it.
This time I have an old issue, happening at least on versions from last three years I bet, the problem arises when you print a common gcode, in my case always generated by Prusa slicer, and just, after finish the print, made from Pronterface, (I use Pronterface to avoid using the SD card), then, just if you finish to print a part, you simply load another file on Pronterface, and click on print button, instead to print, you only get a stream of text showing you error after error, in the last three years, my procedure is so simple, I simply click on disconnect, then in connect, again, ant this manoeuvre generates a reset on my Prusa original Mk3s printer, then you can print the same gcode that was "generating" errors, without any problem, but always you need to make a reset in between files, now I'm using latest Pronterface versión, but I can get same behaviour in both versions you could see in the attached pictures:
The text was updated successfully, but these errors were encountered: