search

Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.03k stars 5.19k forks source link

klipper via docker? #358

Closed mentaluproar closed 5 years ago

mentaluproar commented 6 years ago

Are there any plans to put klipper in a docker format? I think running it off a pi running alpine linux would be a good idea rather than using octopi.

MrKekson commented 6 years ago

Mind blown! We could run it on anything. Are you planning to develop it, or just asking, because i can investigate it if needed. I mean, theoretically, it must not be a problem, but running a container, on a pi, while it need some real time data transfer outside from the container, worth testing before.

oderwat commented 6 years ago

I am using it (running on a RasPi) over a serial connection directly in Simplify3D. The problem with using Klipper outside of OctoPrint is, that you (usually) can't use the pseudo serial file with any of the available hosts (Cura / Simplify 3D / Repetier Host), because they scan for real hardware serial devices.

I also have Klipper directly on my iMac. You could easily run it on any Linux PC too. I am pretty sure it will run on Windows too. There is no need for Docker from that point of view. But running it directly on my Mac does not really help anything, because the Hosts don't use it. So I had to come up with a solution which really adds a hardware serial into the equation.

Besides that, the hardware serial support inside of Docker can be a problem. There is currently no way to attach the printer to a Klipper version which is running in a Docker container on Mac (I did that too). Not sure if that would work with another VM. There is also a QEMU based emulator which could run Klipper and emulate the RasPi, there is just no reason to do that. Klipper is written in Python with some cffi.

gdachs commented 6 years ago

I am using Klipper on an Odroid C2 and Ubuntu. So there is no real need to use Docker for getting Klipper to run on an OS other than OctoPi.

MrKekson commented 6 years ago

Imho, bundling clipper, with a octoprint into a container, would be nice. If you need multiple instance of both, then it would be just a click of a button to bring an other printer online, but it should not be a problem with a bit of a techical knowledge without docker, so yeah, still not sure if it's worth the time. But an interesting idea non the less.

Also, this "Besides that, the hardware serial support inside of Docker can be a problem." is an interesting problem too.

On 27 May 2018 at 14:53, gdachs notifications@github.com wrote:

I am using Klipper on an Odroid C2 and Ubuntu. So there is no real need to use Docker for getting Klipper to run on an OS other than OctoPi.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-392328987, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BojWDKMEqAkN_sWmSVaGO2Nv0EvEwks5t2qHQgaJpZM4UOwp9 .

-- Oli

oderwat commented 6 years ago

If you run it on the main machine using a second printer is just running another klippy.py with another printer config and virtual device name.

mentaluproar commented 6 years ago

I don’t have the skill to dockerize anything. I ask because alpine boots fast and doesn’t need shutdown when you are done. Just turn off the printer. It’s a better fit here than octopi.

Docker is just an easier way to get it working on alpine. I want the machine to be able to print without my laptop connected to it. I am going to look into throwing it the root account on alpine, adding an Lbu-commit instruction to octoprint, and we should be on our way. Getting the touchscreen and camera working might be an issue but if need be I can run it without.

hg42 commented 6 years ago

using a second printer is just running another klippy.py with another printer config and virtual device name.

...and another log file (-l $logfile)... I did it once and it worked as expected.

May be python (and C) runs on more machines than docker?

However, docker could eventually help to prevent conflicts. On a dedicated machine this shouldn't be a big problem, but on a machine with thousands of packages they sometimes conflict. Mainly ARM compiler and python. Python modules are already in their own virtual environmant, so they don't conflict. But up to now Klipper fits in anything I changed on my machine. And on my machine packages are changed/updated at least once a day.

Another advantage of docker could be that the system is clearly defined and each variant can be tested more easily by developers. But I think this isn't one of the usual problems.

Users could benefit from a predefined environment (if installing docker is easier for them). Releasing klippy and binaries for each common MCU/board could be another way to simplify that.

However, some usual user problems like choosing a serial device, moving without homing etc. won't be solved.

KevinOConnor commented 6 years ago

FYI, I personally don't have plans to implement a docker container for Klipper. I'm open to it if someone wants to do the development and documentation for it.

-Kevin

sillyfrog commented 6 years ago

I have just finished doing this over the weekend (it has both OctoPrint and klipper in the same container, not ideal, but only way I could get it going). I'll post on my github page in the next 24 hours for those that are interested (it's very much for my setup, so happy for someone to take it and make it as generic an they wish).

oderwat commented 6 years ago

@sillyfrog where and how are you running docker for that? I made an image some time ago but could not get it to work with the docker app on OS X. I could not access the hardware serial of the host. This is/was a limitation of the docker app for OS X. I was not keen to run it on a full VM after finding out that the virtual serial port is not being useable from Simplify3D anyway. I still would love to check out your work and compare it to what I had done.

sillyfrog commented 6 years ago

This is basically what I'm running at the moment. It's not an optimised Dockerfile by any means, however it's working well for me, and provides the isolation and repeatability of all of the various libraries etc I like. It also includes mjpg (and can run several instances), so if you don't need that, you can probably cut out over half of the file. It also includes all of the OctoPrint plugins I use. See here for all the details: https://github.com/sillyfrog/OctoPrint-Klipper-mjpg-Dockerfile

