Skip to content
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

Spontaneous start of SD print when browsing Ultimaker 2 file list via printer rotary button #1407

Closed
ErikDeBruijn opened this issue Jul 11, 2016 · 21 comments

Comments

Projects
None yet
7 participants
@ErikDeBruijn
Copy link

commented Jul 11, 2016

What were you doing?

When using an Ultimaker 2 and going into PRINT and scrolling through the file list, the printer's firmware outputs something like:

Recv: File opened: 4AB_FI~1.GCO Size: 565162
Recv: File selected

This is recognized and updates the "File" that is selected within the Octoprint UI. So far, this is what can be expected.

What did you expect to happen?

I expect the OctoPrint + printer combination only to start printing when button is pressed, not when scrolling through a menu.

What happened instead?

While starting to scroll through the menu I experience a sudden start even without pressing the button on the printer nor pressing Print within Octoprint. The serial conversation continues like this:

Changing monitoring state from 'Operational' to 'Printing from SD'
Send: N0 M110 N0*125
Recv: ok
Send: N1 M23 4AB_FI~1.GCO*110
Recv: ok
Send: N2 M24*23
Recv: ok
Send: N3 M27*21
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
[etc]

Branch & Commit or Version of OctoPrint

Version: 1.2.9 (master branch)

Printer model & used firmware incl. version

Ultimaker 2+ with firmware 2.1 of May 11 2016 13:14:07.

Browser and Version of Browser, Operating System running Browser

Chrome 51.0.2704.103 (64-bit) on OS X.

Link to octoprint.log

Around the event, nothing new happens.

Link to contents of terminal tab or serial.log

Relevant bits show above. If needed I'd happily provide more.

Link to contents of Javascript console in the browser

No JS errors

Other info

I'm using Octoprint with the API, but to be sure nothing external is starting the job, I disable the API access under settings. I don't see data from my client accessing Octoprint anymore as soon as I do this and the print still starts suddenly (at byte 0 and without the startup sequence that the Ultimaker 2 normally starts an SD card print with (UltiGcode)).

@GitIssueBot

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2016

Hi @ErikDeBruijn,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-07-25 16:40) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 11, 2016

@jankeesvw

This comment has been minimized.

Copy link

commented Jul 13, 2016

Hi @foosel, we updated to 1.2.13 yesterday and we saw the same issue. This was the output we got:

Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0*125
Recv: echo:Unknown command: ""
Recv: ok
Send: M21
Recv: echo:SD init fail
Recv: ok
Send: M105
Recv: ok T:26.3 /0.0 B:23.8 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.0 /0.0 B:23.2 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.8 /0.0 B:23.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.6 /0.0 B:23.5 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.5 /0.0 B:23.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.0 /0.0 B:23.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:25.7 /0.0 B:23.2 /0.0 @:0 B@:0
Send: M105
Recv: ok T:26.0 /0.0 B:23.4 /0.0 @:0 B@:0
Recv: echo:SD card ok
Send: M20
Recv: Begin file list
Recv: 4PA_VO~1.GCO
Recv: 4PB_OV~1.GCO
Recv: 4PC_FI~1.GCO
Recv: 4PD_BE~1.GCO
Recv: 4_FAST~1.GCO
Recv: JIG-93~1.GCO
Recv: /TRASHE~1/501/JIG-93~1.GCO
Recv: /TRASHE~1/501/JIG-93~2.GCO
Recv: echo:Cannot open subdir
Recv: 1/
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:26.0 /0.0 B:23.5 /0.0 @:0 B@:0
Recv: File opened: 4PA_VO~1.GCO Size: 14119530
Recv: File selected
Recv: File opened: 4PB_OV~1.GCO Size: 2084107
Recv: File selected
Recv: File opened: 4PC_FI~1.GCO Size: 565162
Recv: File selected
Recv: File opened: 4PB_OV~1.GCO Size: 2084107
Recv: File selected
Recv: File opened: 4PA_VO~1.GCO Size: 14119530
Recv: File selected
Send: M105
Recv: ok T:26.0 /0.0 B:23.5 /0.0 @:0 B@:0
Recv: echo:SD card ok
Recv: File opened: 4PA_VO~1.GCO Size: 14119530
Recv: File selected
Send: M105
Recv: ok T:26.2 /0.0 B:23.5 /0.0 @:0 B@:0
@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 13, 2016

