It would be really nice if my printer would sync with a git repository (or have a repository that I could push to) to print from.
Is that something that could be implemented as a plugin? I'd like to see the latest files I've pushed right on the main web page for the printer so that I can print right away.
1 Like
It may be possible.
But for me the question is why to synchronize printer files via git, for this has a certain use ?
May a cloud storage also fit your needs?
But maybe you have a reason in mind that I do not see,
When I develop my files to print, I store them on my local desktop machine in a git repository. I then have to upload the gcode file to the printer with the upload button in OctoPrint. If I could just push my latest gcodes from my git repository to the printer, it would be one less step for me to actually print the works.
Now I see. It's your local git, not the public one.
During development I noticed, after a failed print, these certain gcode files are quite obsolete. More important are the STL files. (to my opinion)
Some slicers offer the possibility to upload gcodes directly to OctoPrint. These are Slic3r, Simplyfi3D and, it I'm not wrong, Cura.
These work via the OctoPrint API and it's just a click to upload after sclicing.
On the other hand you can drag and drop your gcode file to OctoPrint too, but for this, you have the file folder and the browser with OctoPrint accessible on your screen.
It would be nice to have a well organized tree of things to print on my front page, and using git allows an easy way to accomplish that.
I do push my git repository publicly too.
I just tried to see if I could print directly from Cura to OctoPrint, but I couldn't find a way to do it.
I'll probably try drag and drop and some point, but it's fairly easy to upload new versions of a file with the current button by sorting the file picker dialog by most recently modified file.
To connect Cura to OctoPrint, here are some Links: 1) and 2)
Ah, ok, it looks like there are many versions of Cura. I'm using 15.04.4
I can see a lot of merit to this.
Currently, Thingiverse has a mechanism by which you can see a collection of files needed for a project, download all as a folder and then you continue your workflow from here.
But I don't publish on Thingiverse, myself. When I create a write-up of some new project, I store the documentation and images in a github repository. I sometimes also include the STL file(s) and occasionally the GCODE file(s) as well but these aren't usually pertinent to other people. I like your direction of thinking here on this. There ought to be a tighter coupling.
I'm not sure if I'd want a process similar to CircleCI in which—upon pushing to origin—the printer then begins to print. If this is what you want I'd at least throw a notification in OctoPrint asking if you'd now like to print this "v1.0.2", for example.
I personally would prefer a mechanism by which:
- In the plugin, you identify one or more github IDs
- There's a new side panel below
Files
which allows you to browse directly to an individual github repository and subfolder, then to select an individual file (even by tag or version)
On the plus side, git
is already included in the OctoPi image (naturally).
Your preference sounds fine to me.
I had thought about printing on push, but seems like a poor mistake could be made; I haven't thought about it much more than that.
We should stand back from all this for a moment and "think bigger". We should design in a better-than-Thingiverse workflow in which OctoPrint + github (or github competitor) now supplants it for the way to print.
Workflow Setup:
- Author of a public project creates github repository
- README.md describing the project with graphics and photos
- STL subfolder
- GCODE subfolder
-
SpecificPrinter subfolder
- IMAGES subfolder
Personally, I think the author should use tags for versioning so that earlier versions may be selected instead. I prefer the pull model in a case like this. For the push model, setting up github hooks—although do-able—might lock this in as a github-only sort of thing. I also run a local Gogs server for all my private repositories and I'm not sure if they have the same mechanism, to be honest.
The average 3D printer enthusiast doesn't necessarily know all the jargon from the git space, to be honest.
Workflow for End-User:
- User installs Plugin-X
- In Settings, user optionally adds their github or similar credentials
- In Settings, user maintains a list of repositories they wish to print from
- Back in the main screen side panel, for example, they select the short name for the repository which then displays a browsing tree
- Having selected down through the path and file they choose the default (latest on master) or they steer otherwise
- This then performs, in essence, a pull of a single file into the
~/.octoprint/uploads/repositoryname/
folder
Question: Should the filename as downloaded be decorated with the tag information? This raises a concern about discovery: A week ago, I downloaded from git a particular file. If this were on my workstation I might run git log
to see what version I'm on. I'm guessing it would be nice to see what version is in my uploads. The tag-decorated file naming mechanism could work. Or it might be necessary to insert the branch/version/tag into the standard metadata that foosel tracks for each file.
1 Like
It would really be nice to have all relevant information, of which, the version being printed seems to be arguably the most important; but, I'm not looking to take over this entire project. Along with what you are saying, it would be nice to have a 'log view' showing all the prints, how much filament was used, with timelapse in-line.
I might take it on. I'm just in crunch mode now trying to build a timelapse rail kit before the 15th.
What is a timelapse rail kit? Like a rail to move a camera on? Sounds cool.
I may take a look at this more and try to hack something in. If I can get something to get files to show up in the directory OctoPrint is expecting, maybe that will be enough for my purposes.
Something else I thought of that would be nice is a print queue.
w/ re: 'log view', I found this plugin: Print History
My girlfriend is a photographer for OutdoorProject.com and we're doing a four-day hike in Yosemite on the 17th. Just as you've suggested, imagine a 6' X-rail oriented on the diagonal and propped between two tripods. Add a Nikon, a Raspberry Pi 3B with a TFT, USB charger, stepper motor and lots of printed parts. It just has a single 2' section in this photo:
1 Like
For what it's worth, I created a slimmed-down version of the basic git pull
mechanism into a plugin. I've described it here and it's almost ready for production.