›

Connect Repetier Server to Klipper firmware

AlexMAlexM
in Repetier-Server
Is it possible to connect the Repetier Server to a Klipper firmware? 
Short description:
"Klipper is a new experimental firmware! It is designed to run on both a micro-controller and a low cost host computer such as a Raspberry Pi. The host does all the work of determining how and when to move each stepper motor, it compresses that information, and sends it to the micro-controller. The micro-controller then uncompresses the given schedule and executes it at the specified times. The same host computer can be used to run both Klipper and OctoPrint."
https://github.com/KevinOConnor/klipper

I succesfully run it with OctoPrint but Repetier Server has much much better Touch UI and many other nice features.

In OctoPrint I added specific serial port in "Additional serial ports" section - named /tmp/printer. And OctoPrint "talks" to the firmware through it.

I asked the developer of Klipper to integrate it with Repetier and he answered me next:
"In order to replace OctoPrint, you'll need to convince the Repetier Server software to connect to /tmp/printer. (Only the Klipper host software talks directly with the micro-controller - Repetier Server needs to talk directly with the Klipper host software via /tmp/printer.)"
I tried manually change the Device / Port in connection tab to /tmp/printer but the Repetier Server didn't connect it.

May you suggest me what can I do to fix it.
I would like to combine two great products :)

Kind regards,
Alex
«1

