Octoprint with rostock

[daftscience]

I just learned about Octoprint

I have it installed on my linux server and I'm wondering if anyone has given it a shot? From what I've seen it looks like it's pretty slick. Web based controls, drag and drop Gcode files, option for mounting a camera. I had to change my baud rate to 115200 to connect.

The only issue is I can't seem to stay connected, soo I don't have it working.

[theverant]

Looks interesting... and I just happen to have a Raspberry Pi sitting on my desk right now.

Are you running it on Pi, or on a PC?

Looking forward to hearing about your experience - I'm not ready to jump into a new controller until I get my calibration phase finished. The last think I need is more complexity at this point!

[daftscience]

i'm running it on an Ubuntu NAS/XBMC server. I'm using the Repetier firmware and I don't know if that is causing the issues but i'm having a difficult time holding a reliable connection. When I do have a connection I can send commands but the upload file thing doesn't work and unless I manually send M105 it wont report the temperatures.

I'm going to play around with it some more, I think the issue is with the firmware, not octoprint.

Let me know if you get it working on your rPi. I may end up installing it on my beaglebone.

[daftscience]

So I was able to get Octoprint working on Ubuntu. Nice to be able to monitor and control remotely. Also, drag and drop Gcode files makes printing files from Kisslicer a bit easier.

Two things to change (Using the Repetier firmware)

1. Baud rate needs to be dropped down to 115200
2. Comment out

Code: Select all

#define WAITING_IDENTIFIER "wait"

[daftscience]

So, I've managed to write some controls that will make calibrating much easier I think.

If anyone has got it running, throw this into you config.yaml file. It sends the commands to move the printer to give you more accurate positioning than by moving .1mm. It also has the three calibration points hardcoded in, so its just a matter of setting Z height.

Code: Select all

controls:
  - name: Fan
    type: section
    children:
      - name: Enable Fan
        type: parametric_command
        command: M106 S%(speed)s
        input:
          - name: Speed (0-255)
            parameter: speed
            default: 255
      - name: Disable Fan
        type: command
        command: M107
  - name: Delta Calibration
    type: section
    children:
    - name: Set Z=0
      type: parametric_command
      command: G0 Z%(height)s
      input:
       - default: 50
         name: Height
         parameter: height
    - name: Calibrate Z Axis
      type: parametric_command
      command: G0 X0 Y90 Z%(height)s
      input:
       - default: 50
         name: G0 X0 Y90 Z
         parameter: height
    - name: Calibrate Y Axis
      type: parametric_command
      command: G0 X77.94 Y-45 Z%(height)s
      input:
       - default: 50
         name: G0 X77.94 Y-45 Z
         parameter: height
    - name: Calibrate X Axis
      type: parametric_command
      command: G0 X-77.94 Y-45 Z%(height)s
      input:
       - default: 50
         name: G0 X-77.94 Y-45 Z
         parameter: height

[img]http://i.imgur.com/I88EAoU.png[/img]

[foosel]

Hey there daftscience, I'm the developer of OctoPrint. Could you elaborate on what the issue was with the cited line left in the Repetier firmware? I'd love to make OctoPrint as compatible as it can be without any firmware modifications (besides maybe adjusting the baudrate down to 115200) necessary

[mhackney]

Welcome to the forum foosel. I blogged about OctoPrint as it appeared in the RepRap Magazine. Interesting software. I plan on giving it a try soon.

cheers,
Michael

[daftscience]

Hey there daftscience, I'm the developer of OctoPrint. Could you elaborate on what the issue was with the cited line left in the Repetier firmware? I'd love to make OctoPrint as compatible as it can be without any firmware modifications (besides maybe adjusting the baudrate down to 115200) necessary

So, since my last post you and polygonhel have both updated your GIT's. I was holding off on reconfiguring until my rasberry pi came in, but here it goes.

Without the modifications these are the result I get from octoprint:

Code: Select all

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyACM0
Connected to: Serial<id=0x1dc4fd0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Recv: ?????????i?start
Recv: External Reset
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Changing monitoring state from 'Connecting' to 'Closed'
Connection closed, closing down monitor

I found the wait commands comes from this line in Configuration.h

Code: Select all

/** Communication errors can swollow part of the ok, which tells the host software to send
the next command. Not receiving it will cause your printer to stop. Sending this string every
second, if our queue is empty should prevent this. Uncomment if you don't wan't this feature. */
#define WAITING_IDENTIFIER "wait"

Once I comment that out I get this:

Code: Select all

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyACM0
Connected to: Serial<id=0x392f110, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Recv: ????????????start
Recv: External Reset
Send: M105
Recv: Error: Missing checksum
Changing monitoring state from 'Connecting' to 'Error:  Missing checksum 
...'
Recv: Resend:1
Recv: ok
Recv: 
Recv: Resend:1
Recv: ok
Recv: 
Recv: Resend:1
Recv: ok
Recv: 
(This continues forever)

