Thermistor of the heatbed gives spikes

[Javier-Moreno-Blanc]

After upgrading my 3D printer from Arduino+Ramps 1.4 and LCD12864 display to MKS Gen 1.4 with MKS TFT 32 display, I detected that the heatbed thermistor on this screen shows errors in temperature measurement (I have attached several images for you to understand).

In order to recognize the cause of this error, I have carried out 30 tests (clearly organized and classified in a table) in order to have some conclusions and to share the results so that we can find a solution to this problem.

As we can see in the table, the different tests are focused on the type of motherboard, motor driver, thermistor type, Marlin version and its adaptation to the type of machine, and also among other things, the laminator used and the monitoring system.

From the table, with great caution, we can see:

1. Monitoring systems such as Pronterface or LCD12864, unlike the Simplify3D control panel and MKS TFT 32 display, do not display these spikes on the thermistor of the heatbed.
2. In current versions of Marlin (e.g. 1.1.7 or 1.1.8) if you define a Core XY type machine, the monitoring system displays these spikes, but if you use a Core XZ typology the measurement errors disappear. I also don't see errors if you don't use a Core distribution
3. In order to use a Core XY machine type we should go back to version 1.1.0. RC6
4. A strange aspect refers to the slicer used, where we can see that while with Simplify3D or Slic3r the measurement error begins when the movement of the engines begins and is present throughout the printing process, with the Cura slicer, we only have one peak (tends to 0 ºC) at the time of starting the movement of the engines.
5. The thermistor measurement error does not depend on the type of thermistor or the length of its cable.
6. I can cause these errors if during the heating process I send the gcode G92 command, and surely also the G28 command (all the parts I send you start like this).

These tests are performed with the entire control system on a test table and with the engines running at no load. For the configuration.h file, simply use any original file and adapt it for a transfer rate of 115200 In addition to the images (different scenarios) and the table, I attach a .gcode file generated with each slicer software

References: [1.1.7]Strange spikes on bed temperature sensor #8859

after update to newest firmware, temeprature jumps around #5776

Combine fixes for LIN_ADVANCE and temperature ISR #5829

Temperature Spikes (Heatbed) #5805

Attachments

Test table: Thermistor of the heatbed gives spikes.xlsx .gcode files (.zip): drive-download-20180513T213022Z-001.zip

Slicer by Cura with a heatbed at 0 ºC

Slicer by Cura with a heatbed at 50 ºC

Slicer by Simplify3D with a heatbed at 50 ºC

Slicer by Simplify3D with a heatbed at 0 ºC

[thinkyhead]

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[Javier-Moreno-Blanc]

Thank you for your quick response @thinkyhead

I checked version bugfix-1.1.x and with the Core XY configuration it still gives the same problem. Again, with a Core XZ typology this problem does not exist.

With this same version of Marlin I have done a test in which I have not activated the heatbed thermistor on Marlin (TEMP_SENSOR_BED 0) and I verify that when I load a .gcode, the Simplify3D monitoring system only shows one indicator, but when printing starts another measurement appears that repeats the same behavior pattern. The 3D model is laminated with Simplify3D and the temperature of the heatbed was set at 0ºC in the Simplify3D configuration.

[Javier-Moreno-Blanc]

I have done another test and it seems (it is hard to evaluate with certainty) that if we use a PID heatbed temperature control, this system is not affected by this disorder in the thermistor measurements.

[thinkyhead]

Does Repetier Host also show these errant temperature readings?

[rjacobs1969]

I just build a new coreYX machine when I noticed this problem, bed temperature reading sometimes jumping to 700+ degrees. the bug is still there in the latest 1.1.x bugfix branch.

[thinkyhead]

@rjacobs1969 — What's your TEMP_SENSOR_BED setting? Do you also see the problem go away when using PIDTEMPBED?

[rjacobs1969]

TEMP_SENSOR_BED 11 (also tried with 1) in limited testing it doesn't happen with PIDTEMPBED (however even after some PID tunes the bed does not get/stay on the set temperature.. resulting sooner or later in a temp error)