@oderwat I am running this on Linux, so no issues with the serial port. I'm not sure if the new(ish) HyperKit support in Docker for Mac would make the serial ports work - based on testing just now for 2 seconds, the answer is still no unfortunately :( - but I didn't really try very hard. Good Luck!

oderwat commented 6 years ago

@sillyfrog I can run it directly on the Mac (using virtualenv of course) so there is not really a problem with that. I just like to experiment with stuff. Will check it out later 👍

slipstreamliner commented 6 years ago

I know know why this didn't hit me before.. I have no experience in the creation of docker containers, but I use them in a ridiculous number of ways(Zeit and Docker are easymode webapp dev). Thanks sillyfrog! One thing that doe occur to me is that the virtualenv isn't actually necessary since the python instance would be localized to the docker container. I don't know how many performance gains you'd get, but just a thought. Given what Microsoft is doing with IOT core,the number of aging devices around that can run lightweight linux, and the ever expanding array of mcus/socs, using docker is flat out brilliant.

slipstreamliner commented 6 years ago

@oderwat I think I can help you with that issue in a number of ways.. also, if you're interested in collaborating on an optimized version of this I am down to learn.... I feel like this could eliminate one of the hurdles many people face when they approach Klipper.

sillyfrog commented 6 years ago

@shoreliner Good point on the virtualenv, I did try initially to not have it, but OctoPrint really wants it, and given there is no real overhead, I just left it there :)

If I can help at all, let me know. Some things that I found from my messing around:

I think the main thing to simplify it is pulling out the mjpg install, it's broken up in sections, so it should be a case of deleting the relevant lines.

Good luck!

sillyfrog commented 6 years ago

I have just pushed a couple more files to my repo, a cut down Dockerfile with just OctoPrint and Klipper support. This build supports making the binaries in the docker container as well, so everything can be done in one place. It's basically untested, so any feedback welcome.

mentaluproar commented 6 years ago

when I get a moment, I'm going to have to test that. I'm on a pi64 setup right now and taking a break from klipper to finish up some other projects. I'm glad this idea got traction.

slipstreamliner commented 6 years ago

Hey, thanks man.. I'll take a look tonight and put it through some simulavr tests.. just looking for toolhead latency changes really.

On Thu, Jun 7, 2018 at 5:09 PM, mentaluproar notifications@github.com wrote:

when I get a moment, I'm going to have to test that. I'm on a pi64 setup right now and taking a break from klipper to finish up some other projects. I'm glad this idea got traction.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395565893, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQcKW_wiez542DQ7lYPlMB89LIbXmks5t6ZaGgaJpZM4UOwp9 .

mentaluproar commented 6 years ago

if this works in docker, I just need to get the tft working in alpine, and a stable alpine boot on the 3b+ and I'll have a 3d printer IMMUNE from filesystem corruption BS. One of my biggest beefs with octoprint is how fragile such a setup it is compared to something like a duet.

On the other hand, octoprint integrates with literally everything, so it's not like it's all sacrifice.

slipstreamliner commented 6 years ago

I like that you included your udev rules as well -- I still haven't had time to sit down and really learn docker to the level I normally operate at. Seems like we may be able to do some parameterization... this may be the absolute best way to introduce new users to Klipper.

On Fri, Jun 8, 2018 at 3:27 AM, Dave Hargrove davidh976@gmail.com wrote:

Hey, thanks man.. I'll take a look tonight and put it through some simulavr tests.. just looking for toolhead latency changes really.

On Thu, Jun 7, 2018 at 5:09 PM, mentaluproar notifications@github.com wrote:

when I get a moment, I'm going to have to test that. I'm on a pi64 setup right now and taking a break from klipper to finish up some other projects. I'm glad this idea got traction.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395565893, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQcKW_wiez542DQ7lYPlMB89LIbXmks5t6ZaGgaJpZM4UOwp9 .

slipstreamliner commented 6 years ago

This is actually one of my primary thoughts as far as file system immunity, etc... I am envisioning a "klipper printer" docker file, that is initialized by the user... almost like a VM. .just a.... V3Dp.

~shoreline

On Fri, Jun 8, 2018 at 3:34 AM, Dave Hargrove davidh976@gmail.com wrote:

I like that you included your udev rules as well -- I still haven't had time to sit down and really learn docker to the level I normally operate at. Seems like we may be able to do some parameterization... this may be the absolute best way to introduce new users to Klipper.

On Fri, Jun 8, 2018 at 3:27 AM, Dave Hargrove davidh976@gmail.com wrote:

Hey, thanks man.. I'll take a look tonight and put it through some simulavr tests.. just looking for toolhead latency changes really.

On Thu, Jun 7, 2018 at 5:09 PM, mentaluproar notifications@github.com wrote:

when I get a moment, I'm going to have to test that. I'm on a pi64 setup right now and taking a break from klipper to finish up some other projects. I'm glad this idea got traction.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395565893, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQcKW_wiez542DQ7lYPlMB89LIbXmks5t6ZaGgaJpZM4UOwp9 .