I don't see the M24 and M23 plus the switch to state "Printing" in that log, which was still contained in the one from @ErikDeBruijn (which sadly lacked what happened before though, which might be crucial).

Also please provide the list of installed plugins (it might be a plugin that is starting the print once a file gets selected, hence I'm asking for that - it's all listed in octoprint.log, but that wasn't included with the ticket ;)).

foosel added a commit that referenced this issue Jul 13, 2016

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 13, 2016

IF you set the print parameter to True in the API calls you did before switching over to the display, I think I might have found the problem now (actually by pure coincidence while looking for a different issue).

A first solution is pushed into the maintenance branch in 2cc9631, properly resetting the "start printing after selecting a file" flag once it's been "used up".

To reproduce I first sent an upload request to the server, making sure to have print set to true. I cancelled that file, then I manually issued an M23 in the terminal tab to trigger a File selected message from the printer. Print started. Applied fix. Did the same again. Print no longer started.

Can you test this against your setup?

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 16, 2016

@ErikDeBruijn @jankeesvw any chance yet to test the above mentioned fix? Asking because I hope to release 1.2.14 next week, and I'd rather verify this fixed before that ;)

@jankeesvw

This comment has been minimized.

Copy link

commented Jul 16, 2016

@foosel no sorry didn't test it yet. I can test it when i'm at the office on Tuesday. But I can tell you this how we call we the api from our app (simplified):

post(
    host: host_name,
    path: "/api/files/local/test-file.gcode",
    data: { command: :select, print: true }
)
@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 16, 2016

Definitely looks like the scenario I described then, print is set to true. My money is on it being solved ;)

@jankeesvw

This comment has been minimized.

Copy link

commented Jul 21, 2016

That's good news, let us know when you release an update, then we will update our Pi's.

I think you can close the issue for now @ErikDeBruijn.

@ErikDeBruijn

This comment has been minimized.

Copy link
Author

commented Jul 21, 2016

Hi @foosel. Finally I can spend some more time on tracking down this issue.

I cherry picked the fix (2cc9631) on master (1.2.13) and could still reproduce the problem. I did the following:

pi@ultipi002 ~/OctoPrint $ git branch
* master
pi@ultipi002 ~/OctoPrint $ git cherry-pick 2cc96317915380116bf7aa6f7646962e87ce2f6e
[master af714f2] Reset printAfterSelect once it's triggered
[...switch to root...]
root@ultipi002:~# /etc/init.d/octoprint restart

I'm using an OctoPi image.

A bit over due, but this is the list of plugins:
image
image

Later, I did the following to really switch to maintenance as you suggested:

pi@ultipi002 ~/OctoPrint $ cd ~/OctoPrint
pi@ultipi002 ~/OctoPrint $ git checkout maintenance
Branch maintenance set up to track remote branch maintenance from origin.
Switched to a new branch 'maintenance'
pi@ultipi002 ~/OctoPrint $ git log
commit d61371a495b2aff8291c31a482b18d986a69fab2
Author: Gina H<C3><A4>u<C3><9F>ge <osd@foosel.net>
Date:   Mon Jul 18 12:13:16 2016 +0200

    Make sure to include all md files in manifest
[...]

My fear is that I'm still running on 1.2.13 (master branch) somehow instead of the version with the fix. How can I confirm that your fix is in place?

With ps the line listing octoprint's process reads like this:
pi 3373 69.6 3.8 144416 33768 ? Sl 08:51 1:17 /home/pi/oprint/bin/python /home/pi/oprint/bin/octoprint --host=127.0.0.1 --port=5000

This is a more complete serial log:

