Sunday 5 March 2017

New and exciting problems! Well... not so exciting it turned out in the end.

Printing journal (I hope)

Printing glass marker. Temp 22C, 999hPa, 48%, Z offset 0.5.

Whether due to me interfering with the early stages of a print, or something fatally breaking, I don't know, but the printer now doesn't take commands. I had done calibration, and before starting a print, I turned off the extruder and on the bed. The print started as normal, except when it had heated the bed and gone into heating position for the extruder, it didn't set the extruder temperature.

Several variations of turning things on and off later, the extruder temperature still didn't get set, and occasionally even homing didn't seem to take. The temperature is measured fine, though.

Now keeping careful log:

Closed Pronterface and kept the printer off for 5 seconds. Connected, which took seconds, then it didn't register homing.

After I had written the above, it homed. I started a print, it went straight into heating position, then didn't set temperature.

RepRapPro has a lengthy article about what can go wrong related to temperature. However, I can set temperatures manually, so it's not fully dead.

When I turn on debug communications, I get wrong-looking output:

>>> M105
SENDING:M105
T:22.5 E:0 W:?

There should be more in there - also the temperature listing on the left is missing the target, it shows the same as above. The graphs show about 20C for the extruder, though

Manually set extruder to 120 and bed to 60. No apparent increase in temperature.

Tried lifting the Z axis to better feel the extruder, but it didn't budge. Homing didn't work either. Turned off everything and went to have brunch.

Later I used my laptop for a print, and it went totally smooth (the print process, not the print itself):

It's a piece that fits on a standard IKEA glass so we can tell which is whose

Coming back even later. Z offset 0.5, and I was able to set the temperature for that (since I don't want old filament on the hotend to influence the offset). Temperature 21C, humidity 994hPa, moisture 36% (outside). When printing, no temperature gets set. Weird. Maybe Pronterface is just being stupid and it's time to try...

Octoprint!

I already installed it a while back. Starting it gave a webserver at port 5000, with a security check (http only, though, so not that useful). The settings are pretty nice, but there's no obvious way to set a Z offset, which I need until I get autocalibration in. Homing is split between X/Y and Y. I copied over the start/end commands, and added commands on connection to prepare for calibration.

There's a Slic3r plugin on GitHub, but right now I'll just reuse the GCode.

Like Pronterface, this doesn't like to say where the printer currently thinks it is. Again, no heating happens. The following commands were sent:

Send: N0 M110 N0*125
Recv: ok
Send: N1 G28*18
Recv: ok
Send: N2 G1 Z5 F5000*6
Recv: ok
Send: N3 M107*38
Recv: ok
Send: N4 M190 P60*89
Recv: ok
Send: N5 M104 P220*99
Recv: ok
Send: N6 G28*21
Recv: ok
Send: N7 G1 Z5 F5000*3
Recv: ok
Send: N8 M109 P220*99

The N* is just line numbers. The M190 P60 is setting bed temperature, and the *38 is a checksum. So that looks fine. (Yes, it homes twice, due to extra start GCode I pasted in). Sending it manually does nothing, nor does the temperature controls work. There's still temperature data coming back, though.

Tried powercycling the printer in case it had got into a stuck state (waiting for a temperature that never goes anywhere?). Now it won't connect. Restarting Octoprint doesn't help. 

Restarted Pi and printer both. On start, it nicely connects, gets ready to calibrate, and shows the actual temperature and targets after M105 commands. I can use the controls to set the target, and that works (OctoPrint doesn't poll that often, so the curves are more jagged, but it doesn't do the confusing autoscale).

Sending the commands above in sequence worked fine, until N4, where it just ignored it. Still sending back full temperature reports, though. The N8 M109 P220*99 command is the killer. The argument apparently should be S220, not P220, according to RepRapWiki. That's Slic3r's fault - which makes sense, then, since the laptop uses a different version of Slic3r.

And there, in one of the printer settings, lies the answer: It was set to a different GCode flavor. Why this happened now, I have no idea, but after switching it to Marlin, it works perfectly. Another cube came out just right:

Still slight gappiness in the top, but otherwise nice.

No comments:

Post a Comment