mentaluproar commented 6 years ago

or if you want to go crazy for the sake of crazy, have the pi netboot, then fetch the docker container off a server! bwahaha!

My irrational hatred of SD cards is taking me to the crazy place again.

slipstreamliner commented 6 years ago

Upon init, the dockerfile would prompt the user for input. After providing details, which would include sed'ing the printers to an arbitrarily defined name(symbol links via udev or /serial/by-id), MCU info, and other config details(or preset configs) we'd create the actual docker image for that priner.

On Fri, Jun 8, 2018 at 3:39 AM, Dave Hargrove davidh976@gmail.com wrote:

This is actually one of my primary thoughts as far as file system immunity, etc... I am envisioning a "klipper printer" docker file, that is initialized by the user... almost like a VM. .just a.... V3Dp.

~shoreline

On Fri, Jun 8, 2018 at 3:34 AM, Dave Hargrove davidh976@gmail.com wrote:

I like that you included your udev rules as well -- I still haven't had time to sit down and really learn docker to the level I normally operate at. Seems like we may be able to do some parameterization... this may be the absolute best way to introduce new users to Klipper.

On Fri, Jun 8, 2018 at 3:27 AM, Dave Hargrove davidh976@gmail.com wrote:

Hey, thanks man.. I'll take a look tonight and put it through some simulavr tests.. just looking for toolhead latency changes really.

On Thu, Jun 7, 2018 at 5:09 PM, mentaluproar notifications@github.com wrote:

when I get a moment, I'm going to have to test that. I'm on a pi64 setup right now and taking a break from klipper to finish up some other projects. I'm glad this idea got traction.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395565893, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQcKW_wiez542DQ7lYPlMB89LIbXmks5t6ZaGgaJpZM4UOwp9 .

mentaluproar commented 6 years ago

It's possible to do this even cleaner. Just load the docker image, have it output the IP address and printername.local address it can be found at. Have all settings set up like when octoprint first boots, and add a few pages somehow for any klipper stuff (like uploading your printer.cfg file). Then, have it commit changes to the docker container and restart it. Every time it starts up, it would output the printername, IP address, and port to locate the machine at.

To prevent corruption, dont even write to the card unless an update or config change is made. Uploaded a gcode file? into ram you go! We don't need it to survive reboots so why put it on the card at all?

slipstreamliner commented 6 years ago

Well, I have forked the repo and will be doing some work tonight but mostly tomorrow... if we all work together on this we could really improve the overall delivery and understanding of Klipper.. one thing to pay attention to is also that Klipper does not need octoprint. in fact, Klippy in virtual-sd mode will print gcode from the command line. So again, a revision:

octoprint should not be part of the docker image, we can simply pass gcode to the docker image.. which, at this point, could simply be the klipper mount point... hmmmmm.

On Fri, Jun 8, 2018 at 3:48 AM, mentaluproar notifications@github.com wrote:

It's possible to do this even cleaner. Just load the docker image, have it output the IP address and printername.local address it can be found at. Have all settings set up like when octoprint first boots, and add a few pages somehow for any klipper stuff (like uploading your printer.cfg file). Then, have it commit changes to the docker container and restart it. Every time it starts up, it would output the printername, IP address, and port to locate the machine at.

To prevent corruption, dont even write to the card unless an update or config change is made. Uploaded a gcode file? into ram you go! We don't need it to survive reboots so why put it on the card at all?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395678855, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQWl0OXm54xZLqRLPNVr7FXMcmOs0ks5t6ixVgaJpZM4UOwp9 .

mentaluproar commented 6 years ago

How does virtual SD work with octoprint? Would it still allow on-screen tool path drawing? Sensonrs and controls? I haven't used it yet.

slipstreamliner commented 6 years ago

Within Octoprint? No... but keep in mind the only thing Octoprint is doing here is connecting to /tmp/printer as its serial connection. You'd still be able to visualize your gcode in any other application.. there are a million ways to solve this issue.. but primarily, things work out like this and we would want to optimize the docker image as such.. best said here describing Klippy's flow:

"Initial execution starts in klippy/klippy.py. This reads the command-line arguments, opens the printer config file, instantiates the main printer objects, and starts the serial connection. The main execution of G-code commands is in the process_commands() method in klippy/gcode.py. This code translates the G-code commands into printer object calls, which frequently translate the actions to commands to be executed on the micro-controller (as declared via the DECL_COMMAND macro in the micro-controller code).

There are four threads in the Klippy host code. The main thread handles incoming gcode commands. A second thread (which resides entirely in the klippy/chelper/serialqueue.c C code) handles low-level IO with the serial port. The third thread is used to process response messages from the micro-controller in the Python code (see klippy/serialhdl.py). The fourth thread writes debug messages to the log (see klippy/queuelogger.py) so that the other threads never block on log writes."

Here's what you need to give Klippy:

######################################################################

Startup