[not much interesting before this point]
Send: M105
Recv: ok T:29.3 /0.0 B:29.9 /0.0 @:0 B@:0
Send: M105
Recv: ok T:29.7 /0.0 B:28.8 /0.0 @:0 B@:0
Send: M105
Recv: ok T:29.4 /0.0 B:29.4 /0.0 @:0 B@:0
Send: M105
Recv: ok T:28.8 /0.0 B:29.4 /0.0 @:0 B@:0
Recv: File opened: 4PB_OV~1.GCO Size: 2084107
Recv: File selected
Recv: File opened: 4PC_FI~1.GCO Size: 565162
Recv: File selected
Changing monitoring state from 'Operational' to 'Printing from SD'
Send: N0 M110 N0*125
Send: N1 M23 4PC_FI~1.GCO*110
Recv: ok
Send: N2 M24*23
Recv: ok
Send: N3 M27*21
Recv: ok
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: SD printing byte 798/565162
Recv: ok
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Send: N4 M27*18
Recv: echo: cold extrusion prevented
Send: N5 M27*19
Changing monitoring state from 'Printing from SD' to 'Operational'
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: SD printing byte 1294/565162
Recv: ok
Send: M105
Recv: SD printing byte 1294/565162
Recv: ok
Send: M25
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: ok T:29.3 /0.0 B:29.3 /0.0 @:0 B@:0
Send: M26 S0
Recv: ok
Send: M84
Recv: Done printing file
Recv: echo:0 hours 0 minutes

My octoprint.log is found here: http://pastebin.info/?paste=5

I'll try to run more tests today if you can tell me what to try.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 21, 2016

Hi @ErikDeBruijn, from the log it indeed looks like you are still running regular master/stock 1.2.13:

2016-07-21 08:51:54,556 - octoprint.server - INFO - Starting OctoPrint 1.2.13 (master branch)

Btw, the list of plugins can also be found in the log (which is one of the reasons I ask for it in every ticket):