I'll see if I can figure out what's going on. Before the updates though, after I was connected I could control the printer but had an issue where I had to send M111 S1 before I tried to start printing. Otherwise I would get an error like this

Code: Select all

Expected line 5 got line 4

Thanks for looking into this. I was able to print a few things and I love being able to use my laptop in another room to monitor it.


Tom

[daftscience]

I've installed repetier-server on the same box running octoprint(Still liking the simplicity of octoprint over RS) and I am able to connect. The only real difference I see at the surface is the fact that I have to configure the printer manually.

This is the communication output from Reptier-Server.

Code: Select all

23:48:16	FIRMWARE_NAME:Repetier_0.81 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Rostock EXTRUDER_COUNT:1 REPETIER_PROTOCOL:2
23:48:16	Printed filament:362.84 m
23:48:16	Printing time:6 days 0 hours 11 min
23:48:16	M105
23:48:16	ok 3
23:48:16	T:0.00 B:0.00 @:0
23:48:17	M105
23:48:17	ok 4
23:48:17	T:22.18 B:24.26 @:0
23:48:18	M105
23:48:18	ok 5
23:48:18	T:22.18 B:24.26 @:0
23:48:19	M105
23:48:19	ok 6
23:48:19	T:22.34 B:24.26 @:0

This is the config file for my printer that reptetier-server uses. This is mine

Code: Select all

tom@NAS:/var/lib/Repetier-Server/configs$ cat test.cfg 
version="1.0";
active=false;
printer:{
  name="Rostock Max";
  slugName="rostockmax"; // Unique name with ascii chars without space,tab. Is used for path names.
  connection:{
    device="/dev/serial/by-id/usb-UltiMachine__ultimachine.com__RAMBo_640363537303512181C1-if00";
    //baudrate=250000; //
    baudrate=115200;
    pingPong=false; // Allow sending more then one command if it fits into printer cache
    readCacheSize=127; // Size of the printer cache. May be 63 for some printer.
    /* Communication protocol used to communicate with this printer:
       0 = ascii protocol - works with all reprap firmwares
       1 = Repetier-Protocol V1 - requires Repetier-Firmware
       2 = Repetier-Protocol V2 - requires Repetier-Firmware 0.80 or higher */
    protocol=2;
    okAfterResend=true; // Does your firmware send a ok after sending a resend for that line?
  };
  dimension:{
    xmin=0.0;
    ymin=0.0;
    zmin=0.0;
    xmax=195.0;
    ymax=195.0;
    zmax=195.0;
  };
  homing:{
    xhome=0.0; // Coordinates after homing x axis
    yhome=0.0; // Coordinates after homing x axis
    zhome=0.0; // Coordinates after homing x axis
  };
  speed:{
    xaxis=50.0; // Move speed in mm/s for manual moves
    yaxis=50.0; // Move speed in mm/s for manual moves
    zaxis=2.0; // Move speed in mm/s for manual moves
    eaxisExtrude=2.0; // Move speed in mm/s for manual moves
    eaxisRetract=20.0; // Move speed in mm/s for manual moves
  };
  extruder:{
    count=1;  // Number of extruder on that device
    tempUpdateEvery=1; // Update temperature every x seconds
  };
};

I don't know if any of that is helpful. I think the issue is with the firmware not recognizing non-repetier communication.


Tom

[foosel]

Without the modifications these are the result I get from octoprint:

Code: Select all

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyACM0
Connected to: Serial<id=0x1dc4fd0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Recv: ?????????i?start
Recv: External Reset
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Changing monitoring state from 'Connecting' to 'Closed'
Connection closed, closing down monitor

Looks like OctoPrint doesn't even try starting to send it's continuous "M105" updates here. What strikes me as suspicious is the garbled binary before the start. OctoPrint usually doesn't wait for the "start" response before sending (there's an option though to force it to do so), so this shouldn't make a difference, but still, this looks weird.

I found the wait commands comes from this line in Configuration.h

Code: Select all

/** Communication errors can swollow part of the ok, which tells the host software to send
the next command. Not receiving it will cause your printer to stop. Sending this string every
second, if our queue is empty should prevent this. Uncomment if you don't wan't this feature. */
#define WAITING_IDENTIFIER "wait"

What puzzles me here is that while the firmware keeps sending a wait, there indeed is never an ok.