###################################################################### def arg_dictionary(option, opt_str, value, parser): key, fname = "dictionary", value if '=' in value: mcuname, fname = value.split('=', 1) key = "dictionary" + mcu_name if parser.values.dictionary is None: parser.values.dictionary = {} parser.values.dictionary[key] = fname def main(): usage = "%prog [options] " opts = optparse.OptionParser(usage) opts.add_option("-i", "--debuginput", dest="debuginput", help="read commands from file instead of from tty port") opts.add_option("-I", "--input-tty", dest="inputtty", default='/tmp/printer' , help="input tty name (default is /tmp/printer)") opts.add_option("-l", "--logfile", dest="logfile", help="write log to file instead of stderr") opts.add_option("-v", action="store_true", dest="verbose", help="enable debug messages") opts.add_option("-o", "--debugoutput", dest="debugoutput", help="write output to file instead of to serial port") opts.add_option("-d", "--dictionary", dest="dictionary", type="string", action="callback", callback=arg_dictionary, help="file to read for mcu protocol dictionary") options, args = opts.parse_args() if len(args) != 1: opts.error("Incorrect number of arguments") start_args = {'config_file': args[0], 'start_reason': 'startup'}

On Fri, Jun 8, 2018 at 4:00 AM, mentaluproar notifications@github.com wrote:

How you virtual SD work with octoprint? Would it still allow on-screen tool path drawing? Sensonrs and controls? I haven't used it yet.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-395681820, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQXSDHz2BD_usQppcipM3RdIaMChDks5t6i8ZgaJpZM4UOwp9 .

KevinOConnor commented 6 years ago

Is this still being worked on? Is this something that could be checked into the Klipper repo (documentation and/or scripts)?

Thanks, -Kevin

sillyfrog commented 6 years ago

I'm still working on it - it's specific to my needs, but shows how it can be done. It integrates OctoPrint into the same container to allow the virtual port to work. I'm more that happy to put in a PR for it if you are interested, it would combine OctoPrint/Klipper and a few other tools into a single container.