2016-07-21 08:51:56,659 - octoprint.plugin.core - INFO - 6 plugin(s) registered with the system:
|  Announcement Plugin (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/announcements
|  CuraEngine (<= 15.04) (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/cura
|  Discovery (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/discovery
|  Plugin Manager (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/pluginmanager
|  Software Update (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/softwareupdate
|  Virtual Printer (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.2.13-py2.7.egg/octoprint/plugins/virtual_printer

After checking out maintenance, you also need to install the new version (same goes for applying a cherry picked patch), my guess is this is what you forgot. If you are running OctoPi:

source ~/oprint/bin/activate
cd ~/OctoPrint
python setup.py install
sudo service octoprint restart

If you are running a manual install which followed the official installation instructions:

cd ~/OctoPrint
source venv/activate
python setup.py install

and restart OctoPrint's process. Also note that you might have to adjust venv to point to the correct location of the virtual environment used for installing OctoPrint.

When you start up, OctoPrint should print

Starting OctoPrint 1.2.14.dev.<some number>+g<some commit hash> (maintenance branch)

to the log. Or

Starting OctoPrint 1.2.13.post.<some number>+g<some commit hash> (master branch)

if you cherry picked. If it still says 1.2.13 (master branch) it's not properly updated. You also can find the exact same information in the UI in the lower left corner, including branch, commit hash etc, in case you don't want to look into the log all the time.

@ErikDeBruijn

This comment has been minimized.

Copy link
Author

commented Jul 21, 2016

I was hoping it was me :)
Thanks for the clear instructions on applying the update.

When I use python setup.py install I get permission denied. Is it acceptable to use sudo for this?

@ErikDeBruijn

This comment has been minimized.

Copy link
Author

commented Jul 21, 2016

(never mind my last message, I didn't source the env file... need more coffee)

@ErikDeBruijn

This comment has been minimized.

Copy link
Author

commented Jul 21, 2016

So far I'm unable to reproduce the problem anymore so the fix does appear to work. I will test on a few more machines.

If anything changes I will reopen the issue.

Thanks a lot @foosel !

@massvoice

This comment has been minimized.

Copy link

commented Jun 19, 2018

@ErikDeBruijn @foosel I am using Ultimaker 2+ with Octopi 0.15.1. When I connect my printer to the octoprint, insert my sd card, and start the file nagivation by rotatory wheel, the print automatically starts without me pressing the button.
I guess this is the same issue.

This is my Log

Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: echo:Unknown command: ""
Recv: ok
Send: N2 M21*18
Recv: FIRMWARE_NAME:Marlin Ultimaker2; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://github.com/Ultimaker PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ultimaker EXTRUDER_COUNT:1
Recv: ok
Recv: echo:SD card ok
Send: M20
Recv: ok
Recv: Begin file list
Recv: echo:Cannot open subdir
Recv: 1/
Recv: /TRASHE~1/501/WHEEL_~1.GCO
Recv: BIGCAR~1.GCO
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:28.4 /0.0 B:24.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:28.1 /0.0 B:24.3 /0.0 @:0 B@:0
Send: M105
Recv: ok T:28.2 /0.0 B:24.4 /0.0 @:0 B@:0
Recv: echo:SD card ok
Send: M105
Recv: ok T:28.2 /0.0 B:23.2 /0.0 @:0 B@:0
Recv: File opened: BIGCAR~1.GCO Size: 7041501
Recv: File selected
Send: M27
Recv: SD printing byte 0/7041501
Changing monitoring state from "Operational" to "Printing from SD"
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M105
Recv: ok T:28.5 /0.0 B:24.0 /0.0 @:0 B@:0
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M105
Recv: ok T:28.7 /0.0 B:24.1 /0.0 @:0 B@:0
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M105
Recv: ok T:28.4 /0.0 B:24.6 /0.0 @:0 B@:0
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M105
Recv: ok T:27.9 /0.0 B:24.0 /0.0 @:0 B@:0
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
Send: M105
Recv: ok T:27.8 /0.0 B:24.1 /0.0 @:0 B@:0
Send: M27
Recv: SD printing byte 0/7041501
Recv: ok
@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 19, 2018

I guess this is the same issue.

No, it's not, not even remotely, since what's happening here can only happen since 1.3.7 ;)

It's OctoPrint thinking you started a print since your printer reported that you selected a file for printing. OctoPrint doesn't do anything on its own here, it basically "leaves the field" for your printer controller since you are using that to select files and most likely also print it. Note how it says "SD printing byte 0/7041501" there - the file isn't actually printing yet.

The problem is that there's no way to know when the printer actually starts printing the file (at least on most firmwares) so all OctoPrint can do is rely on "file got selected" messages. I'll take a look though if I can only switch to printing state once the byte position starts increasing. Most likely won't make it into 1.3.9 though.

@massvoice

This comment has been minimized.

Copy link

commented Jun 20, 2018

@foosel Thank you for the quick reply. Two things....
Will it be possible to let me know the code change which might help me, I can do it then.
Secondly, in the current version, is there no way, I can navigate and print my files from the printer's sd card while the octoprint is connected? I am using Ultimaker 2+.
Currently, as soon as I start navigating with the rotatory wheel, the file automatically gets selected, and then all that is displayed is 'printing via usb' even though nothing is being printed.

Will really appreciate any kind of help in this regard.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 22, 2018

Secondly, in the current version, is there no way, I can navigate and print my files from the printer's sd card while the octoprint is connected? I am using Ultimaker 2+.

Not if every single use of the rotary wheel on your printer immediately selects the file and has the printer produce a corresponding message on the serial interface (which btw kinda surprises me and certainly doesn't match the behaviour I've seen from other printers).

Will it be possible to let me know the code change which might help me, I can do it then.

I have something prepped on maintenance (see 5a60af9). I decided against including this change in 1.3.9 (for which I released the first RC of on Wednesday) since that felt too risky, so it won't be part of a stable release until 1.3.10.

@darkom-ltu

This comment has been minimized.

Copy link

commented Aug 9, 2018

Hello,

I was using OctoPrint to monitor my Ultimaker 2+ some time ago and due to memory card failure, I stopped for a few months. Now, finally I got time to fix the issue and I have a very similar problem as @massvoice . When I want to print from the SD card, I enter 'Print' menu and then it kind of automatically is starting to print some file with info on the printers display 'Printing from USB' or sth like that (I don't remember a right now exact message, but can get it tomorrow).

Any suggestions on how I could track down what is causing this behaviour?

@musyne

This comment has been minimized.

Copy link

commented Sep 20, 2018

FYI I have the same issue (starts on its own when I'm scrolling on UM2+).
Latest Octoprint (1.3.9), latest UM2 firmware (3.3.0)
I need to disconnect Octoprint if I want to print from the SD card.

@foosel

This comment has been minimized.

Copy link
Owner

commented Sep 20, 2018

As I pointed out above, this is a bug in the UM firmware - it shouldn't report every single file you scroll through as selected on the serial interface, only when you actually select (and start) a print should it do that.

Repository owner locked and limited conversation to collaborators Sep 20, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.