fieldOfView / Cura-OctoPrintPlugin

Cura plugin which enables printing directly to OctoPrint and monitoring the process
GNU Affero General Public License v3.0
484 stars 74 forks source link

[Feature Request] add support for moonraker/mainsail #227

Closed nforceroh closed 3 years ago

nforceroh commented 3 years ago

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

fieldOfView commented 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.

fieldOfView commented 3 years ago

Unless I get information, there is nothing I can do and I will close this issue.

grigi commented 3 years ago

@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?

fieldOfView commented 3 years ago

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?

grigi commented 3 years ago

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.

grigi commented 3 years ago

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!

grigi commented 3 years ago

@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.

grigi commented 3 years ago

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.

fieldOfView commented 3 years ago

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.

grigi commented 3 years ago

I have a PR to enable at least basic functionality here: https://github.com/Arksine/moonraker/pull/102

grigi commented 3 years ago

Note the PR has been merged in. Please update moonraker and add an [octoprint_compat] section in the moonraker config file and please test.

fieldOfView commented 3 years ago

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.

hapklaar commented 2 years ago

@grigi Would it also be possible to add support for switching on the printer using the moonraker power plugin, like the Cura2Moonraker plugin does?

grigi commented 2 years ago

I don't know. I didn't pay any attention to that functionality.