<p>Since the terminal temperatures never exceed the setpoints, there's no apparent potential for disaster.   Whether it's due to missing readings or to some sequencing of power (current) applied to the bed vs. the hotend, it really doesn't matter.   </p>

<p>If you have a similar graph of the temperatures over an hour of printing and you see signifcant anomalies there, that might be of interest. </p>

CC BY-SA 4.0
2019-04-15T17:21:21.240Z
2019-04-15T17:21:21.240Z
Carl Witthoft
<p>It looks like everything is ok with the real temperature, and it is just Octoprint missing some readings, like Oscar said. 
But I think it is unlikely the USB cables fault, the whole print would fail in that case. I think the PI is to busy, maybe due to a Webcam streaming at high rate (try reducing the framerate). Another reason might be if you use a PI Zero W, especially if you transfer data over the Wifi at the same time, since Wifi and USB cause bottlenecks for each other on that board.</p>

<p>PS. I'd comment, but don't have privilege yet.</p>

CC BY-SA 4.0
2019-04-14T18:32:14.597Z
2019-04-14T18:32:14.597Z
Kjell
<p>During my last print I noticed this jumpy behavior during heat up (blue is bed, red is hotend):</p>

<p><a href="https://i.sstatic.net/KlD2K.png" rel="nofollow noreferrer" title="Graph of heatbed and hotend temperature over time"><img src="https://i.sstatic.net/KlD2K.png" alt="Graph of heatbed and hotend temperature over time" title="Graph of heatbed and hotend temperature over time"></a></p>

<p>So I am wondering about the jumps. What could cause this? I do not think that it is a defunct sensor (it is in both sensors) and I also don't think it is real. Could this pose some sort of hazard as temperature might not properly be controlled?</p>

<p>I use an Anet A8 printer with Marlin 1.1.9 and Octoprint</p>

CC BY-SA 4.0
2019-04-14T09:45:46.863Z
Looking at the graph, it looks like OctoPrint is missing temperature readings from the sensor considering that a) thermal runaway protection is not kicking in, b) the heating curve continues the path it has set in by recovering to the position it should be after failed readings/measurements. You could try to change the USB cable between OctoPrint and printer board.
0scar
<anet-a8><heat-management>
Bed and nozzle temperature jumping
Till B
# Bed and nozzle temperature jumping

(Asked by: username_0 on 2019-04-14)

During my last print I noticed this jumpy behavior during heat up (blue is bed, red is hotend):

[![Graph of heatbed and hotend temperature over time](https://i.sstatic.net/KlD2K.png "Graph of heatbed and hotend temperature over time")](https://i.sstatic.net/KlD2K.png "Graph of heatbed and hotend temperature over time")

So I am wondering about the jumps. What could cause this? I do not think that it is a defunct sensor (it is in both sensors) and I also don't think it is real. Could this pose some sort of hazard as temperature might not properly be controlled?

I use an Anet A8 printer with Marlin 1.1.9 and Octoprint

**Tags:** anet-a8, heat-management
> **Comments:**
> **username_1**: Looking at the graph, it looks like OctoPrint is missing temperature readings from the sensor considering that a) thermal runaway protection is not kicking in, b) the heating curve continues the path it has set in by recovering to the position it should be after failed readings/measurements. You could try to change the USB cable between OctoPrint and printer board.  

---

## 2 answers

### Answer by username_2 on 2019-04-15. Score: 3

Since the terminal temperatures never exceed the setpoints, there's no apparent potential for disaster. Whether it's due to missing readings or to some sequencing of power (current) applied to the bed vs. the hotend, it really doesn't matter.

If you have a similar graph of the temperatures over an hour of printing and you see signifcant anomalies there, that might be of interest.


---

### Answer by username_3 on 2019-04-14. Score: 2

It looks like everything is ok with the real temperature, and it is just Octoprint missing some readings, like Oscar said.
But I think it is unlikely the USB cables fault, the whole print would fail in that case. I think the PI is to busy, maybe due to a Webcam streaming at high rate (try reducing the framerate). Another reason might be if you use a PI Zero W, especially if you transfer data over the Wifi at the same time, since Wifi and USB cause bottlenecks for each other on that board.

PS. I'd comment, but don't have privilege yet.


---

