Octoprint: When using /api/files/... with Print:TRUE - Returns 204 always except when in Error

Created on 18 Apr 2020  路  4Comments  路  Source: OctoPrint/OctoPrint

What were you doing?

Connecting to octoprint with the API interface, selecting a file and having it print immediately.

Looking for the 409 response code when there is already a print in progress (documentation says anytime it's not Operational when the request is made it should return 409)

Returns 204 even when in the middle of a print job

Code being used;


def print_file(directory,file):     # Sends print job to ocotpi
    url = "http://" + str(OCTOPI) + "/api/files/local/" + str(directory) + str(file) + "?apikey=" + str(OCTO_KEY)

    post_values = {
        'command':'select',
        'print':True,
        }

    run_request = requests.post(url, json = post_values)
    result = run_request.status_code

    return(result)

test code for checking that 409 is returned:

for i in range(10):
    print(print_file('Utility_Prints/','extents_square_v2.gcode'))
    time.sleep(1)

What did you expect to happen?

Expected 409 code returned

What happened instead?

had 204 code return

Did the same happen when running OctoPrint in safe mode?

Yes

Version of OctoPrint

1.4.0

Operating System running OctoPrint

OctoPi 0.17.0

Printer model & used firmware incl. version

grbl custom plotter

Browser and version of browser, operating system running browser

python in command line on OSX

Link to octoprint.log

Link to contents of terminal tab or serial.log

Link to contents of Javascript console in the browser

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

Yes

bug done

Most helpful comment

Thank you for taking a look! That's a great resolution.

All 4 comments

"not operational" means not connected. It's also operational when it's already printing, so the behaviour here is as documented.

However, that behaviour is suboptimal, it should in fact return a 409 not only when the printer isn't operational but also when it already has an active print job and not just fail in selecting and printing silently. Will adjust implementation and docs accordingly.

Solved by the above commit, to be released with 1.4.1.

Thank you for taking a look! That's a great resolution.

Was this page helpful?
0 / 5 - 0 ratings