Comments

  • RepetierRepetier
    Repetier-Server connects to the device given in config. It will not list it but if it can be controlled like a serial port it should work if you put the path to it manually. So first question is, if it is like a serial port or more like a socket. A socket requires other functions to talk as it has no baud rate etc.

    Second thing is selecting the right firmware. I think Marlin would be the correct start to get it going. Also you can copy the firmware description /usr/local/Repetier-Servers/firmwares to adjust to special answer format. But most important is to get a general communication running and repetier-firmware uses a binary format that klipper surely does not speak.
  • RossiniRossini
    afaik generates klipper a virtual serial port with python pyserial which accepts normal G-Code
  • AlexMAlexM
    About second thing - yesterday I found firmware list and added the separate config for klipper. I tried to copy from Marlin and Smoothie but anything didn't connect. May I found a log of the reason why Repetier doesn't connect properly? I didn't find any debug information.
  • RepetierRepetier
    If it gives some hints it would be in /var/lib/Repetier-Server/logs/server.log where it normally logs every connect/disconnect as well.

    Looking into klippy sources I found that this creates the port:# Support for creating a pseudo-tty for emulating a serial port:

    def create_pty(ptyname):
        mfd, sfd = pty.openpty()
        try:
            os.unlink(ptyname)
        except os.error:
            pass
        os.symlink(os.ttyname(sfd), ptyname)
        fcntl.fcntl(mfd, fcntl.F_SETFL
                    , fcntl.fcntl(mfd, fcntl.F_GETFL) | os.O_NONBLOCK)
        old = termios.tcgetattr(mfd)
        old[3] = old[3] & ~termios.ECHO
        termios.tcsetattr(mfd, termios.TCSADRAIN, old)
        return mfd

    now is python a language I do not really speak or use, so I can not say if this is really a virtual serial port. I see for example no baud rate, not that it matters on virtual devices.

    From https://docs.python.org/3.2/library/pty.html I would think it is more a input/output socket. Once the communication is established that makes no big difference, but I guess that the used library will fail when trying to set rts/DTR signals or baud rate with some error. So please report what you see.

    Also does klippy work without a board so I can test it some time?
  • AlexMAlexM
    edited January 2018
    Many thanks for your reply and interest in my question!

    1. I checked the server.log and found just this:

    2018-01-16 22:50:17: Start logging...
    2018-01-16 22:50:17: Webdirectory: /usr/local/Repetier-Server/www/
    2018-01-16 22:50:17: Storage directory: /var/lib/Repetier-Server/
    2018-01-16 22:50:17: Configuration file: /usr/local/Repetier-Server/etc/RepetierServer.xml
    2018-01-16 22:50:17: Directory for temporary files: /tmp/
    2018-01-16 22:50:17: Reading firmware data ...
    2018-01-16 22:50:17: Starting Network ...
    2018-01-16 22:50:17: Active features:0
    2018-01-16 22:50:17: Reading printer configurations ...
    2018-01-16 22:50:17: Reading printer config /var/lib/Repetier-Server/configs/DBot.xml
    2018-01-16 22:50:17: Starting printjob manager thread for DBot
    2018-01-16 22:50:17: Starting printer threads ...
    2018-01-16 22:50:17: Starting printer thread for DBot
    2018-01-16 22:50:17: Starting work dispatcher subsystem ...
    2018-01-16 22:50:17: Starting user database ...
    2018-01-16 22:50:17: Initalizing LUA ...
    2018-01-16 22:50:17: Register LUA cloud services
    2018-01-16 22:50:17: add Repetier-Renderer
    2018-01-16 22:50:17: LUA initalization finished.
    2018-01-16 22:50:17: Starting web server ... 
    2018-01-16 22:50:17: Work dispatcher thread started.
    2018-01-16 22:50:17: Webserver started.
    2018-01-16 22:54:40: Shutting down web server.
    2018-01-16 22:54:41: Closing server
    2018-01-16 22:54:41: Stopping work dispatcher.
    2018-01-16 22:54:41: Work dispatcher thread stopped.
    2018-01-16 22:54:41: Waiting for all threads to finish ...
    2018-01-16 22:54:41: Worker threads finsihed.
    2018-01-16 22:54:41: Stopping printer threads.
    2018-01-16 22:54:41: Printer thread for DBot stopped
    2018-01-16 22:54:41: Closed virtual port /tmp/printer
    2018-01-16 22:54:41: Closing user database.
    2018-01-16 22:54:41: Server is now down.

    and /var/lib/Repetier-Server/printer/DBot/logs/connected.log file is empty

    2. Klipper (RPi Host part) start as service and fine works without printer board. Octoprint succesfully connecting to the virtual /tmp/printer port

    For my case, at first I installed the Octopi 0.14 RPi image, then Klipper and after that the Repetier Server armel 0.86.2 version. Of course before connect the Repetier Server to Klipper I closed connection from Octopi.

  • tmashtmash
    Just registered for this, Octoprint is too slow for small segmented lines on large prints, Repetier worked fine with smoothie same gcode without stutter, now using klipper (much better for printing large circles on 15~ inch printer), but octoprint stutters even on my i7 NUC.
    I will be willing to test anything. 
  • AlexMAlexM
    I tried to set Device|Port option to "/tmp/printer" and "/dev/pts/1" ("/tmp/printer" looks like alias for "/dev/pts/1") but Repetier don't try to connect (just what I can see in interface). Is it possible to manually enter port name? Is it affected to connection after I will save options? Looks like Repetier filtered all ports not from combo list.



  • RepetierRepetier
    Ok, managed to setup klippy which is a bit of a pain on a non octopi image, but it now works.
    BTW: It requires a ramps or so connected to work and not just show an error message.

    Just as I thought it has no serial port - it is a pseudo terminal. You can use it simply if you have 2 terminals. In one you send
    cat /tmp/printer
    here you will see all output. To send some commands enter in second terminal
    echo "status" > /tmp/printer

    I think pyserial just detects the difference and therefore it works with octoprint while repetier really wants a serial port and fails here on connect. For the further communication this makes no difference, so all I have to do is somehow make it detect this somehow and use it a simple 2 files for reading and writing and it should work. Hope I can make it work for next release but for now there is nothing you can do.
  • tmashtmash
    edited January 2018
    Thanks for all the effort. Ill manage to tinker with mirroring klipper to external mcu with direct serial (rpi gpio to arduino direct serial), then connect the arduino to rpi via usb with serial mirror sketch or rpi serial loopback with bitbang method without external hardware only wires temporarily and post the results. (which i guess might help investigate beyond serial)
     
  • tmashtmash
    Welp I can't believe how easily it worked. Didnt use any hardware, just install tty0tty module, then do:
    echo /tmp/printer > /dev/tnt0 & echo /dev/tnt0 > /tmp/printer
    Then type in Repetier host serial port: /dev/tnt1 
    Done! Works perfectly fine! Gotta test high segmented line 12 inch circle on 80mm/steps at 100mm/s now will report back.
  • tmashtmash
    since I can't edit anymore, use cat not echo hehe, was just too excited :)
  • tmashtmash
    edited January 2018
    This is what I get after being connected but it doesnt affect the print:

    23:27:18.860: Firmware was halted, trying to reconnect. Eventually running print is stopped.
    23:27:19.872: !! Printer is halted
    23:27:19.872: Response while unconnected:ok
    23:30:14.849: Response while unconnected:ok T0:25.5 /0.0 B:24.8 /0.0
    23:30:28.837: // Unknown command:"M117"
    23:30:51.763: Firmware was halted, trying to reconnect. Eventually running print is stopped.
    23:30:52.774: !! Must home axis first: 0.000 10.000 0.000 [0.000]
    23:30:52.775: Response while unconnected:ok
    23:31:03.170: Firmware was halted, trying to reconnect. Eventually running print is stopped.
    23:31:04.182: !! Must home axis first: 0.000 10.000 0.000 [0.000]
    23:31:04.183: Response while unconnected:ok

    I sent RESTART from the console tab like in the pic below, but it seems repetier only sends gcode, either way I used the built in reset command field . (sh script that echo "RESTART" > /tmp/printer") , its much neater that way (couldn't do it in Octoprint without plugins killing my ram, and having to type or click a button, useful for diagnosis)

    I'm gonna dry print a 10 hour print of a protien complex model as a stress test and stability before using it as my daily driver and will report back.

    Also, repetier smooth printing a large circle test succeeded with large amount of segmented lines (since arcs are not supported by most slicers) this is important for large prints, not for small prints due to molten plastic physics. There is no more 8bit blockyness on 10 inch diameter surface. You can simply test it by exporting a circle shaped model from fusion 360 with "high" profile.  This is all tested on Rpi Zero wireless version for anyone wondering. This comes first after my clone Duet 0.6 with fried stepper driver for extruder, not sure if it has to do with it being clone, but duet was louadly vibrating on the curves making ripples on the surface, running the latest firmware and printing from sdcard.



  • RossiniRossini
    Repetier said:
    If it gives some hints it would be in /var/lib/Repetier-Server/logs/server.log where it normally logs every connect/disconnect as well.

    Looking into klippy sources I found that this creates the port:# Support for creating a pseudo-tty for emulating a serial port:

    def create_pty(ptyname):
        mfd, sfd = pty.openpty()
        try:
            os.unlink(ptyname)
        except os.error:
            pass
        os.symlink(os.ttyname(sfd), ptyname)
        fcntl.fcntl(mfd, fcntl.F_SETFL
                    , fcntl.fcntl(mfd, fcntl.F_GETFL) | os.O_NONBLOCK)
        old = termios.tcgetattr(mfd)
        old[3] = old[3] & ~termios.ECHO
        termios.tcsetattr(mfd, termios.TCSADRAIN, old)
        return mfd

    now is python a language I do not really speak or use, so I can not say if this is really a virtual serial port. I see for example no baud rate, not that it matters on virtual devices.

    From https://docs.python.org/3.2/library/pty.html I would think it is more a input/output socket. Once the communication is established that makes no big difference, but I guess that the used library will fail when trying to set rts/DTR signals or baud rate with some error. So please report what you see.

    Also does klippy work without a board so I can test it some time?
    maybe this can get fixed in klipper too
    see http://man7.org/linux/man-pages/man3/termios.3.html
    looks like there is a way to set baud rate and other stuff

  • tmashtmash
    Rossini said:
    Repetier said:
    If it gives some hints it would be in /var/lib/Repetier-Server/logs/server.log where it normally logs every connect/disconnect as well.

    Looking into klippy sources I found that this creates the port:# Support for creating a pseudo-tty for emulating a serial port:

    def create_pty(ptyname):
        mfd, sfd = pty.openpty()
        try:
            os.unlink(ptyname)
        except os.error:
            pass
        os.symlink(os.ttyname(sfd), ptyname)
        fcntl.fcntl(mfd, fcntl.F_SETFL
                    , fcntl.fcntl(mfd, fcntl.F_GETFL) | os.O_NONBLOCK)
        old = termios.tcgetattr(mfd)
        old[3] = old[3] & ~termios.ECHO
        termios.tcsetattr(mfd, termios.TCSADRAIN, old)
        return mfd

    now is python a language I do not really speak or use, so I can not say if this is really a virtual serial port. I see for example no baud rate, not that it matters on virtual devices.

    From https://docs.python.org/3.2/library/pty.html I would think it is more a input/output socket. Once the communication is established that makes no big difference, but I guess that the used library will fail when trying to set rts/DTR signals or baud rate with some error. So please report what you see.

    Also does klippy work without a board so I can test it some time?
    maybe this can get fixed in klipper too
    see http://man7.org/linux/man-pages/man3/termios.3.html
    looks like there is a way to set baud rate and other stuff

    Issue should be discussed in Klipper tickets, Pronterface and Repetier host also work with my workaround, so it's not exclusive to Repetier Server anymore.
  • RepetierRepetier
    Tried to install tty0tty but failed. No matching headers for kernel so it refuses to load the module. But I'm happy it works for you and it is good to know communication works fast and stable with klippy. So it really depends on just adding support for pseudoterminals.

    You can force server to send commands 1:1 by pretending a # like
    #status
    that way you can use the special commands as well. Das added this for smoothieware but should work here as well. Next release will also detect non standard gcode and send it also 1:1 but maybe with line number and checksum. Not sure what I did there, but # should work and is I think already included in latest version.
  • tmashtmash
    Repetier said:
    Tried to install tty0tty but failed. No matching headers for kernel so it refuses to load the module. But I'm happy it works for you and it is good to know communication works fast and stable with klippy. So it really depends on just adding support for pseudoterminals.

    You can force server to send commands 1:1 by pretending a # like
    #status
    that way you can use the special commands as well. Das added this for smoothieware but should work here as well. Next release will also detect non standard gcode and send it also 1:1 but maybe with line number and checksum. Not sure what I did there, but # should work and is I think already included in latest version.
    # indeed works, thanks.

    installing raspberrypi-kernel-headers works for tty0tty, but doing quick search, it seems new rpi debian images (w/ kernel 4.4+) repos no longer offer that so back to crosscompiling.

    You can however still test it without any MCU connected in a VM or Linux desktop host (used lubuntu 17.10), thats how I discovered that it works first. You will see "klippy is not ready" messages on each m105 request in the console log with 0c temp reporting. And most desktop distros offer the header package.
  • RepetierRepetier
    Yes, got kernel headers being too new. rpi-update updated it and now installed version is newer then headers. So it is just a pain to get it matching. Could of course force rpi-update to use special version. But since I have no printe rwih klippy anyway I just wait until I can test server solution. So for "official" support I prefer the simple pts support. That makes it easier for everyone and no fear to loose connectivity on kernel updates.
  • tmashtmash
    edited January 2018
    Repetier said:
    Yes, got kernel headers being too new. rpi-update updated it and now installed version is newer then headers. So it is just a pain to get it matching. Could of course force rpi-update to use special version. But since I have no printe rwih klippy anyway I just wait until I can test server solution. So for "official" support I prefer the simple pts support. That makes it easier for everyone and no fear to loose connectivity on kernel updates.
    Agreed, thanks alot for the support and Repetier-Server (only alternative to Octo). Looking forward for the next release.
  • AlexMAlexM
    edited January 2018
    I successfully installed tty0tty. It's working. But really hard to install and tune.
    Now I've other trouble. Few times printing failed because Klipper doesn't support g-code line numbering and Repetier-Server shuffle the lines. For example:

    source g-code:
    G1 X110.407 Y79.808 E0.0180
    G1 X110.323 Y80.316 E0.0180
    G1 X110.296 Y80.805 E0.0171
    G1 X110.298 Y113.909 E1.1561
    G1 X110.322 Y114.350 E0.0154
    G1 X110.401 Y114.835 E0.0171

    received g-code by Klipper:
    Read 55661.970401: 'N155729 G1 X110.407 Y79.808 E0.0180*91\n'
    Read 55661.970698: 'N155730 G1 X110.323 Y80.316 E0.0180*80\n'
    Read 55661.970973: 'N155731 G1 X110.296 Y80.805 E0.0171*89\n'
    Read 55661.971765: 'N155733 G1 X110.322 Y114.350 E0.0154*101\nN155732 G1 X110.298 Y113.909 E1.1561*103\n'
    Read 55661.975812: 'N155734 G1 X110.401 Y114.835 E0.0171*107\n'
    Read 55663.483560: 'N155735 M105*23\nN155736 M105*20\n'
    Read 55664.530720: 'N155737 M105*21\nN155738 G1 X110.530 Y115.307 E0.0171*111\n'
    Read 55665.534970: 'N155739 M105*27\n'
    Read 55666.537640: 'N155740 M105*21\n'

    Is it possible to fix it on the Repetier Server?

    Link to the Klipper issue ticket - https://github.com/KevinOConnor/klipper/issues/146#issuecomment-361033682

  • RepetierRepetier
    I'm pretty sure server does not reorder lines. All firmwares would complain a missing line number. I also think it might be tty0tty reordering the 2 lines send.
    Only way to be 100% sure is when I have next release running with pipe support.

    Line numbers are not ancient btw, they are a very good method for firmwares to communicate errors. How else could a firmware tell which line had a defect. During internal communcation there is of course no chance for com errors so line numbers and resends can be skipped.

  • AlexMAlexM
    Thanks alot for the answer and support! Looking forward for the next release.
  • AlexMAlexM
    Do you have an approximate date for new update with the pipe support?
  • RepetierRepetier
    Not really. I have already written it but not compiled on linux for testing. I think we make a public beta when it has stabilized the new feature set and should work, which is maybe end of march. After all it is the biggest update we ever had, so much work.
  • CronixCronix
    Repetier said:
    which is maybe end of march. 

    i dont want to sound needy, but especially this feature is quite interesting to me aswell since i just switched from repetier-firmware to klipper, is there already some kind of closed beta going on where tech savyy linux engineers can test and give some feedback?
  • RepetierRepetier
    No, but we will publish in may as it looks and I already wrote the code that hopefully will work. Will at least test with a fake klippy printer.
  • RepetierRepetier
    After some testing I found that we already support connection to klipper. The problem is that you need to use /dev/pts/1 as port and change the group permission to be readable. Already filled in an issue that klipper should do this on it's own, see
    https://github.com/KevinOConnor/klipper/issues/348

  • Marco67Marco67
    Roland, when you think to release the server 0.90.0?
  • RepetierRepetier
    It comes beginning June I think. Just testing latest features. The klipper permission problem is already fixed on github version. 0.86.2 can also connect with /dev/pts/1 as device, just /tmp/printer will require the next release.
  • siimusiimu
    Hey,

    Might be a bit of a beginner question but, I have klipper installed and started with sudo service klipper start. Now if I go to Repetier-server do I have to choose Serial connection or Pipe/UNIX Socket for Connection Method? just wondering because I have tried both with /tmp/printer and /dev/pts/1 but havent been able to connect. If possible, would someone be able to write down the setting for Repetier side to connect to Klipper service, because Ive used it with OctoPrint before and loved it, but Ive come to like Repetier more than Octo and would love to use it here.
    Cheers 
  • RepetierRepetier
    Use serial connection and /tmp/printer as link.
    It is important to use latest github version of klipper. Klipper in 0.6 does not set the permissions for the device correctly, but if you use latest github version of klipper the fix will do that.
Sign In or Register to comment.