Closed nforceroh closed 3 years ago
My stance on this is as follows: This plugin is primarily written to support OctoPrint. If another software chooses to implement the OctoPrint API to have software like this plugin to work with that software, I don't mind that at all. But I think it is up to the developers of that software to make sure that they implement the API properly.
I don't have a Klipper/moonraker/mainsail printer, so I don't have a way to test things. If I were to put energy towards this, I need ACTIVE involvement and support. This is as good a place as any to mention that it is possible to sponsor my efforts working on Cura plugins: https://github.com/sponsors/fieldOfView/
This plugin queries the OctoPrint API settings to check if the server on the other end is alive (and indeed an OctoPrint (compatible) server) before spamming it with update requests about the state of the printer. Having an API key in the request there is the least of your issue, I would guess.
At the very least I would need proper documentation of which parts of the OctoPrint API mainsail implements. In https://github.com/Arksine/moonraker/blob/master/docs/web_api.md I don't see any mention of OctoPrint compatibility.
Unless I get information, there is nothing I can do and I will close this issue.
@fieldOfView I did some investigation and found that what appears to be the "octorpint api compatibility" is basically just this: https://github.com/Arksine/moonraker/blob/master/moonraker/plugins/file_manager.py#L48
Which does work fine for sending files to moonraker from Slic3r and variants. The cura octoprint integration is a lot more thorough.
What would be the minimum api we need to support there so that cura will work as-is currently?
I'm basically volunteering to extend the moonraker API to work with this plugin.
Also, what would be the minimum you'd need to "support" that combination?
What would be the minimum api we need to support there so that cura will work as-is currently?
It depends on what you want the plugin to be able to do. Just uploading is extremely limited. How about starting, stopping, pausing and resuming a print. How about monitoring the progress of the print?
Let me start at the absolute minimum. That is uploading gcode and ufp files. This is the most critical part for me.
Progress monitoring and the like could be a phase 2.
Ok, I started a moonraker plugin that just defined the following paths: (each return a blank json dict {}
)
Basic gcode uploading now works.
I also see a request to GET /plugin/appkeys/probe
but the auth seems to be different (will have a look some more)
To make it progress further, the issue seems to be that moonraker wraps the responses with {"result": ... }
, which breaks things obviously. Will need to conditionally work around that so as to not break any existing code.
Could you please point me to which fields you use from the config, as that schema is huge!
@fieldOfView I have a prototype with hardcoded values that basically works here: https://github.com/Arksine/moonraker/compare/master...grigi:master
I still have to do real integration with moonraker (report real values and send gcodes on), but those harcoded fields make cura-octoprint pretty happy.
Uploads of .gcode files work, but even with faking that we have the UltimakerFormatPackage
plugin installed, for some reason Cura doesn't want to send a .ufp
file.
What are the requirements for ufp to work?
Note that this exact cura installation sends ufp files to a real octoprint system and it all works nicely there. I sourced the stubs from that installation.
Update: I got UFP uploading to work. I'm not sure what I did differently. It may just be that Cura needs to be restarted for that config to take effect.
The OctoPrint Connection plugin checks the settings json for the existence of plugins/UltimakerFormatPackage only when discovering or connecting to the instance. If it is not found, it will not send UFP files.
I have a PR to enable at least basic functionality here: https://github.com/Arksine/moonraker/pull/102
Note the PR has been merged in. Please update moonraker and add an [octoprint_compat]
section in the moonraker config file and please test.
As I said, I don't use Moonraker/Mainsail myself, but I want to thank you for your work on this. I'm closing this issue.
@grigi Would it also be possible to add support for switching on the printer using the moonraker power plugin, like the Cura2Moonraker plugin does?
I don't know. I didn't pay any attention to that functionality.
Moonraker, https://github.com/Arksine/moonraker, supports the same method as octoprint to upload gcode from CURA. The issue is that in moonraker, you don't need an API key yet. This plugin is failing to connect to moonraker because it's querying for an API config that isn't there When I try to connect to the printer, in the cura plugin, you need to add something in the api key field, which causes this http request/response on moonraker 2021-02-03 14:01:26,054 [web.py:log_request()] - 404 GET /api/settings (10.0.99.202) 11.51ms
Could we have an option that skips the whole API key validation when trying to connect to moonraker? The easiest way to set this up/validate would be to try on MainsailOS, it uses the moonraker api https://github.com/meteyou/mainsail