Started print, and it started heating up. I thought it was working fine since 1.2.14 wouldn't even display the temperature curves after hitting Print. However, after canceling the temperatures continued to ramp up no matter that I tried to set them to off, and then to 0. I had to reset the RAMPS board, and unplugged/reconnected the arduino to the Pi to be safe.
I think this might be a bug that's unrelated to the one we're pursuing. Probably worth testing when we reach a stable point again.
I retried the print, this time letting it go through, and it started printing fine. I canceled the print, and the temperatures fell off on a curve like you'd expect.
Service restart didn't do the job. Trying to print, the temp graph went away and everything stopped responding. The terminal output didn't seem garbled though. I rebooted, and it's timing out.
Reloaded after restarting service, and tried a print. Hotend temp hit target and the bed didn't start showing up as heating. I checked the terminal and there was a bunch of garbled junk in it. Rebooted, reset RAMPS, and power cycled the Arduino.
Tried to print again, this time the print button causes comms to drop right after "Changing monitoriing state from 'Operational' to 'Printing'". No temp readout, no more info in the terminal. Cancel does not bring back comms.
Still broken. I tried to print and lost all control again, starting with temp feedback. So this time instead of rebooting, I tried to disconnect...which it eventually did (it took ten seconds or more). When I reconnected, it gave me temp feedback but I think the application was stuck in some half state. I couldn't cancel, and I couldn't manually set the temp to zero (I was locked out). I had to reset RAMPS, power cycle the Arduino, and I rebooted the Pi for good measure.
Still broken. Tried to print, same story. This time I checked the terminal immediately, and saw:
Recv: Error:No Checksum with line number, Last Line: 1
This time I hit cancel before disconnecting / reconnecting. When it reconnected, the temps were dropping. The thing still doesn't print, but at least the temps aren't ramping out of control. Rebooted for another clean start.
Note to self: It'd be nice to have a way to power cycle the Arduino and the RAMPS board remotely from the Pi shell (OctoPrint necessarily, since we're debugging that now).
Appears to work normally. It's printing.
937487037aeae452d1656e2fc38870b8203eb5a6 is the first bad commit
commit 937487037aeae452d1656e2fc38870b8203eb5a6
Author: Gina Häußge <osd@foosel.net>
Date: Wed Jul 13 17:21:45 2016 +0200
Shorter timeout during heatup & no scary message on end
Set read timeout on serial port to a much shorter value (default 2.0s)
during a heatup. Firmware should usually send the current temperature
back every second, so if that stops we can consider the heatup to be finished
even if we don't see an ok.
That is important in cases such as SD printing, where we might see a
heatup sequence we didn't trigger ourselves, during which we shouldn't spam
the printer with commands it potentially can't process but after which we
still should take up normal communication again. In case of a heatup sequence
triggered by an SD print we won't see an ok and hence only can now through a
timeout that things are now done printer side. In such a case the user should not
get thrown a scary timeout message in their general direction either.
Solves #1409
:040000 040000 e7c9b9aee3e49b1133fdf576ad8156ff83684038 bd689ab66de2c357220d08ee1316037183085b38 M src