Not sure if I should post this here, on in the Robo R2 forums or in the Cura forums...
I installed on Cura the plugin to connect with Octoprint and be able to send the prints directly to the printer after the slicing.
But when Cura tries to send the file, I receive the message:
Can't store the print job on the printer SD card
I'm imagining the first issue is related, maybe, with the permissions to write on SD.
Also, maybe the problem with the free space.
Robo R2 has internal storage, probably bigger than the SD card from raspberry.
So... is there any way to fix this?
Or maybe a way to upload from Cura directly into the internal storage of R2? Octoprint already do this if I upload the file through Octoprint. But if I use Cura, looks like it trying to upload the file intro raspberry SD card.
The message Can't store the printjob on the printer sd card. is shown in Cura when OctoPrint returns a 409 http response code when uploading to the printer sd card.
As always, we need logs to see what is going on. In this case, both octoprint.log (from octoprint) and Cura.log (from Cura).
Without logs, I can only guess; You cannot store a file on the printer sd card when the printer is printing. You also can not upload a gcode file with the same name as the file that is currently selected in OctoPrint.
Thanks for the partial log, but could you post a link to a more complete log? The part you highlight indicates a problem that I need to fix, but it does not lead to the "Can't store the printjob" error, so there is something else going wrong as well.
Could you also post the output of http://[your printer]/api/printer?apikey=[your api key]? It is strange that the flags lemma does not contain a pausing flag, but apparently does contain an error and closedOrError flag.
Edit: What version of OctoPrint do you use? The pausing flag was introduced in OctoPrint 1.3.7, three years ago. Is it possible to update to a newer version?
You might want to remove that API key, it is a secret.
Unfortunately, Robo3d have made it unnecessarily hard to see what the difference is between OctoPrint and roboOctoPrint (making their own life harder in the process), but there seems to be a significant difference between what the roboOctoPrint API returns and what OctoPrint returns on `/api/printer'. I can make my plugin robust against this one difference, but it is hard to see if that is the only difference I would have to support. Currently you are using something that looks like OctoPrint, but behaves different than OctoPrint.
@OutsourcedGuru, do you have anything to add here?
At the very least, roboOctoPrint lacks this commit:
Hey, I used to contract for Robo 3D and I own a Robo C2 myself. I eventually just replaced/modified many things about my printer to include the roboOS and their resistive TFT screen, for example.
The particular error message suggests that it's trying to upload/store the gcode file to the Robo board's SD card (possibly). You really want it to go to the microSD card that's in the Pi 3B computer in the base of the printer.
Somewhere behind-the-scenes, the OctoPrint REST API's upload accepts a path. I seem to recall that local in that path is the microSD card. I'm guessing you don't want that to be sdcard in your case.
Out of curiosity, what changes did you make on OS and TFT screen?
I imagine if was not the OS the printer is like a "common" printer, without the limitations from OS.
Due the OS I can't upgrade the PI version and the Octoprint version.
About the SD, is there an SD also in Robo board?
I'm not sure witch one is that one appear on the screen (TFT). I'd like to upload the file into the storage I can access via display.
@OutsourcedGuru, I was hoping you could shed some light on the difference(s) between OctoPrint and roboOctoPrint. Are there likely more "dragons" on the road of supporting it like the missing commit I pointed out?
Good god. roboOS (and their related Marlin fork) is a train wreck, to be honest. The manager in charge of software development—by his own admission—knows nothing about software.
They have two repositories: the actual one and the public one which is just there "for show" to pretend to be open-source compliant. This should be obvious from the commit history. So, don't try to go-to-school on their repository, in other words.
They had a contractor build the TFT menuing interface then probably screwed him over because he didn't work with them after that. They had someone else write the plugin which completely "re-arranges the deck chairs on the Titanic" with respect to the UI. Imagine hundreds of lines of jQuery to hack away at some old OctoPrint version of the interface. Nobody there can maintain that code, it's spaghetti at this point. That dude wasn't work there by the time I arrived.
From a strict difference standpoint, though, the web interface involves a plugin which clobbers screen elements out of existence using jQuery and then moves/adjusts-in-real-time useful parts of the interface using a different CSS theme, basically. It's like somebody didn't realize that they could have used CSS before a certain point in time. The TFT interface looks beautiful and supports both C2/R2 printers with slightly different sized screens and a blue-versus-red theme throughout. All this results in a laggy page reload for the user, of course.
The Marlin fork at some point got really stupid. The lead coder and the software development manager cooked up some crazy mod which involved introducing something like G35/G36 to do some dodgy behavior with respect to Z-offset. I just listening with my mouth agape, it was that crazy. And they rolled that out to the customers knowing full well that everyone's printer would "air print" about an inch over the bed.
And let's not forget that they promised to look into sponsoring for a long time while trying to syphon off know how and consulting from me for free off and on for at least a year and then suddenly vanished once I told them we need some written consulting contract first before I'd continue to help them in any way.
And I still got all the emails to proof that, in case one of them is reading along here and is now thinking about trying to pressure me into silence...
OK, drama aside, my stance is that my plugin is meant to interface with OctoPrint, not with some half-baked fork of OctoPrint. If it works with a fork, that's great. If there are minor adjustments that I can make to make the life of users of that fork better, then I'll give it my best effort, though at a low-ish priority. I'll always advise to use the real OctoPrint instead.
I saw this issue after selecting "Store G-code on the printer SD card". Deselecting this option in the Cura-> Settings -> Printer -> Manage Printers -> Connect OctoPrint -> "Store G-code on the printer SD card".