Looks like you got a longer cable for the camera - does it work well? Where did you get it from?
Printable View
Looks like you got a longer cable for the camera - does it work well? Where did you get it from?
I'm also using the Raspberry Pi camera board with a longer cable, I didn't notice any loss of image quality compared to the shorter cable.
I bought a 24 inch long cable from Adafruit for 3 bucks: https://www.adafruit.com/products/1731 They have a variety of lengths as well.
What are the plusses/minuses of using a usb webcam v/s the pi camera?
I'm also using the Raspberry Pi camera with a 24" cable.
I use a webcam. One of the minuses for it is if you have any LEDs on the X extruder carriage to light up your print area, they will often "wash out" the image so you can't see the print. There is no brightness setting for using a USB camera, as opposed to using the RPi camera. Another minus would be you'd have to come up with your own mounting solution if someone else hasn't designed one for your particular webcam, unlike the RPi camera, which has many mounts and cases designed for it already. A plus for the USB webcam is long cords, you can put it anywhere. So far all I've seen is a maximum of 24 inches for the RPi camera, which may limit its location options.
Here is my setup using part of a white LED strip for light. I need to print another holder for the lights in black instead of yellow, but I went with I had at the time. The Pi will eventually be mounted to the side wood at the top of the printer along with relays for controlling the power to the printer, fans, and lights.
Lights on:
Attachment 4196
Lights off:
Attachment 4197
Has anyone come up with a fix for Octoprint and ABL line error timeouts?
I can't seem to print anything because octoprint is erroring because it is forcing lines instead of waiting on custom gcode to finish like G29 for ABL
Increase the Communication Timeout to 300. That worked for me.
It's in the settings dialog in the UI.
I think that has solved the last of my reliability issues. The symptom on the timeout was that it would occasionally finish the ABL, run my prime and wipe sequence and then stop, with the nozzle on the bed, everything hot, and not actually print anything. The terminal had lots of messages about retransmitting lines and the firmware deciding that it was getting the wrong line number.
I got mine from Amazon:
http://www.amazon.com/gp/product/B00...?ie=UTF8&psc=1
The AdaFruit cable is cheaper--until you factor in shipping. I have Prime, so...
I have one printer with the Pi camera and one with a Microsoft webcam. The pi camera is easier to mount, and it works, but the colors are awful if you have fluorescent or LED lighting. I had to break the lens loose and screw it out a turn or so to get the camera to focus close enough. I'm also getting very slow frame rates from the Pi camera. I would have thought it would be faster.
The USB webcam (Microsoft LifeCam Cinema) works great. It has much better color and it auto-focuses, which is both a blessing and a curse. The frame rate seems much better as well, and it doesn't seem to interfere with printing. I don't have a mount for it yet, but probably will design something soon.
Yep with that fixed and the fan re rtsed i printed your x carraige without any warping :-) now to print the rest and get ready to tear it all apart do i can rebuild and retune it :-P
To print tomorrow...
New unwarped abl mounts and foot... Part cooling will be needed at some point might as well go ahead and print it along with the makerfarm cold end...
Then its time to break it and make it better :-D
Yeah, with the timeout at its original setting, OctoPrint would just keep firing off gcodes to the printer without waiting for an acknowledgement. And the printer is busy during a G29, and can't acknowledge. When G29 finishes and the printer finally opens up and starts taking commands again, it's expecting (say) command 29, while OctoPrint is sending it command 250. That's where the "wrong line number" comes from.
Has anyone tried replacing their LCD with OctoPiPanel + PiTFT?
Not yet, but I have been wondering if it was possible to connect the LCD to the RasPi.
You're probably better off replacing it with the cheap 2.8" 320x240 full-colour touchscreens that adafruit sells. That's my plan anyhow.
got my webcam in today and all setup :-)
Now i can watch my prints from another room or if it is a fairly short build i can build from work and watch to make sure nothing goes wrong :-)
sniffle.is-a-geek.net :-) for those bored people that like watching printers run :-P
I was previously able to use Octoprint on my Raspberry B+ with the baud rate of 115200 (I think). After upgrading the Makerfarm/Ramps to the Itty Bitty Dual extruder, I can't connect at any rate.
I see in configuration.h the rate is set at 250000 but every setting in Octoprint returns "Connecting..." until the timeout.
Any tips?
Code:Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyAMA0
Connected to: Serial<id=0x29494b0, open=True>(port='/dev/ttyAMA0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: M105
Send: M105
Send: M105
Send: M105
Send: M105
Changing monitoring state from 'Connecting' to 'Closed'
You should be connecting to /dev/tty/ACM0. /dev/tty/AMA0 is the built-in serial port of the Pi.
I fought that demon myself for quite a while. /dev/tty/ACM0 only appears when the Pi can see the RAMPS via USB. Not sure what causes it to not detect it at times. Restarting OctoPrint seems to resolve it most times, occasionally I have had to reboot the Pi itself.
I used to struggle with this as well as a number of other seemingly random instabilities. I think the 5v regulator on the Arduino isn't really up to the task. With RAMPS and the LCD, it's very close to what it can handle--even on the Taurino Power. Adding a servo to the 5v rail caused me all kinds of instability. In the end, I cutt D1 off the RAMPS board and supplied 5v from the power supply to the +5v and VCC pins (no jumper) as well as to the Raspberry Pi through the GPIO pins, all with separate runs back to the power supply. This fixed pretty much all of the random symptoms I was having, including Octopi falling to start on boot and the Pi crashing or rebooting mid print.
I use a 4-40V buck regulator to get 5V from the 12V line of my power supply. This in turn powers the servo and the Pi.
I'm using the 5VSB output from my power supply. That way, I can also connect the power supply switch line (green wire) to the PS-ON terminal of the RAMPS board, and I can turn the power supply on and off with M80/M81. Since the Rpi and arduino are on the standby line, they're always on, waiting for me to VPN in and start a print job.
Has anybody experienced random disconnections between the Pi and their printer?
While doing some testing today, on multiple occasions, I would get an error from the printer, according to OctoPrint, and it would disconnect. Each time this happened it was in the first 20 seconds of a print.
I am thinking it might be a power related issue, any other thoughts?
If you power your Pi from your printer power supply, that might be the problem. I have mine plugged into a phone charger, separate from the printer supply. I have not experienced any random disconnections.
Same here i have my pi powered by a i believe 1.5amp phone charger and heavy gauge usb cable. Its enough to power the pi and c310 camera witbout hiccups.
Hmm... Mine is powered from a 2A phone charger as well. In thinking it might have been a power issue, I removed the camera, but still had the issue.
Hmm... Odd... If the pi is rebooting that generallg means its drawing too much power... The cheap usb cables usually cant handle a decent current throughput the small wires just wont permit it... If you have a stock cell phone cable that is thicker/stiffer than the others you have try using it and see if it might fix the problem.
Much like heated beds suffer on the 12" printer if you dont have 12awg wire because the smaller wire limits your current... Beyond that i wont be much help im not a pi or linux guru... I know just enough to get myself into trouble and google a way back out...
It isn't rebooting, I just get some error message and the print stops abruptly.
The "terminal" provides an error from the printer saying that the current line isn't the last line +1 so it stops printing and the connection to the printer is closed.
It just happened 3 times in a row... :/
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Changing monitoring state from 'Printing' to 'Error: Printer requested li...'
Recv: ok
Recv: ok
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Recv: Error:Line Number is not Last Line Number+1, Last Line: 58
Recv: Resend: 59
Recv: ok
Ooohhhh do you have abl enabled?
No sir, I am running dacb's firmware though, with the no_abl configuration.h file.
As a test, I removed the wireless NIC and am using a cable now. We shall see if it makes any difference. At this point I am guessing. haha
Hmmm... It could be from you homing taking too long i know wierd... Later updates fixed it but if you start a print and watch the command line in octoprint and it starts yalking about forcing next line while it does your print star procedure you need to extrnd one of the timeout settings.
I believe it is the communication timeout... But could be connection timeout... By extending that it forces octoprint to wait for the printer to be ready instead of octoprint trying to rush the printer when it cant.
Yeah, it would be the communication timeout. I increased mine to 300 to accommodate ABL. The printer (for some reason) is ignoring incoming commands from OctoPrint while it does something, but OctoPrint keeps sending commands anyway. Then when the printer starts taking commands again, it's looking for line 25 (or so), while OctoPrint is sending it line 250. That's when it fails. Increasing the communication timeout makes OctoPrint wait longer for an "okay" from the printer before sending the next line.
Excellent, thank you everyone. I will make the changes and see if it settles down.
There are a few things that can cause this.
1. Power issues: The Pi needs a solid power supply. The 5V regulator on the Arduino will not suffice. If you have an ABL servo, this will make things even worse. If you cut D1 (RAMPS) and power everything from the 5V rail of your supply, you should be okay. Running separate wires from the supply to RAMPS +5, RAMPS VCC and the Pi is best. Using a cell phone style supply for the Pi is probably also fine.
2. Timeouts. If you run an ABL sequence at the beginning of your job, OctoPrint can give up because it isn't getting anything back from the printer during the sequence. If the carriage is high and it takes a long time to get back down to zero, the same can happen. Increase the communication timeout in OctoPrint to fix this. I think mine is set to 150 seconds.
3. Floating endstops. If you have your max endstops enabled with the pullups disabled, the printer will still work most of the time, but they can false trigger with power rail noise. Make sure your max endstops are disabled in the firmware if you aren't using them.