[Javier-Moreno-Blanc]

In my case, when you activate PIDTEMPBED these spikes seem to have no effect on the control and I manage to maintain a stable temperature, but the thermistor still shows the spikes (as detailed at the beginning of the case).

[thinkyhead]

Are the temperature spikes visible in the output of M105 in the console?

[rjacobs1969]

I'll check this weekend

[Javier-Moreno-Blanc]

I think it's hard to throw the M105 and just then you'll "catch" the spike, won't you?

[thinkyhead]

I think it's hard to throw the M105 and just then you'll "catch" the spike, won't you?

M105 or M115 are the only ways that a spike is ever seen by a host. And every temperature reading (thermistor) in Marlin is the result of 16 ADC samples averaged together.

[rjacobs1969]

I don't think it's the actual measurement. yesterday I saw a temperature of -1600 for the bed while homing, it lasted the entire time the bed was moving. As the minimum temp that can be measured is -14 (when ntc is disconnected) it must be something else... overriding a variable or memory location comes to mind.

[thinkyhead]

I saw a temperature of -1600 for the bed while homing, it lasted the entire time the bed was moving.

Again, unless you're seeing this as the output of M105 / M115 (auto-report) we can't tell if it's Marlin or just the host being weird.

[rjacobs1969]

same "host" (a Mks tft display) connected to my other printer (running marlin 1.1.4) does not show the problem but as said earlier I will try to capture output of m105 /m115 this weekend.

[aurion55]

I'm using a PT100 on a CoreXY using 1.1.8 and I'm having issues as well the temperature is fluctuating 10 degrees in Pronterface, also while PID tuning it jumping up and down 10 degrees. I've replace the PT100 board I'm still having the same problem, the thermistor it OK. I do some more testing back with the stock thermistor.

[moth4017]

HI also seeing this issue V2.0 on core xy, Rearm heated bed thermistor , but i have noticed that it always spikes just at the start of the G29 command in my script and then again just before it starts to print, sometimes halting the print altogether.

[moth4017]

I have managed to get the spike to accrue on a G28 command , with no heaters on at all .

Which makes me think it is noise from the stepper motors some how getting into the ADC input on the micro (ReArm) all my stepper motor leads are quite long but they are all twisted to help minimize the noise.

the next thing to do is wire from the ramps to the headed bed direct and away from all other cabling. will try tomorrow.

[aurion55]

No mind what doing it at low temperature jumping all over the place once it was heated up, it run fine. But was annoying when it keep drop out on low bed temp, and has to keep reset the Board, so I rip it all out for now, and when back to stock thermistor Bloody waste of money as No-one can get it to work properly as far as I can see. That my thoughts as well, I think the cable need shield back to the board to stop any interference. .

[moth4017]

ok , i did some tests, removed the thermistor from the ramps board, and added a 10K resistor across the pins on the ramps board ( temp around 78 deg) ran a G28 and got the same issue as above , so i shorted out the pins on the ramps board (temp around 690 Deg) ran G28 again and got the same result as above big spikes around 2000 deg. so if it is noise is getting from either the PSU or from the stepper motors into the ramps board, not sure how to resolve this... or is it a software/firmware issue.

[p3p]

