-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M114 error with Prusa Mini+ #712
Comments
After staring at self._position_signal.set() I wonder why because at this time no position request should have been send. Maybe that introduces a race condition. In lines 277+ the flag is cleared but as this is asynchronous, couldn't it be that it interferes with I didn't look at the whole code, so I might be missing something. Also, I am printing right now, so I can't test for the next 13 hours or so. |
That set doesn't cause any issues as it's cleared in get_position_async on line 277 here:
The question is why is it taking so long to get a position request back. The request was sent an no position was delivered in 1 minute (from 12:23:26 to 12:24:26). Why don't you clear the log (see the logging profile, edit it, and click clear all logs) and produce a full log of the startup. I want to see when the position is returned. It might also be a good idea to see the serial log of this (from OctoPrint Settings -> Logs), so maybe enable that logger before you start. Also, do you have any other gcode scripts that run, like maybe in Octoprint or some other plugin? Finally, what other plugins are active? This could be a conflict. I just got a video today of someone doing a timelapse on a mini, but maybe it really is the most recent firmware? Have you upgraded recently, and was it working before? |
Hey @hasko, just making sure you saw my comment here. I fought with this for over an hour, but when I power cycled my mini+ it went away. Seems very strange. Not sure if it's a firmware issue or if something got the printer in a bad state. Wondering if you're able to get working again with the reboot. |
Very odd. The only reason m114 should be delayed is that either an m400 was sent, or the printer is busy (warm up and wait, wait for user input, etc...) |
@jbienz yes, I saw that comment, thank you. Unfortunately, power cycling didn't fix it for me. The issue is repeatable. @FormerLurker I will send the logs tomorrow when my current print is done. In terms of other plugins I have only BedVisualizer 1.0.1 (don't think it makes a difference) and OctoRant 1.2.3 (send Discord messages, slight chance it interferes because it notifies on print start; I will try to disable it). I haven't tried OctoLapse with older firmware. You are right about the 1 minute difference, that's weird. I hadn't noticed because it's the same second almost the same microsecond, in fact 1 minute and 30 milliseconds. Very odd. Almost as if there was another timeout involved. How else could it be so precisely a minute? |
thanks @hasko. Looking forward to seeing the logs. |
@FormerLurker here are the logs: Fun fact: I've increased the Is it possible that the |
So, I think the issue is that the new buddy firmware seems to respond with an OK to M114, but isn't sending the position until after it sees another command (M108 in the case of your log). Try this: Go to the OctoPrint terminal and send an M114, then record the response. Then send M108 and record the response. Paste in all the results in here please. |
Watching this discussion with interest. FYI, I also have BedVisualizer but do not have OctoRant. I've only experienced this issue once and I completed another 8.5 hour print last night with successful Octolapse. In case it helps with troubleshooting, I'm running: Firmware: 4.3.1+2759 |
I tried but it seems that the firmware responds immediately to an M114, see below. I tried this from the OctoPrint terminal when the printer was idle.
I've also tried the repeated M114/M119 sequence they suggest in the Buddy issue you've mentioned but the output looked all right; no messing up of M114 and M119 responses. |
Anybody find a solution. I'm having the same issue. When I disable Octolapse, my Mini+ prints like it always has. When I enable Octolapse when I press print the print never starts. After several seconds I get a popup error notification saying my printer does not support the M114 command and that I should update my printer's firmware. |
I've added this to the milestones, but am really confused since I see people using Octolapse with a mini on youtube all the time. I think I need to get my hands on one to test with the debugger. |
The M114 test fails in Prusa Mini+ with the latest (4.3.1) firmware, OctoPi 0.18.0, OctoPrint 1.5.3, OctoLapse 0.4.1 with a GCode file from PrusaSlicer with "verbose" switched on.
As you can see below, the command is displayed in the terminal as sent and received "ok" but there's a bunch of temperature messages, which I omitted, before the actual position is returned.
Also, here is the end of the debug log:
Originally posted by @hasko in #459 (comment)
The text was updated successfully, but these errors were encountered: