This is a call for discussion from OctoPrint users or potential users. Recently, I registered a plugin for OctoPrint that makes it possible to send print jobs directly from within Kiri:Moto (even inside Onshape and Thingiverse) to an OctoPrint device on your local network.
The method used to make this possible is the same one used by devices like the Glowforge laser cutter and the Markforged 3D printer. Really, all cloud-connected devices do this in one way or another. In short, the device checks in periodically with a secure cloud endpoint (grid.space in this case) to see if any jobs are waiting for it. If so, the job is returned to the device. If not, the device sleeps and tries again.
The upshot: inside Kiri:Moto in the export window or local device list, you can auto-discover devices on your local network and send files to them. Hopefully you find this very useful.
I use Octoprint for my CR10s and Prusa MK2. I have yet to try the Kiri:Moto slicer for FDM printing, but I can give it a go. Would be nice to cut out the middle step of exporting from Onshape and then opening in PrusaSlicer or Slic3r.
@mjmak that would be a great test of the plugin. You should see both devices as export targets. I donāt think there are default KM profiles for those two printers. But they shouldnāt be hard to create from a sample gcode generated in another slicer.
So Iāve tried to install the plugin on my rpi3 running the latest release of octopi, and I canāt get the plugin to work. It is continually in a state of ādisabled.ā Iāve tried updating from python 2 to 3, but that didnāt help.
I think OctoPrint remembers the version of Python it was installed with. And if itās running in a virualenv built with Python2 you have to build a new one. Iām not a Python expert, but thatās my understanding.
But Iāve gone ahead and pushed a new version 0.1.3 that relaxes the Python check and allows 2.7
Youāre making. And that needs applause. I do want to give some feedback on it though, in the hopes that it helpsā¦
Iām not a big fan of it circumventing the security and going all the way to your server to get the gcode. It seems possible for malicious printer control, or even mistaken identity causing prints to show up on some other printer.
What I was expecting was a mDNS/avahi/bonjour service on the pi to advertise a websocket that kirimoto could find. That would still have security implications, but at least it was limited to the LAN.
I donāt want to naysay though. I think it is neat. The api keys are annoying to copy/paste.
I get your concern. But this is actually the way all cloud-based devices work. And there is a good reason for that. Even with bonjour/mDNS, the only way the browser can send directly to that device is if it has a valid certificate signed by a cert authority that includes the fully qualified host name of your device. That is a very tall order. It means your device has to exist in DNS with a name that matches a cert from a valid authority and not self-signed. bonjour only gets you part of the way there.
Whether you use this convenience method is all under your control. You can just as well download the gcode then drag/drop it onto the device instead. Closed systems donāt give you that choice.
One thing I can do is to provide an encryption layer on top of the already encrypted link. This already uses https to transmit the job in both directions. But if you want to hide the contents from the server pipe (and it is a pipe ā no files are stored), we can encrypt it in Kiri:Moto with a key you set there and on the GridBot and have it decrypt the file bounced off the cloud. This does address your concern about anyone else peeking at the contents or going to the wrong device (which is very difficult to imagine how this happens when you dig into the mechanics).
And the more I think about that, the more I like it. So I will include that in the next release of this plugin and the GridBot control software.
Finally trying this out. Was not succeeding and after installing the plugin on my Creality Octoprint rig and updating the system, now my ancient rPi 1B is just taking too long to do anything. Whatever I added or changed was too much. So I am just trying to connect to my Prusa to see if I can upload.
Ah. With the OctoPrint Plugin, you enable Grid.Local and disable the OctoPrint (legacy) facility. Then your OctoPrint printer shows up as a GridLocal device and you donāt have to enter anything by hand.
I was looking for documentation and missed this page for some reason. I assumed it was somewhere but kept getting sidetracked to the Octoprint pages and the slicer plugin rather than the github home.and the spooler.
Yes, this is exactly what I was looking for. Iāll check it out tonight when I get home from work.
I have to put in a new thermistor for the Prusa. My fourth one. Pain really. I did get some new capton tape. I was using the original bit still to manage.
Still need to fire up the MPCNC again and try that spoon carve.
Iām sorry Iām confused. I am not understanding something here.
I have an object in the Kiri:Moto extension for Onshape. I did the slicer settings for the Prusa. I unclicked Octoprint in the export prefs and check Grid:Local.
Now when I go to export, nothing shows to export to, just the download gcode.
I do have the GridSpace plugin installed on Octoprint and I enabled CORS support and restarted/rebooted.
Sorry to be obtuse here. Was able to figure out the CNC and get it to work well as with the laser. Sending it to my Octoprint connected printer is not happening.
With the OctoPrint-GridSpace plugin, you donāt need to enable CORS or do anything else. When the plugin is working properly, it will add a tab to OctoPrintās interface.
Back again after a slight detour chasing down errors that I thought might be an issue, such as out of date installations of Octoprint.
First was I totally messed up my rPi 1B installation for the Creality in updating and upgrading everything. Then when I went to update and upgrade my rPi 3b+ with latest Octoprint and that kept failing. So I did a fresh install of Octopi on each of these to get to a neutral platform that I know should not put any obstacles in like out of date Python or something.
Another side issue from redoing the rPi 3b+ was that I got a strange error message that I couldnāt add any plugins, that the system was throttled down. Arg. So I went through logs and discover that I have been getting undervoltage errors and that system has been down throttling. That was why I always had issue getting wifi to work on the board. So I learned about power requirements. Weird that this was with the original Canakit power plug that should be delivering enough. Not sure why. So I found a USB wall wart that can do 3 amps and got the shortest micro USB cable I had and now no low voltage errors.
So both systems are back in action and running Octoprint fine. All systems updated and functioning.
Now back to the task at hand. I loaded the GridSlpace plugin: crickets!
Iām stumped here. I am expecting that after installing the GridSpace plugin for Octoprint for my Prusa, I should be able to find that printer as a target to export to from the Kiri:Moto instance app window I have in Onshape with no further installs or tweaking.
Am I missing something obvious. Iām sorry to be a bother.
By any chance have you selected a version of Kiri (through the chooser) other than current (2.2)? Is your OctoPrint device on the same network as the computer you are using? The expected configuration is that they are on the same internal home network behind a NATād firewall. Are you maybe on a VPN or doing something else that would cause your device and computer to appear on the internet as coming from different IP addresses?
Same network at home behind normal firewall. I havenāt done anything particular to the router, other than reserving addresses for the Octoprint servers and giving them names.
No special firewall rules or VPN. Charter cable modem. Netgear wireless router. Ethernet connection to the rPi running Octoprint and wireless from laptop.
Whatās also interesting is that the current version of Kiri is v2.2.2, not v2.2.1 that your dialog shows. Perhaps a cache between you and grid.space is ignoring proper specs and serving up stale / wrong data.
I believe this is a caching issue between you and the grid.space servers. So I have pushed a client update that should prevent cached responses when looking for local devices. Please do a forced refresh of your browser page or clear your browser cache. If you get v2.2.2 for Kiri, then local device lookups should start working.
I noted the warning that popped up about older version in cache. Cleared cash and refreshed in Chrome in all the different instances. Nothing. All say 2.2.2 now.
I fired up Edge which I have barely used, only for testing browser compatibility issues. Nothing.
And the same with Firefox. Both for the Octoprint client page and plugin and for Onshape and the GridSlpace/kiri server. Tried it all.
Not even sure where to look for clues. Nothing in my syslog or other logs indicate anything. octoprint log doesnāt mention anything about the plugin.
Tried it on the MPCNC Octoprint server, which I donāt use but use the CNC.js app. Nothing there.
Tried it by doing https:// for the local Octoprint server, but nothing showing up.
I am missing some major thing or something obvious that I should know.
No deal breaker for me since I use Kiri mainly for laser and CNC, but to be able to upload to CNC.js straight would be nice.
Still, if I could get the FDM thing to export to Octoprint, and the slicing settings give good results, that would be a great workflow.
Ok. Taking a break to cook dinner. I need to give this a rest because I still have to put a new thermistor on the Prusa bed and while I am at it I need to redo the PEI sheet. Iāve done that once before and once I realized that GooGone is the thing that gets the adhesive off best, it went smooth. Used a gallon ziplock of flat ice block to child the PEI before removal and that worked like a charm.
Sorry to be a bother, but at least after working through this I can be of assistance on the forum for sure.
