Started a print this morning and after a few layers the printer stopped an "Error: No Checksum with lin..." was displayed in the "Machine State:" field of Printer WebUI.

I'm not sure what went wrong but I was able to reconnect after resetting my RAMPS board, but unable to find a way to resume the print.

If there is a log or something I can provide that would help let me know, I was monitoring stdout but there's a lot of temp callback lines in there so it's hard to find anything other than those (but I might be able to find it if there's something specific you want me to look for).

I'm still seeing the Cura favicon in my browser; does that need to be replaced or maybe I'm just caching the old one...?

When I attempt to resume a paused print job, I start receiving line number errors immediately after I resume the print job. It appears the OctoPrint is a bit confused once a job is resumed. See output from terminal below. Note that lines are either duplicated or skipped after starting wtih N586. I am running a Raspberry Pi and it doesn't appear to matter where in the job I trigger the pause. Everything works perfect until I resume the pause.

Send: N582G1 X9.89 Y55.18 E69.8197_116
Recv: ok T:199.46 B:3.00 @:50
Send: N583G1 X9.71 Y53.77 E69.9429_124
Recv: ok
Send: N584G1 X9.84 Y53.82 E69.9548_125
Changing monitoring state from 'Printing' to 'Paused'
Recv: ok
Recv: ok
Changing monitoring state from 'Paused' to 'Printing'
Send: N585G1 X9.95 Y53.89 E69.9659_116
Send: N586G1 X20.44 Y60.78 E71.0593_75
Recv: ok
Send: N586G1 X20.44 Y60.78 E71.0593_75
Send: N587G1 X20.57 Y60.8 E71.0708_127
Recv: ok
Send: N589G1 X22.7 Y60.11 E71.2656_118
Send: N589G1 X22.7 Y60.11 E71.2656_118
Send: N590G1 X23.16 Y59.96 E71.3074_77
Send: N592G1 X24.07 Y59.65 E71.3918*71
Recv: Error:Line Number is not Last Line Number+1, Last Line:586

BTW, I really, really like the work done on this program!

Jim

how hard would it be to have the option to load the Gcode file from a URL as well as from a local file
as you can now? I'm working on a slicer-as-a-web-service and it would be cool if I could load the
Gcode directly from the service instead of having to ferry it vial the local filesystem.

(comment by Jason Gullickson from https://plus.google.com/u/0/103331171897037694195/posts/JovLpnS4YQ3)

The times displayed below the temperature graph seem weird to me. I'm not sure what they are related to:

As talked about on gTalk - prinitng via SD card would make things a bit more reliable with crappy USB connections.

As requested, here are some logs from the teminal when printing via SD:

Send: M20
Recv: Begin file list
Recv: OPEN_B~1.GCO
Recv: BOX1.GCO
Recv: BOX2.GCO
Recv: WAFFEL1.GCO
Recv: FANHOLD1.GCO
Recv: FANHOLD2.GCO
Recv: BUNNYS3.GCO
Recv: FANMOUNT.GCO
Recv: WAFFELEI.GCO
Recv: HUXLEY_F.GCO
Recv: COMPCUBE.GCO
Recv: BENDER.GCO
Recv: TRASH-~1/
Recv: CAGE1.GCO
Recv: CAGE2.GCO
Recv: RJFRAME.GCO
Recv: RLEDMT.GCO
Recv: TCUBE.GCO
Recv: ALIEND.GCO
Recv: ADRED3.GCO
Recv: HNDCG2.GCO
Recv: HNDCG1.GCO
Recv: BATTERY.GCO
Recv: End file list
Recv: ok

Send: M23 box1.gco
Recv: File opened:box1.gco Size:193158
Recv: File selected
Recv: ok

Send: M24
Recv: ok
Recv: Kp 2.00
Recv: Ki 0.01
Recv: Kd 20.00
Recv: PID_MAX 255
Recv: PID_I_MAX 125
Recv: NZONE 5

Send: M27
Recv: SD printing byte 534/193158
Recv: ok

None of the controls know that they should turn on the power supply before the printer can do anything (M80).

(comment by Thomas Sanladerer at https://plus.google.com/u/0/106003970953341660077/posts/cvDcYeE3MFG)

Printer is a Mendel90

Sometimes when homing the Z axis my X carriage stops and the motors spaz out.

At first I assumed this was something causing the steppers to be unable to drive the axis (too little current, binding, etc.), however if I switch to using printrun/pronterface without making any other changes, I can drive the axis freely.

I have no idea why or how PrinterWebUI could cause this behavior but I wanted to report it in case there was something that could be done. In the meantime I'm going to keep experimenting when I observe the behavior and see if it could be some sort of configuration issue with the Raspberry Pi (the other variable here).

This is just a feature request, no hurry :)

It would be cool if you could specify URL's that would be called when certain interesting events occur (printer coming up to temp, print complete, etc.). If these were flexible enough they could be used to indicate status on other systems (post a tweet, etc.) or even fire a buzzer or other indicator that is accessible via URL.

If some basic parameters were included (say filename, duration, etc.) you could do some really neat stuff, but even just something basic like being able to specify a URL that gets hit when the job is complete would be awesome.

Uploaded a large gcode file to Octoprint which seemed to work fine. However it seems like the file wasn't correctly saved so about 5 hours into the print it just stopped (sad panda)

Compared the gcode source file on my machine and it's 11,661,801 bytes however in the uploads directory it is 11,186,176 bytes.

I believe there may be an issue connected to the "Saving..." status on the uploader as that was present for a very long time in the end I had to refresh the page and "Saving..." disappeared - could this have caused the problem?

The gcode was for Prusa i3 x-end-motor and x-end-idler.

Attempting to upload this file again (with a new name) doesn't seem to even upload at all - OctoPrint is now at 56% mem usage on the raspberry pi (original Model B).

In total - is there a practical size limit to the gcode file size currently?

First very interesting software, great for my Ultimaker :)

So I`m trying to upload a Gcode file with the webinterface of octoprint, the progressbar fills then is looses connection to the server (server is offline). No file is added to uploads folder. it should be in the /home/pi/.octoprint/uploads folder right?

Probably just missing something obvious.

-----EDIT--------
Problem is solved, KISSlicer was saving the code with file extension (.g), changed it to (.gcode) and problem was gone.

Hello. First I must say it's a brilliant work.

I have a trouble with running multiple printers. Multiple instances can be very easily mistaken.

My printers have names and colour codes, it would be awesome if we could set different titles and color of top bar :-)

Not sure if this belongs in this application or not but having feedback on how much filament remains becomes important when you're not sitting there watching the reel unwind :)

My printer doesn't have any awareness of this, but it would be nice if I could tell the PrinterWebUI when I load a new reel, specify the length and have it keep track of how many mm get consumed by each job so I can have a ballpark idea as to if there's enough left before I submit a new job.

I realize that it's not going to be super accurate, but it might prevent me from submitting a big print remotely only to find out it ran out half way through.

The temp controls often don't reflect the inputs i make - When i hit "set", neither the graph shows the target nor is the target numerically displayed.

(comment by Thomas Sanladerer at https://plus.google.com/u/0/106003970953341660077/posts/cvDcYeE3MFG)

Printer is a Mendel90

On my pi i had to

sudo chown pi /dev/ttyAMA0

From the log from the dom.

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyAMA0
Connected to: Serial<id=0x130b950, open=True>(port='/dev/ttyAMA0', 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'
Send: M105
Send: M105
Send: M105
Changing monitoring state from 'Connecting' to 'Closed'
Connection closed, closing down monitor Changing monitoring state from 'Offline' to 'Opening serial port' Connecting to: /dev/ttyAMA0 Connected to: Serial<id=0x13a77d0, open=True>(port='/dev/ttyAMA0', 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' Send: M105 Send: M105 Send: M105 Changing monitoring state from 'Connecting' to 'Closed' Connection closed, closing down monitor

Any thoughts?

Hello,

The program is great, but I'm experiencing one minor issue that may be due to my own lack of experience. I am running on a fresh install of Raspbian (the Feb 9 image) and everything runs fine from the command line. However, I'd like to have it auto-start, so I added the line

/home/pi/OctoPrint/run

to /etc/rc.local. This does not seem to start the server, so I've additionally tried

python2.7 -m /home/pi/OctoPrint/octoprint.server

and a few variations on these two lines. It seems that rc.local is running (I added touch /home/pi/rclocal_working and on reboot the file appeared) but I'm not sure how exactly to call Octoprint from it.

Thanks for the help!

I'm noticing if I leave OctoPrint running for a few hours it's memory increases gradually from 10% to 30% on my rasp pi. I'm wondering if this is to do with the verbose text log being held in memory.

Perhaps limiting the size of the log to the last X lines and also removing the repetitive M105 from the logs.

With many files uploaded, the page height increases and you need to scroll around, if the file operations where inside a tab, your screen for monitoring would be more suited for a phone or tablet

Any chance you can implement folders for files?

Use case: Printing a prusa i2 takes 6 full plates for me. I'd like to upload prusa i2 folder easily then choose which plate to print.

In the filelist, PrinterWebUi cant delete files with (), atleast if the upload directory in config.ini is a mounted share from a remote source (/mnt/router_usb)

It loads files with () fine

feel free to mess around with my PrinterWebUi at http://mosnet.mine.nu:5000/ (if its online, but should be)

I switched my firmware from Sprinter to Marlin and Octoprint is no longer able to connect to the printer:

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyUSB0
Connected to: Serial<id=0x19f0070, open=True>(port='/dev/ttyUSB0', 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: 
Send: M105
Send: M105
Send: M105
Send: M105
Recv: start
Changing monitoring state from 'Connecting' to 'Closed'
Connection closed, closing down monitor

Here's what I get when connecting to the printer via Pronterface:

echo:Marlin 1.0.1 RRP
echo: Last Updated: 2012-12-21-JMG | Author: RepRapPro
echo: Free Memory: 11197  PlannerBufferBytes: 1232
echo:Using Default settings:
echo:Steps per unit:
echo:  M92 X91.429 Y91.429 Z4000.000 E875.000
echo:Maximum feedrates (mm/s):
echo:  M203 X300.000 Y3

Is it possible you'd need to wait for that "start" command before trying to send the M105 commands?

From looking at the sources, it seems to be AGPL licensed but it's not immediately obvious under which license OctoPrint is released. I'd recommend to include a copy of the license text in a LICENSE file.

I am using the devel branch, I am unable to use auto detect to determine the serial port. I have tried editing the config.yaml file but it doesn't seem to make any difference only "AUTO" and "Virtual" are listed.

It appears that the display of the model printing in the gcode viewer is more of an approximation based on the time estimate rather that what the printer is actually doing. At least in my case, the display is considerably ahead of what is printing. I suppose it could be the delta between what has been buffered in the server and what has been actually been sent to the printer, but that seems unlikely given the sometimes significant delta. Some clarification would be helpful.

While the current UI functionally works perfectly on smartphones, it requires frequent zooming and panning (or holding the phone in landscape) to do stuff. An interface with a single column layout and larger buttons would be more suitable for a portrait smartphone.
Lowest priority for me.

I noticed when I printed the same gcode file using PrinterWebUI and Pronterface that the cooling fan for the nozzle doesn't get turned on when printing with PrinterWebUI.

I assume that both controllers would just pass the gcode on to the RAMPS firmware the same, so I don't know why it would be different, but it's something I observed so I thought I should pass it on.

When sending the M105 command, my RepRapPro Huxley answers with current temperatures only:

Send: M105
Recv: ok T:198 B:59

There's no info about the current target. It should be possible to watch the gcode for any temperature target changes within OctoPrint itself and adjust the UI accordingly.

Pronterface has a feature where you can configure custom GCode commands which will be shown as buttons in the UI. Might be a cool idea for OctoPrint as well, this way people can easily add certain printer specific features (like fan on/off) themselves.

Automatically tick off successfully printed files (BotQueue asks you if the file printed well and then loads and prints the next file. The successfully printed one is marked "complete" and archived.)

(comment by Thomas Sanladerer at https://plus.google.com/u/0/106003970953341660077/posts/cvDcYeE3MFG)

OctoPrint on a Raspberry Pi has no config.yaml when installed. If yone is added in the ~/OctoPrint or ~/OctoPrint/octoprint folder it seems to be ignored.

Am I putting this file in the wrong place?

By the way, excellent work on this! I love printing from ymPi with this setup!

I've been having some communication issues with the repetier firmware. The most current causes octoprint to stop responding when reading the bed temp from the M105 command

I am getting this error:

Exception in thread Thread-4:
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: 

This is the output from the terminal tab.

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.

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,
Tom

[Feature request] Drag and Drop file uploading would be nice to have - Slic3r also expects its files to be dropped in, so most of the time a file browser will be open anyways with the folder containing the stl & gcode.

And last, but not least least: My printer reproducibly got disconnected shorty after it had heated up.

(comment by Thomas Sanladerer at https://plus.google.com/u/0/106003970953341660077/posts/cvDcYeE3MFG)

Printer is a Mendel90

Log:

...
Recv: T:236.56 E:0 B:86.2
Recv: T:236.47 E:0 B:85.8
Recv: T:236.38
Send: N60G1 X132.434 Y69.127 E2.13450*77
Recv: ok
Send: N61G1 X133.924 Y70.357 E2.16766*79
Recv: Error:No Checksum with line number, Last Line:57
Changing monitoring state from 'Printing' to 'Error: No Checksum with lin...'
Recv: Resend:58
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line:57
Recv: Resend:58
Recv: ok

But I'm also getting these a couple of times:

Communication timeout during printing, forcing a line

I'd guess those are caused by the printer not communicating right during longer (homing) moves - Homing Z takes around half a minute one-ways (homes to max).

Is it possible to send a sequence of commands / macro with a custom control? That'd be very useful.

Settings such as default port and default baudrate should be configurable via a settings page.

File uploading is a bit weird right now:

• The progress bar goes from 0 to 100%, then stays there. This looks broken. I'd suggest to keep it at 100% for a second, then reset it to 0.
• Files are sorted alphabetically, if multiple pages of files are available my new file might land on a not shown page. Either switch to the right page after uploading, or sort the files by upload date.
• It seems that it takes a while after upload before the file shows up in the list. I thought my upload failed, but after clicking around for a while it suddenly was in the list. I think the file name should be immediately available, even if meta data isn't

all tested on a current devel branch on a raspberry pi

I just had a print stop because OctoPrint lost connection with the printer for some reason:

Communication timeout during printing, forcing a line

Disconnecting and reconnecting fixed the error and OctoPrint continued to correctly show the temperatures. However, clicking the "print" button did reset the whole print job making it start from scratch instead of continuing where it left off. Would be nice if it could have simply continued. Maybe even doing the disconnect/connect thing itself after having a timeout for multiple times in a row.

I noticed a couple of things when printing to my PrintrBot Jr with OctoPrint running on a Raspberry Pi...

1)When you load a file into OctoPrint the CPU utilization goes to 100% in the OctoPrint process for a minute or two. It appears the file is being prepped for printing, however the status display above the print button is not updated with the file name so you can't actually use the prepped file. So, in order to print the file, you need to click on the file name, then the open folder icon, then wait for the progress indication to complete, then print. And at the end of the print job, the CPU utilization stays at almost 100% for a minute or two after the job is completed. My guess is that Octoprint is pre-processing the job 3 times, once when you load it, once when you hit the icon to load it, and possibly once when the job is done. At least that is my observation without digging into the code.

2)When running OctoPrint, I noticed that the Raspberry Pi would occasionally crash or I would lose the video feed if I brought a second Octoprint browser window up on another computer. This would happen when I wanted to check on the status of a print job when I was away from the my desktop computer, but had left the browser pointed on the Desktop pointed at OctoPrint. Some measurements revealed that video feed sucked up about 5% of the CPU utilization and double if an additional browser was added. A running print job varied between 35% and 75% CPU utilization, and as mentioned above when processing the print job during loading was 90% plus. I found a nice utility called "cpulimit" that I was able to add to the rc.local file to cap the OctoPrint process around 70% CPU utilization. This seemed to create a more stable environment, particularly when multiple browser windows were up. At least so far.

While it is already possible to save the preferred serial port and baudrate to configuration, a lot of other configuration options have been added since this got introduced that could also profit from being editable via the UI itself instead of forcing to user to SSH into the server box.

The preferred goal would be to allow full configuration via a new settings dialog accessible from the top navigation bar.

Would be nice to have a few common "interactive" gcodes linked to buttons on the UI. Extruder +/- would be nice for loading, motors off, etc.

I'm not sure if the best way to do this is to add a specific number of controls or to add a tab for "custom" buttons, or something completely different. I definitely like the clean-ness of the UI and I'd hate to see it turn into one of those "pages of buttons" apps, but there are a couple things I end up using for almost every print that would be handy.

For now I'll just keep a gcode ref handy (in fact maybe that would be a nice thing to have on the term page... ;)

I am installing on a Raspberry pi and notices the video end needs Subversion installed.

It would be helpful to have a button or link to shutdown the Raspberry Pi. This would be nicer than using SSH to shutdown the Pi at the end of the day.

Is the Makerbot Replicator Dual (first generation) supported by OctoPrint, because we are unable to connect to the printer. When I plug in the printer via USB a see "/dev/ttyACM0" appearing in the Serial Port Select Box but whatever baud rate I choose, I can't connect.

Any ideas?

From the comments to https://plus.google.com/u/0/106003970953341660077/posts/91bgT8eGioW:

May I suggest a safety feature? The ability to cut power to the printer in case something crazy
happens, such as loss of usb connectivity to the printer so you can't power it down?

Maybe make it 'pluggable' via script so some people can use an x-10 module, and others a Belkin,
etc. 

A print job should be able to be restarted after it has been paused.
There are legitimate reasons to have to restart a print job shortly after starting (wrong z-height, etc) and it becomes cumbersome to have to stop, set temperatures again, and start. Being able to pause, make adjustments, then restart would greatly simplify this process.

The new GCode viewer is absolutely awesome! However, the options below the viewer seem to do nothing for me. I assume they should unfold some settings?

I don't get any JS errors though. Tested on Chromium 24

There could maybe be a admin password to configure for access to printer hardware ? and if
user doesnt provide correct password, user are degraded to a view only experience.

I have 2 nosy teenagers in the house/lan after I showed them that they could watch their prints
from remote :)

I am playing around with the config file, and would like to create a button that sends multiple lines of command with one click. (Specifically, one button that is labeled warmup that turns on the extruder, bed, and fan to my standard values.) If I list multiple lines of "command:" the button only executes the last one, listing all the commands in one line confuses Marlin, and \n is not interpreted as a newline character. Is there a different newline character that would work, or is it currently only one command per button?

For writing a proper start/stop script it would help if the server would do the daemonizing (detaching from the current process) itself and write the PID to a lockfile in /var/run/octoprint. Maybe when a flag --daemon is passed only.

Moving STDOUT and STDERR to a specified log location and way to influence the amount of logged output would be the next step.

Port autodetect didn't recognize my printer on /dev/ttyACM0 (Arduino Mega). Manually selecting the port did.

(comment by Thomas Sanladerer at https://plus.google.com/u/0/106003970953341660077/posts/cvDcYeE3MFG)

Printer is a Mendel90