Code: Select all

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyACM0
Connected to: Serial<id=0x392f110, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Recv: ????????????start
Recv: External Reset
Send: M105
Recv: Error: Missing checksum
Changing monitoring state from 'Connecting' to 'Error:  Missing checksum 
...'
Recv: Resend:1
Recv: ok
Recv: 
Recv: Resend:1
Recv: ok
Recv: 
Recv: Resend:1
Recv: ok
Recv: 
(This continues forever)

Do you know if Repetier demands a checksum for all communication? I currently only use Marlin, and there the checksum is optional.

I'll see if I can figure out what's going on. Before the updates though, after I was connected I could control the printer but had an issue where I had to send M111 S1 before I tried to start printing. Otherwise I would get an error like this

Code: Select all

Expected line 5 got line 4

Hm, sure you don't mean "M110 N1"? OctoPrint actually prefixes any printed GCODE files with a M110, so the linecounter should be reset. Might be that Repetier demands a N0 here though... I guess I'll have to look into the source code. In any case, when you figure something out (or even when you don't), please don't hesitate to just open a ticket on the issue tracker

Welcome to the forum foosel. I blogged about OctoPrint as it appeared in the RepRap Magazine. Interesting software. I plan on giving it a try soon.

Thanks for the welcome, hope you'll like the software!

Cheers,
Gina

[daftscience]

Looks like OctoPrint doesn't even try starting to send it's continuous "M105" updates here. What strikes me as suspicious is the garbled binary before the start. OctoPrint usually doesn't wait for the "start" response before sending (there's an option though to force it to do so), so this shouldn't make a difference, but still, this looks weird.

When I tell octoprint not to wait for the start command it will always just plain fail to connect.

Do you know if Repetier demands a checksum for all communication? I currently only use Marlin, and there the checksum is optional.

I believe it does. But I may be wrong on that. I'm looking through the firmware files and I can't seem to find it.


As far as the M111 M110 thing... I can't even remember anymore I'm sorry I've tried a lot of different things and they are all blurring together. I wish I could confirm, but like I said after updating I can't connect.

However, this may be something of interest? Maybe not.

/** \brief Sets time for echo debug

You can set M111 1 which enables ECHO of commands send. This define specifies the position,
when it will be executed. In the original FiveD software, echo is done after receiving the
command. With checksum you know, how it looks from the sending string. With this define
uncommented, you will see the last command executed. To be more specific: It is written after
execution. This helps tracking errors, because there may be 8 or more commands in the queue
and it is elsewise difficult to know, what your reprap is currently doing.
*/
#define ECHO_ON_EXECUTE

I can't comment that out because the firmware won't compile without it.


Thanks for looking into this though. I can start up a ticket. Hopefully we can get it working soon.
Tom

[daftscience]

I don't know what the issue was, it's "working" now but i'm getting this.

Code: Select all

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "octoprint/util/comm.py", line 340, in _monitor
    self._bedTemp = float(re.search("-?[0-9\.]*", line.split(' B:')[1]).group(0))
ValueError: could not convert string to float: 

Every once in a while, I'm going to wait until my rasberryPi comes on monday and start from there.

[foosel]

Code: Select all

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "octoprint/util/comm.py", line 340, in _monitor
    self._bedTemp = float(re.search("-?[0-9\.]*", line.split(' B:')[1]).group(0))
ValueError: could not convert string to float: 

That looks like it's hiccuping on the temperature information coming back from Repetier. When it happens again, could you take a look into the Terminal tab? You should see something along the lines of

Code: Select all

Send: M105
Recv: ok T:0.00 /0.00 B:1.00 /1.00 @:64

My guess is that the Recv-line will look more like

Code: Select all

Recv: T:0.00 B: @:64

with the bed temperature just left out. That's just a blind guess from the log file though, so if you could paste the corresponding line here or in a ticket, that would be great.

[daftscience]

Here is the output. I didn't notice anything remarkable about it before that's why I didn't include it. But It basically stops posting when the error occurs.

Code: Select all

Send: M105
Recv: ok
Recv: T:183.01 B:70.96 @:255
Recv: 
Send: M105
Recv: ok
Recv: T:186.67 B:71.14 @:255
Recv: 
Send: M105
Recv: ok
Recv: T:190.13 B:71.42 @:255

The terminal tab stops posting anything sent by the printer. However it responds when i send commands.

Code: Select all

Send: M105
Recv: ok
Recv: T:186.67 B:71.14 @:255
Recv: 
Send: M105
Recv: ok
Recv: T:190.13 B:71.42 @:255
*****Everything from here down was manually sent by me, the printer homed and set the temp
Send: G28
Send: M104 S230
Send: M105
Send: M105
Send: G28

Thanks again. I just opened a ticket on github.

Tom

[enggmaug]

Does anyone know if these issues were resolved or not since 2013 ?
I'm Still struggling to get it to connect to my max.