(For reference, my current implementation is here: https://github.com/sillyfrog/OctoPrint-Klipper-mjpg-Dockerfile )

Let me know your thoughts and I can get started on a PR.

MrKekson commented 6 years ago

Why not put Klipper into an image, so anyone could compose any stack of tool combination, but the klipper image itself won't contain anything else. May not even need octopi since pronterface can run klipper too if i'm right.

On Sun, 1 Jul 2018 at 00:54, sillyfrog notifications@github.com wrote:

I'm still working on it - it's specific to my needs, but shows how it can be done. It integrates OctoPrint into the same container to allow the virtual port to work. I'm more that happy to put in a PR for it if you are interested, it would combine OctoPrint/Klipper and a few other tools into a single container.

(For reference, my current implementation is here: https://github.com/sillyfrog/OctoPrint-Klipper-mjpg-Dockerfile )

Let me know your thoughts and I can get started on a PR.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401571282, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1Bos449pUcMjoYAX5PgUB8OEbLLaLoks5uCAGugaJpZM4UOwp9 .

-- Oli

sillyfrog commented 6 years ago

@MrKekson It would be very easy to put it into it's own container (the section is marked in the Dockerfile), however I have been unable to get the virtual port exposed outside the docker container, so that means that whatever is driving it also needs to run in Docker. Pronterface has a GUI (best I can tell, I have not used it), so this could not run inside docker (sanely, I have seen people doing it). I figure most people will want something like Octoprint as it provides a web interface, and will play nicely with Docker.

One solution would be to have Klipper expose the port via TCP rather than a virtual socket - not sure this would be even possible if it's emulating all features of a serial port (things such as RTS, CTS etc, not sure, not looked at this part of the code). The other end, eg pronterface would then also need to support connecting to a TCP socket rather than a serial port - so quite a number of changes to make it all happen.

oderwat commented 6 years ago

@sillyfrog it works with ser2net (in docker)and socat (to setup the virtual port on a host). I did that already. But the virtual port socat creates will not be useable with any of the available slicers or controller (at least it was not on my Mac. I don't own a Windows system). Afaik the only one which can be made using the virtual serial port is OctoPrint. There may be other solutions at least for windows if you find a hardware serial port emulating driver which can be connected to the ser2net or another software running inside docker. I stopped searching because I found another way to use Klipper as I wanted to.

slipstreamliner commented 6 years ago

Please let me know if you need help in any particular aspect of the dockerfile. I will jump in to any bottlenecks(reviewing the ones above and will see what I can do after this is sent). Now, let's step back a bit. We've got a fork that's developing the Duet web interface to use w/ Klipper as Octoprint; this requires very little optimization as a docker container. So, keeping in mind that were are going to keep seeing different iterations of how people want to control Klipper(we've got button code, we've got the Tornado integration with duet web, we've got the normal installation, and we really have a 5th type of installation/control which would simply be running in VSD mode and feeding gcode without octoprint or any additional control. This seems like it may be time put forth some suggestions for further requirements on Klipper docker containers; I am seeing this now as the best way to deliver a good experience to people that want an easy setup that is configured for them... Docker's workflow for updates works wonderfully for this as well... no additional work on our part besides compiling the individual 'flavors'.

As for @sillyfrog's concern and Hans response, I believe ser2net can be easily used answer to this bridging question.. but, as I said, perhaps if we could all think about these different variants we are beginning to see.. it would certainly help us develop and maintain good documentation to get this sorted out asap. I think among the suggestions made here in this thread, a sort of mixture of these things should provide us with a much better modular, environment-neutral version of Klipper to people with less command line familiarity than most of us.

Thanks,

Dave

On Sun, Jul 1, 2018 at 8:38 AM, Hans Raaf notifications@github.com wrote:

@sillyfrog https://github.com/sillyfrog it works with ser2net and socat (I did that already). But the virtual port socat creates will not be useable with any of the available slicers or controller (at least it was not on my Mac. I don't own a Windows system). Afaik the only one which can be made using the virtual serial port is OctoPrint. There may be other solutions at least for windows if you find a hardware serial port emulating driver which can be connected to the ser2net or another software running inside docker. I stopped searching because I found another way to use Klipper as I wanted to.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401604104, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQUEMv3pNe-fyUb6PrmALlwO-l2teks5uCMLJgaJpZM4UOwp9 .

slipstreamliner commented 6 years ago

Kevin -- can we defer to you for this? I mean, what do you envision as a more clean, simple way of installing and using klipper? I feel that since repetier-host picked klipper up, exposure is going to grow rapidly and instead of a github full of angry people that have never touched a *nix box, if we could act quickly enough we might be able to put a more user friendly install method out there.. which, seems to be your intention. =) Also, I need to chat with you about a hardware thing that has come to light(and to my house) and I want to ensure you're aware -- all good things. I'll reach out.

Dave

oderwat commented 6 years ago

@shoreliner I actually think that docker is even more complex to use for some people. I don't see why klipper can't just get a "binary" distribution and being installed as package/homebrew or even with an legit installer. I deployed some of our own Python based software for Windows and Python in the past. Having a self contained installation with py2exe is kinda easy to do. You can even add automatic updates. For example by using the Github releases. Maybe the problem here is having avrdude and stuff on Windows (probably... I don't use Windows since years). The real problem (in my eyes) is how to interface to Klipper from "any host" software. As long as this is an OctoPrint only solution there will be hurdles for users which just don't want to use that.. even if installed on the normal host computer.

slipstreamliner commented 6 years ago

I though you could actually distribute docker instances through windows installers? Could be wrong there... I will have to revisit that. However, because Klipper is a mixture of both python and C(for actual movement execution), is py2exe robust enough to handle this sort of an ecosystem? I will begin looking into it as well. Outside of that I totally agree with you though... the clear nature of the 'problem' hasn't even really been totally defined, and i think that's because this is a potentially large evolution in the way Klipper is thought of and used.... I would hope that we'd maintain our current methods and add more where they wont' create a huge amount of new overhead.

On Sun, Jul 1, 2018 at 4:54 PM, Hans Raaf notifications@github.com wrote:

@shoreliner https://github.com/shoreliner I actually think that docker is even more complex to use for some people. I don't see why klipper can't just get a "binary" distribution and being installed as package/homebrew or even with an legit installer. I deployed some of our own Python based software for Windows and Python in the past. Having a self contained installation with py2exe is kinda easy to do. You can even add automatic updates. For example by using the Github releases. Maybe the problem here is having avrdude and stuff on Windows (probably... I don't use Windows since years). The real problem (in my eyes) is how to interface to Klipper from "any host" software. As long as this is an OctoPrint only solution there will be hurdles for users which just don't want to use that.. even if installed on the normal host computer.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401632515, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQT9tcN1U5LBCPuQSV0bk8uabPzpWks5uCTcIgaJpZM4UOwp9 .

oderwat commented 6 years ago

Well you can use Docker For Windows (or Docker For Mac) to enable using Docker. This is much better than in the past already. I use later one and created and used some images but all of this needs running stuff in the terminal and is a bit obfuscated actually. I use Visual Studio Code for controlling the running instances. There is no GUI with Docker (afaik). I think when going Docker the best way is to force OctoPrint/Klipper (+tools) and make it so, that it can be run and then controlled by web easily.

The C parts of Klipper could be a problem on Windows, because you need a compiler and installing Visual Studio is not an easy thing. A MinGW based install is not mentioned on the CFFI site. But I think that this can be precompiled. Even the hardware images could be precompiled. There are only so many variants needed.

All of this is way off the actual development of the software. I see why Kevin would just not want to deal with having a (binary) distribution besides the sources. That is a beast of its own. Having a OS X "from source" install is probably pretty easy with the help of Homebrew. It is basically just another *nix. Windows may get easier in the future as I read that they adopt Linux toolchains?

What I wanted (and kinda still want) to do is distributing an SD Card image for an RasPi which "works out of the box". So people just need to buy that, slide the SD in, connect it to the PC (DHCP?) and use it like that or set up WiFi. Maybe even be able to add wifi preparing the SDCard connected to their PC.

sillyfrog commented 6 years ago

I agree a Docker solution should just be "another option". What makes it really nice to use is everything can be included in the container (gcc, make, libraries etc), that on some platforms is a real pain to get installed.

The biggest issues with Docker as I see it are:

Personally I think OctoPrint bundled with Klipper is a great combination and would be the most common (but that's just because that's what I found the best), but totally understand that's not what everyone would want (hence not pushing a PR). Having a "heavy" container with everything that someone may want built in would make deployment really easy on any platform, provided we could get ser2net and similar easy to install.

Something else I found good about the Docker container is I could build all of the firmware (and run updates) in the container as well, without requiring the install of a bunch of tools on my host I would never use again.

Sorry for the brain dump, keen to help out where I can, just want to be clear on the end goal, I'm keen to see Klipper in more peoples hands, it's awesome! :)

Cheers!

oderwat commented 6 years ago

@sillyfrog You need ser2net inside docker and socat on the host (it is available for Mac and Windows). But it will not really help a lot, because none of the commonly used slicers and hosts work with the virtual serial port. They either don't allow to configure it or just down work with them. I tried really bad to get this working and ended up using a real hardware "null modem" connection (using 2 USB2TTL GND<->GND and TX/RX crossed). This shows promises but is not an universal solution.

I do believe that one could make Slic3r and Cura to actually work with the virtual serial Klipper uses by creating a PR for that. I also already tried to convince S3D that this would be cool. Having this would make a lot of stuff possible.

sillyfrog commented 6 years ago

@oderwat Re ser2net, my thinking was this is for Klipper talking to the actual printer, the slicing and interface etc would all run in the container (hence OctoPrint). This is what I do, I run the Slicer plugin in OctoPrint, and never actually use the Cura/Slic3r interface. I was talking about it a few posts ago going the other way - bit confusing :)

oderwat commented 6 years ago

@sillyfrog Yeah. I was confused and just forgot that you can't access the serial from inside docker (which I brought up before myself). Actually I believe you can, by using docker-machine and Parallels, VMWare or VirtualBox to run the docker image. It is just not yet possible with Docker for Mac afaik.

BTW: I am not sure if Klipper will run on a socat virtual serial port itself. But that should also be solvable (and is easily tested.. but my printers all run).

(I personally would never use a slicer engine inside of OctoPrint though.. I need manual supports, highly detailed previews of feature and speed. I also use manual set variable layer heights or multiple processes of S3D).

slipstreamliner commented 6 years ago

I am in the middle of some deep diving into Docker at the moment -- but, something Hans said reminded me... Win 10(at least the Enterprise IOT edition i'm using) allows you to install an entire Linux subsystem via the windows store. We could look into the implications of this at a low level and see how they are exposing ports... I would imagine it is indeed similar to the parallels/virtualbox as Hans mentioned.

Also, since the work is already being done for Tornado(in terms of the Duet Web server instance) to work with Klipper... perhaps this could be another optional aspect that could be docker-ized... the control method itself. It could be as it is now, Tornado, a direct interface to klippy.... etc. I can see this being an attractive option to people.

Thanks

Dave

On Sun, Jul 1, 2018 at 6:32 PM, Hans Raaf notifications@github.com wrote:

@sillyfrog https://github.com/sillyfrog Yeah. I was confused and just forgot that you can't access the serial from inside docker (which I brought up before myself). Actually I beliefe you can by using docker-machine and Parallels, VMWare or VirtualBox to run the docker image. It is just not yet possible with Docker for Mac afaik.

BTW: I am not sure if Klipper will run on a socat virtual serial port itself. But that should also be solvable (and is easily tested.. but my printers all run).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401637931, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQYnk5noCML-SdS1o0YvN4U7phMcGks5uCU4DgaJpZM4UOwp9 .

AxMod3DPrint commented 6 years ago

A little off topic here, but as an aside, I've started working on an Octopi variant that includes Klipper. I'll be sticking up an issue soon for people to test.

On Mon, 2 Jul 2018, 01:34 David Hargrove, notifications@github.com wrote:

I am in the middle of some deep diving into Docker at the moment -- but, something Hans said reminded me... Win 10(at least the Enterprise IOT edition i'm using) allows you to install an entire Linux subsystem via the windows store. We could look into the implications of this at a low level and see how they are exposing ports... I would imagine it is indeed similar to the parallels/virtualbox as Hans mentioned.

Also, since the work is already being done for Tornado(in terms of the Duet Web server instance) to work with Klipper... perhaps this could be another optional aspect that could be docker-ized... the control method itself. It could be as it is now, Tornado, a direct interface to klippy.... etc. I can see this being an attractive option to people.

Thanks

Dave

On Sun, Jul 1, 2018 at 6:32 PM, Hans Raaf notifications@github.com wrote:

@sillyfrog https://github.com/sillyfrog Yeah. I was confused and just forgot that you can't access the serial from inside docker (which I brought up before myself). Actually I beliefe you can by using docker-machine and Parallels, VMWare or VirtualBox to run the docker image. It is just not yet possible with Docker for Mac afaik.

BTW: I am not sure if Klipper will run on a socat virtual serial port itself. But that should also be solvable (and is easily tested.. but my printers all run).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401637931 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AEzNQYnk5noCML-SdS1o0YvN4U7phMcGks5uCU4DgaJpZM4UOwp9

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-401644391, or mute the thread https://github.com/notifications/unsubscribe-auth/AQULnlnN6N4Q9ZQggIZ9PpxHo88Tx3hnks5uCWqpgaJpZM4UOwp9 .

KevinOConnor commented 6 years ago

On Sat, Jun 30, 2018 at 03:54:36PM -0700, sillyfrog wrote:

I'm still working on it - it's specific to my needs, but shows how it can be done. It integrates OctoPrint into the same container to allow the virtual port to work. I'm more that happy to put in a PR for it if you are interested, it would combine OctoPrint/Klipper and a few other tools into a single container.

(For reference, my current implementation is here: https://github.com/sillyfrog/OctoPrint-Klipper-mjpg-Dockerfile )

Let me know your thoughts and I can get started on a PR.

Okay, thanks.

I'm really not that familiar with docker, so I can't provide much guidance. If it's as simple as placing a "Dockerfile" into the scripts/ directory, then I don't see any harm in including an example dockerfile in Klipper. As for what to include - I'd go with the basics and let more advanced users customize from there.

On Sun, Jul 01, 2018 at 01:45:57PM -0700, David Hargrove wrote:

Kevin -- can we defer to you for this? I mean, what do you envision as a more clean, simple way of installing and using klipper?

Installation is indeed a thorny issue. I organized the installation document around OctoPi, "git pull", "./scripts/install-octopi.sh".

It's one of my primary goals for Klipper to be hardware independent (both on the mcu and host side), so despite the docs being specific to OctoPi + OctoPrint I tried to avoid any unnecesary dependencies in the code.

I'm open to alternative installation mechanisms, but I don't have any particular inspiration to provide.

On Mon, Jul 02, 2018 at 12:11:04AM -0700, AxMod 3D Print wrote:

A little off topic here, but as an aside, I've started working on an Octopi variant that includes Klipper. I'll be sticking up an issue soon for people to test.

That would be neat. Just as an FYI, I didn't pursue that originally because I thought the download size would be too large to effectively distribute as a small open source project.

-Kevin

slipstreamliner commented 6 years ago

Actually I'm really happy to verify that, as I have gotten the impression you tried to keep things general where possible. I have never really discussed it with you, but it seems like Klipper was basically 'launched' with OctoPrint because of the target audience... people with a raspberry pi, that aren't intimidated by flashing MCUs, trying new things, etc. Now since Klipper is evolving, I think I can at least work on some different possible configurations. The Duet integration from Petri and Jouni's project is right now how I am utilizing Octoprint. I absolutely LOVE it.

Right now I see a few options for people:

--As currently distributed, Klipper is primary intended to work by attaching to a virtual bridging port in OctoPrint. --As currently distributed, Klippy as a command line utility in VSD mode.... but, what if we expand this? It seems that Klippy could handle gcode from any source. --TouchUI realm: A Klipper-centric TouchUI interface could be awesome for some, given the wide use of waveshare touchscreens and other devices. Plus, @mmone has already written most of the basic functionality for this in the Octo klipper plugin. --Duet/Tornado -- this is the current variant that our friends in Finland are using. --Create a web API including Interface Hooks: this could be extended to UI developers that are not familiar with the ins-and-outs of something like command line scripting. --As AxMod suggested, I do believe it a good method for distribution but I have the same concerns that Kevin has...

Thanks All.

Dave

On Tue, Jul 3, 2018 at 9:17 PM, KevinOConnor notifications@github.com wrote:

On Sat, Jun 30, 2018 at 03:54:36PM -0700, sillyfrog wrote:

I'm still working on it - it's specific to my needs, but shows how it can be done. It integrates OctoPrint into the same container to allow the virtual port to work. I'm more that happy to put in a PR for it if you are interested, it would combine OctoPrint/Klipper and a few other tools into a single container.

(For reference, my current implementation is here: https://github.com/sillyfrog/OctoPrint-Klipper-mjpg-Dockerfile )

Let me know your thoughts and I can get started on a PR.

Okay, thanks.

I'm really not that familiar with docker, so I can't provide much guidance. If it's as simple as placing a "Dockerfile" into the scripts/ directory, then I don't see any harm in including an example dockerfile in Klipper. As for what to include - I'd go with the basics and let more advanced users customize from there.

On Sun, Jul 01, 2018 at 01:45:57PM -0700, David Hargrove wrote:

Kevin -- can we defer to you for this? I mean, what do you envision as a more clean, simple way of installing and using klipper?

Installation is indeed a thorny issue. I organized the installation document around OctoPi, "git pull", "./scripts/install-octopi.sh".

It's one of my primary goals for Klipper to be hardware independent (both on the mcu and host side), so despite the docs being specific to OctoPi + OctoPrint I tried to avoid any unnecesary dependencies in the code.

I'm open to alternative installation mechanisms, but I don't have any particular inspiration to provide.

On Mon, Jul 02, 2018 at 12:11:04AM -0700, AxMod 3D Print wrote:

A little off topic here, but as an aside, I've started working on an Octopi variant that includes Klipper. I'll be sticking up an issue soon for people to test.

That would be neat. Just as an FYI, I didn't pursue that originally because I thought the download size would be too large to effectively distribute as a small open source project.

-Kevin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-402334709, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQSOt_xCSROLKTQJN0LYkjv9XXKQPks5uDBe0gaJpZM4UOwp9 .

AxMod3DPrint commented 6 years ago

My main thought behind the octopi image was accessibility. I can understand the file size issue here, but it's just another way of getting klipper into people's hands. I am able to mirror the file so it's not much of an issue, if you consider that he actual octopi image is 2.3GB unpacked adding klipper really doesn't add much more to it. However, like the Docker file it's just another way of distribution and people can still install Klipper manually, should they want to.

Also if we could get an octoprint plugin for Klipper sorted as suggested in issue #457 then that could be included as well and the end user really wouldn't need to touch the back end at all.

A little off topic here, but once certain large features are in, such as #404 and the mesh levelling that is being worked on, it may be worth freezing the master branch and using it only for major updates and large bug fixes new features and small fixes that may be worked on should possibly go into an upstream or edge branch

slipstreamliner commented 6 years ago

Ax, if we just improve mmone's existing octoprint-klipper plugin and improve the functionality it would be helpful. I'd like to see this turn into a generic interface, but I'm willing to work towards smaller goals for now. I had meant to take this on a while back but things got a bit complicated with my own business(for the better, luckily). https://github.com/mmone/OctoprintKlipperPlugin

On Wed, Jul 4, 2018 at 3:10 AM, AxMod 3D Print notifications@github.com wrote:

My main thought behind the octopi image was accessibility. I can understand the file size issue here, but it's just another way of getting klipper into people's hands. I am able to mirror the file so it's not much of an issue, if you consider that he actual octopi image is 2.3GB unpacked adding klipper really doesn't add much more to it. However, like the Docker file it's just another way of distribution and people can still install Klipper manually, should they want to.

Also if we could get an octoprint plugin for Klipper sorted as suggested in issue #457 https://github.com/KevinOConnor/klipper/issues/457 then that could be included as well and the end user really wouldn't need to touch the back end at all.

A little off topic here, but once certain large features are in, such as

404 https://github.com/KevinOConnor/klipper/issues/404 and the mesh

levelling that is being worked on, it may be worth freezing the master branch and using it only for major updates and large bug fixes new features and small fixes that may be worked on should possibly go into an upstream or edge branch

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-402385233, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQUjckbk0aAGRnNjIFX0NlkpYNG8oks5uDGp1gaJpZM4UOwp9 .

slipstreamliner commented 6 years ago

Can we add Petri and Jouni, the two guys that are developing the Klipper-centric board to the mailing list somehow? I can't remember if it was tied in with GitHub or not, only that you told me I wasn't sending messages to the correct list. =) I know this is tracking an issue right now, but, in general how would we allow them to receive these messages?

Petri: honkala.petri@iki.fi

Jouni: Was driving to work i think.. hehe. Will get it later.

On Wed, Jul 4, 2018 at 9:21 AM, Dave Hargrove davidh976@gmail.com wrote:

Ax, if we just improve mmone's existing octoprint-klipper plugin and improve the functionality it would be helpful. I'd like to see this turn into a generic interface, but I'm willing to work towards smaller goals for now. I had meant to take this on a while back but things got a bit complicated with my own business(for the better, luckily). https://github.com/mmone/OctoprintKlipperPlugin

On Wed, Jul 4, 2018 at 3:10 AM, AxMod 3D Print notifications@github.com wrote:

My main thought behind the octopi image was accessibility. I can understand the file size issue here, but it's just another way of getting klipper into people's hands. I am able to mirror the file so it's not much of an issue, if you consider that he actual octopi image is 2.3GB unpacked adding klipper really doesn't add much more to it. However, like the Docker file it's just another way of distribution and people can still install Klipper manually, should they want to.

Also if we could get an octoprint plugin for Klipper sorted as suggested in issue #457 https://github.com/KevinOConnor/klipper/issues/457 then that could be included as well and the end user really wouldn't need to touch the back end at all.

A little off topic here, but once certain large features are in, such as

404 https://github.com/KevinOConnor/klipper/issues/404 and the mesh

levelling that is being worked on, it may be worth freezing the master branch and using it only for major updates and large bug fixes new features and small fixes that may be worked on should possibly go into an upstream or edge branch

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/358#issuecomment-402385233, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQUjckbk0aAGRnNjIFX0NlkpYNG8oks5uDGp1gaJpZM4UOwp9 .

AxMod3DPrint commented 6 years ago

@shoreliner - I'd missed that one as it's not in the Octoprint Plugin repo.

ysoldak commented 5 years ago

Just dropping here a link to tutorial on how to make USB devices visible in docker containers on Mac (and Win?). http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/

Tried this quickly, still no cigar, but that can just be silly me.