On the LPC176x boards, unless designed incredibly well (they aren't), the ADCs are very susceptible to noise, but because of this I added a huge amount of software filtering making it 'impossible' for spikes to be read from the hardware (at the cost of a little lag), so this is a bit odd. can you show serial communication rather than a graph so we know what your host is interpreting.

[moth4017]

serial communication?

im using the printer tethered via USB so are you referring to the communication window in the control software, i do have some of the debug lines active in Marlin, or is there another serial stream you are referring too?

[p3p]

I just mean the communication window that shows the gcode that is sent and responses received.

[moth4017]

SENT: G28

SENT: M105

READ: echo:busy: processing

busy: processing

SENT: M105

READ: echo:busy: processing

busy: processing

SENT: M105

[p3p]

There is no temperature response in those, I need to know what temperature is being reported from Marlin when the spike happens.

[moth4017]

the G code never shows the spike , even though the graph does

Log Output

``` SENT: G28 SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: echo:busy: processing busy: processing SENT: M105 READ: X:176.00 Y:148.00 Z:0.00 E:0.00 Count A:103680 B:8960 Z:0 READ: ok READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 READ: ok T:73.95 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:74.90 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:78.99 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:83.33 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:86.59 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:90.49 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:94.90 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:97.99 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:101.74 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:105.57 /200.00 B:0.00 /0.00 @:127 B@:0 SENT: M105 READ: ok T:109.50 /200.00 B:0.00 /0.00 @:127 B@:0 ```

[p3p]

Then we have to assume its an issue with the host software, possibly not liking that it isn't getting responses during the homing procedure?

[moth4017]

it also happens , with UBL and also while its printing, sometimes it stops the printer sometimes not, which is very annoying with a long print.

Only happens when stepper motors x or y are moving , might be z , but not extruder

[moth4017]

so after 5 hours of leaving on test and just moving the Z access no spike issues showing up. as soon as i move x and y i get an issue.

[dudi300]

Hi, I have the same problem with Marlin and XY-Core on my machine. Is there already a solution? If not, here are my observations: I use S3D and Marlin 2.0 with 32-bit arm. The bed temperature flips in the bedtemp programm display, as well as in the graphics (between app. -8000 °C up to 900 °C). I also have a Mks display parallel to the ControlBoard (SBase 1.3), here is showen the same wrong temperature. On my second machine XY-Core with Atmel 16 bit and Marlin 1.8 is the same behavior observed. I imagine, that the error is only during the printing, regardless of the set temperature. The temperature control does not seem to be affected, the bed has during the printing the set temperature.

Regards

[Javier-Moreno-Blanc]

I think there is no solution, but this error does not affect the correct PID of the hot bed.

[p3p]

If Marlin is reporting the wrong temperature to hosts it will be visible in the serial traffic, if you can supply a log showing this it will be much easier to track this down, the previous comment above showed no error in Marlins reporting even though the host showed the error leading to the conclusion that the problem was with the host.

[dudi300]

So, I dump the comport and I found this: Temperature for the Bed is 50°
It goes wrong if its not like this B:xx.xx /xx.xx
If the value is wrong, it has no decimal place.

I hope it helps... Regards

Write this command: 003317: 2019-03-31 18:01:41,7857257 +0,0000070 <--- This is the Timestamp of the Snifferprogram

47 39 32 20 45 30 0A 47 31 20 45 2D 31 30 2E 30 > G92 E0.G1 E-10.0 < TxData from S3D 30 30 30 20 46 39 30 30 > 000 F900

Read this : 003330: 2019-03-31 18:01:41,8093979 +0,0000024 <--- Timestamp

6F 6B 0A > ok. < RxData from Marlin

003350: 2019-03-31 18:01:41,8312754 +0,0000024 <--- Timestamp

58 3A 31 35 34 2E 30 33 20 59 3A 31 35 37 2E 30 > X:154.03 Y:157.0 30 20 5A 3A 30 2E 38 30 20 45 3A 30 2E 30 30 20 > 0 Z:0.80 E:0.00 43 6F 75 6E 74 20 41 3A 35 31 37 31 34 20 42 3A > Count A:51714 B: 2D 37 31 31 20 5A 3A 36 30 33 0A 6F 6B 0A > -711 Z:603.ok.

003588: 2019-03-31 18:01:41,8525874 +0,0000024

6F > ok

Some more:

58 3A 31 36 33 2E 32 30 20 59 3A 31 36 35 2E 30 > X:163.20 Y:165.0 30 20 5A 3A 30 2E 38 30 20 45 3A 30 2E 30 30 20 > 0 Z:0.80 E:0.00 43 6F 75 6E 74 20 41 3A 35 32 33 38 31 20 42 3A > Count A:52381 B: 39 33 20 5A 3A 36 31 33 0A 6F 6B 0A > 93 Z:613.ok.

000476: 2019-03-31 18:01:34,8273408 +0,0000024

6F 6B 0A > ok.

000502: 2019-03-31 18:01:34,9179946 +0,0000027

6F 6B 0A > ok.

000522: 2019-03-31 18:01:34,9246737 +0,0000030

6F 6B 0A 6F 6B 20 54 3A 32 30 30 2E 35 36 20 2F > ok.ok T:200.56 / 32 30 30 2E 30 30 > 200.00

000550: 2019-03-31 18:01:34,9271457 +0,0000024

20 42 3A 35 30 2E 30 30 20 2F 35 30 2E 30 30 20 > B:50.00 /50.00 <----This is ok 40 3A 38 39 20 42 40 3A 30 0A 6F 6B 0A > @:89 B@:0.ok.

000614: 2019-03-31 18:01:34,9391119 +0,0000027

6F 6B 0A > ok.

. . .

6F 6B 0A > ok.

001034: 2019-03-31 18:01:35,4324387 +0,0000018

6F 6B 0A 58 3A 31 36 38 2E 31 35 20 59 3A 31 36 > ok.X:168.15 Y:16 30 2E 32 30 20 5A 3A 30 2E 38 30 20 45 3A 30 2E > 0.20 Z:0.80 E:0. 30 30 20 43 6F 75 6E 74 20 41 3A 35 32 31 35 34 > 00 Count A:52154 20 42 3A 37 30 20 5A 3A 39 33 32 0A 6F 6B 0A 6F > B:70 Z:932.ok.o 6B 0A

k. 001344: 2019-03-31 18:01:35,4403698 +0,0000015

6F 6B 0A > ok.

001368: 2019-03-31 18:01:35,4445244 +0,0000018

6F 6B 0A > ok.

. . . 6F 6B 0A > ok.

001742: 2019-03-31 18:01:36,4108271 +0,0000027

6F 6B 0A > ok.

001762: 2019-03-31 18:01:36,4198027 +0,0000021

58 3A 31 36 39 2E 37 36 20 59 3A 31 36 38 2E 32 > X:169.76 Y:168.2 30 20 5A 3A 30 2E 38 30 20 45 3A 30 2E 30 30 20 > 0 Z:0.80 E:0.00 43 6F 75 6E 74 20 41 3A 35 33 31 32 34 20 42 3A > Count A:53124 B: 31 32 38 36 20 5A 3A 36 32 35 0A 6F 6B 0A > 1286 Z:625.ok.

002018: 2019-03-31 18:01:36,4328239 +0,0000021

6F 6B 0A > ok.

002032: 2019-03-31 18:01:36,4356038 +0,0000021

6F 6B 0A > ok.

002046: 2019-03-31 18:01:36,4578894 +0,0000024

6F 6B 0A > ok.

002070: 2019-03-31 18:01:36,4803582 +0,0000030

6F 6B 0A > ok.

002090: 2019-03-31 18:01:36,4842691 +0,0000018

6F 6B 0A 58 3A 31 37 35 2E 39 37 20 59 3A 31 37 > ok.X:175.97 Y:17 33 2E 30 30 20 5A 3A 30 2E 38 30 20 45 3A 30 2E > 3.00 Z:0.80 E:0. 30 30 20 43 6F 75 6E 74 20 41 3A 35 33 34 33 31 > 00 Count A:53431 20 42 3A 31 31 34 33 20 5A 3A 36 32 39 0A 6F 6B > B:1143 Z:629.ok 0A 6F 6B 0A > .ok.

002286: 2019-03-31 18:01:36,7675157 +0,0000027

6F 6B 0A > ok.

6F 6B 0A 6F 6B 20 54 3A 32 30 30 2E 30 30 20 2F > ok.ok T:200.00 / 32 30 30 2E 30 30 > 200.00

012168: 2019-03-31 18:01:50,8173453 +0,0000015

20 42 3A 34 39 2E 37 35 20 2F 35 30 2E 30 30 20 > B:49.75 /50.00<--- This is ok. 40 3A 39 33 20 42 40 3A 31 32 37 0A 6F 6B 0A > @:93 B@:127.ok.

6F 6B 0A > ok.

013888: 2019-03-31 18:01:52,2145908 +0,0000024

58 3A 31 36 38 2E 39 33 20 59 3A 31 36 34 2E 38 > X:168.93 Y:164.8 36 20 5A 3A 31 2E 30 30 20 45 3A 30 2E 30 30 20 > 6 Z:1.00 E:0.00 43 6F 75 6E 74 20 41 3A 35 33 36 36 32 20 42 3A > Count A:53662 B: 32 32 31 20 5A 3A 37 38 39 0A 6F 6B 0A > 221 Z:789.ok.

014212: 2019-03-31 18:01:52,2273166 +0,0000024

6F 6B 0A > ok.

[AnHardt]

So the temperatures reported as well as the report it selves is ok. What fails is the host program, taking the stepper B steps of the position report as a bed temperature.

[dudi300]

@ AnHardt: Yes, you're right. Count A: 53662 B: 221 Z: 789B: 49.75 / 50.00.ok. <--- That's finished B: 49.75 / 50.00 @: 93 B @: 127.ok. <--- And that's also complete. It seems they are just looking for the token "B:" and interpret this as bed temperature. I'll mail that on to S3D/MKS and let's see what happens ...

[dudi300]

Now I was curious. I have looked at the sources of Marlin and I have found something. The probem actually only occurs on XYZ printers and some other. See code.

void Stepper::report_positions() {

// Protect the access to the position. const bool was_enabled = STEPPER_ISR_ENABLED(); if (was_enabled) DISABLE_STEPPER_DRIVER_INTERRUPT();

const int32_t xpos = count_position[X_AXIS], ypos = count_position[Y_AXIS], zpos = count_position[Z_AXIS];

if (was_enabled) ENABLE_STEPPER_DRIVER_INTERRUPT();

if CORE_IS_XY || CORE_IS_XZ || ENABLED(DELTA) || IS_SCARA

SERIAL_ECHOPGM(MSG_COUNT_A);

else

SERIAL_ECHOPGM(MSG_COUNT_X);

endif

SERIAL_ECHO(xpos);

#if CORE_IS_XY || CORE_IS_YZ || ENABLED(DELTA) || IS_SCARA _SERIALECHOPGM(" B:");

else

SERIAL_ECHOPGM(" Y:");

endif

SERIAL_ECHO(ypos);

if CORE_IS_XZ || CORE_IS_YZ || ENABLED(DELTA)

SERIAL_ECHOPGM(" C:");

else

SERIAL_ECHOPGM(" Z:");

endif

SERIAL_ECHO(zpos);

SERIAL_EOL(); }

[thinkyhead]

@dudi300 I don’t see any problem with that code.

[dudi300]

Of course, nothing is wrong with the code. Only the sent B: of the count causes disturbances in the bed temperature value of MKS-TFT3.2 display and in S3D. But only if it is XYZ core printer #(if CORE_IS_XY ) is selected. Othwerwise the firmware sends a 'Y:' for that. For my part, I made the 'B:' a 'D:' as a workaround in the sources and compiled the Marlin 2.0 code again and the displayed temperature problems are solved.

Now my stream is like this.
X:186.01 Y:197.32 Z:2.00 E:0.00 Count A:62775 D:1647 Z:1594

See also @Javier-Moreno-Blanc commented on 14 May 2018

[thinkyhead]

Whoever coded those hosts needs to fix their temperature reading logic. They are apparently looking for "B:" without considering the context. Hopefully they will patch their products soon. Meanwhile, maybe we'll add an option to leave out stepper counts in the current position report.

[ozayturay]

Is there any workaround? How about changing A and B to Alpha and Beta in CoreXY?

[dudi300]

It is in the file "...2.0.x\Marlin\src\module\stepper.cpp" and see all my comments above @ "dudi300 commented on 12 Apr" as instructions. It's simple.

By the way, s3d released version 4.1.2. Nothing was changed here. The error is still present. It seems to be a chicken / egg problem ... (I send a mail to s3d). Regards

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.