Do you have the "Store G-code on the printer SD card" option enabled? That would require pushing the file over the same USB connection that is being used by the printing.
Sorry about the delay in answering ...
Where would I find this option?
In the Connect to OctoPrint dialog from the Printers pane of the Cura preferences.
Ahhh, got it, not checked.
I will have to double check things though because I also did not select
to "show webcam image" and that has always displayed;
Some experimenting is in order!
Thanks
Jens
The camera showing even if it is not selected was a bug that has been fixed a little while ago. Please check if there's an updated version of the plugin in the Marketplace/Toolbox.
I upgraded to the latest version. When I try to print a model in Cura while the printer is busy, I now get 'CONFLICT' reported.
Thinking about this some more, it would appear to me that cueing a print while octoprint is busy might not make much sense since the new print might well run into the print that is still on the build surface (unless it waits for the operator to clear the build surface)
I get "octoprint is busy, unable to start a new job". When I click on 'cue job' octoprint returns a 'CONFLICT' error although the interface seems to have saved the print job on the pi.
Where on the pi would the print file be stored ? I don't have a microSD card in the printer so maybe it is complaining about that ?
It did not print the supposedly saved file.
When you "queue" the file from Cura, it should appear as a file in the sidebar, but it will not start printing automatically. You would have to start the print from the OctoPrint interface after the current print has finished (but you can still monitor its progress from Cura). If you have suggestions how to change the language to better explain this, let me know.
The "CONFLICT" state happens when you try to upload a file with the same filename (jobname in Cura) as the currently printing file. Normally OctoPrint (silently) overwrites the file on upload, but it can't (and won't) do this if it is currently printing the file that you try to overwrite. Could this be what is happening? If not, please open an issue at http://github.com/fieldofview/OctoPrintPlugin/issues and add your cura.log (from the Configuration folder in Cura, see Help -> Show Configuration folder)
I think that the plugin should do a better job at explaining the "CONFLICT", but I had not yet encountered it in the wild and hence have not come around to adding that.
That explains that ... yes, I used the same model and put it in several
different positions on the build plate to test things out.
Suggestions to better explain the "CONFLICT" would be to replace it with
"Can't cue file with same name as file currently printing" or better
yet, when it is determined that the same file is being attempted to be
printed, rename it with a '-x' consequential number like what happens in
many operations in Linux.
Thanks for all your help, I would have been lost without it !
I'm unclear if this the best place to provide feedback on the Cura OctoPrint plugin? Or is Github issues the preferred forum?
I'm trying to connect Cura 2 printers but the Cura Printer profile seems to use the save OctoPrint settings for both my printers. I'm using Cura 3.6 and the latest Octoprint plugin. Happy to provide more details here or else where...
Thanks.
This feedback topic is here for simple questions and feedback and for people that don't have and don't want a github account.
Yours seems to be a setup-specific issue that may require some back-and-forth between us, so I would suggest you open a github issue if it is all the same to you.
Will there be support for Cura 4.0 beta?
Yes there will.
There was a bit of an oversight in Cura 4 beta 1 and the plugin marketplace where it was not possible to publish a plugin for both 3.6 and 4.0. So I have to wait until Cura 4 beta 2 is released until I can publish an update.
1 Like
Because the release of Cura 4.0 beta 2 still has not been released, I have worked around the issue mentioned above, and created a version of the plugin that is compatible with Cura 4.0 beta 1 (and should still work with beta 2 and beyond).
http://files.fieldofview.com/cura/OctoPrintPlugin-v6.0.0-2019-01-28T16_19_16Z.curapackage
Download the file, then drop it into a running Cura application and restart Cura.
1 Like
This seems to be an amazing feature, but I cannot get it to work on both Cura 3.6 and 4.0. Did someone face an issue with the API key?
I just copy the key from octoprint into cura, but it does not work. Error message: "The API key is not valid. You can get the API key through the Octoprint web page."
Cheers,
Gabriel
Are you sure you are entering the whole API key, and nothing but the API key (no leading/trailing spaces). Have you tried the "Request" button in the Connect to OctoPrint dialog?
Yes, I verified that I am copying the whole (and only) the API key. I assume the problem could be related to my reverse proxy since I am using haproxy. I will disable it and try again.
Which request button? I don't see it.
Thanks for your reply.
It should run fine through haproxy, if haproxy is properly configured.
Could you post your cura.log (found via Help -> Show configuration folder) somewhere (dropbox, google drive, wetransfer, pastebin.com, ...) and give me a link? I'ld like to see if the plugin is doing something unexpected.
The request button worked 
The API key cura got using the request button is not the same as the one I was copying from the octoprint settings. I don't know why, but I am glad it works now.
Very nice tool Thanks!
With the "Request" button you get an Application Key. They are new in OctoPrint 1.3.10, and conceived to give you more finegrained control over which applications can access your OctoPrint instance (as well as making the copy/paste thing less prone to issues).
You can revoke access to Cura, without changing your API key (which would also revoke access to all other applications that use the API key)
See https://docs.octoprint.org/en/master/bundledplugins/appkeys.html
BETA 2 is available, does it work now?