Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.28k stars 5.27k forks source link

SKR Mini E3 V1.2 wrong temperature measurement #2194

Closed Magoo0876 closed 4 years ago

Magoo0876 commented 4 years ago

Hi,

I've played a bit with the new SKR mini E3 V1.2 board and liked it so far, but something was strange. After some time I've measured the head and bed temperatures, and they were too low. My sensors are 104GT-2 on the bed and B3950 on the hotted .

bed set to 60 measured 50 hottend set to 200 measured 160

I've played with the pull-up resistor setting and found that 6k almost compensates the error. Also different sensor type settings did not do the expected.

So I think the internal pulldown resistors of the STM32F102 are activated and this would cause a higher temperature reading for the software. I also tried to activate the pull-up resistors for the thermistor input pin, but this is not a possible setting in the config.

Thank's for your help.

klippy.log

markwinger commented 4 years ago

Thanks. I had that change in my previous version but when I cloned a new one I lost it.

Room temp now reads 24.2 on the terminal, 24.0 with the ir scanner. Now back to the other testing.

markwinger commented 4 years ago

Looks like I had the fix wrong before. Now the stepping that was obvious before, is gone. In the terminal I can see it skipping .1 or .2 degrees instead of 2 or 3 degrees as before. Even with the ticks set back to original. It takes a long time for the bed to get to ambient temp so I'll confirm temps in a few hours.

brianrjones69 commented 4 years ago

That is interesting that it worked with just setting the ADC clock divider alone. I previously thought that increasing the sample time just a little bit fixed the issue for me. After an update, I threw all my changes away and started increasing things and trying them, but I think that during my testing the firmware was not getting updated. Maybe I will start over after this print is done.

BTW, if you have a removable glass bed, you can put it in the freezer to get it cooled down faster.

markwinger commented 4 years ago

I have had troubles with the sd card. When I put a new version on, the firmware.bin gets copied to FIRMWARE.CUR, but the firmware.bin file remains and I cannot delete it. I have to file check the device and it moves the file to lost and found dir. Then I can put a new one on. This does not happen everytime but is a pain.

markwinger commented 4 years ago

I am at ambient temp now and the bed is 25.3 according to the ir scanner, and the terminal shows 24.7. Same result with ticks set to 4 or 7.

brianrjones69 commented 4 years ago

I had the same issue with the sd card last time. This time I powered off the printer and disconnected the USB cable, waited 15 seconds, turned the printer on, waited 15 seconds, plugged the USB cable in, waited 10 seconds, restarted klipper.

I just reran my tests. DIV4 doesnt work regardless of ticks, but DIV6 works. So, I think my theory on the sample time cannot be correct. But why does DIV6 work?

markwinger commented 4 years ago

I just re-ran pid tuning. This looks so much better. I had visable stepping in the temps that made me suspicous of the tuning. Now the temp for the hotend shows sine wave like behavior and the bed like a saw tooth. Very much like mks gen-L I had previously.

I feel much better about it now.

l-Kage-l commented 4 years ago

I just changed the settings in stm32f1.c to DIV6 and run the PID test, and yeah, the stepping is almost completely gone. They are not as drastic as before, but when i observed the PID tune, the values were much more, jumpy(?) i would say. They'd change much faster, and that should be from the clock change i did earlier, right? Im just waiting for the bed to cool down to ambient temp now. Will update this later.

Quick edit if this helps somehow: These were the values for the PID BEFORE i changed the clock timing:

*# [extruder]

*# control = pid

*# pid_kp = 27.819

*# pid_ki = 1.656

*# pid_kd = 116.840

*# [heater_bed]

*# control = pid

*# pid_kp = 55.950

*# pid_ki = 1.030

*# pid_kd = 759.518

*

and these were after i changed the timing and ran the PID again:

*# [extruder]

*# control = pid

*# pid_kp = 26.751

*# pid_ki = 1.564

*# pid_kd = 114.361

*

*# [heater_bed]

*# control = pid

*# pid_kp = 69.541

*# pid_ki = 1.396

*# pid_kd = 865.791

*

markwinger commented 4 years ago

I did not save the pid values from before, but this my current setting with div6:

*# [extruder]

*# control = pid

*# pid_kp = 22.099

*# pid_ki = 1.091

*# pid_kd = 111.874

*

*# [heater_bed]

*# control = pid

*# pid_kp = 69.514

*# pid_ki = 1.609

*# pid_kd = 750.753

*

I understand basically how pid works but not what to expect with the values.

KevinOConnor commented 4 years ago

Setting DIV6 will run the ADC at 6Mhz instead of 9Mhz. It shouldn't be necessary to run the ADC that slow, but it should not be a problem either. I'll take a look at it if someone can attach a log file with a pristine copy of Klipper showing a heating cycle (25 degrees to 60 degrees) and also attach a log file with a "DIV6" version of Klipper showing the same heating cycle on the same board.

-Kevin

inthroxify commented 4 years ago

Setting DIV6 will run the ADC at 6Mhz instead of 9Mhz. It shouldn't be necessary to run the ADC that slow, but it should not be a problem either. I'll take a look at it if someone can attach a log file with a pristine copy of Klipper showing a heating cycle (25 degrees to 60 degrees) and also attach a log file with a "DIV6" version of Klipper showing the same heating cycle on the same board.

-Kevin

I've got this board, and this problem. I tried the DIV6 change; I changed only the single line in klipper/src/stm32/stm32f1.c near line 145, changing DIV4 to DIV6, and recompiling. Attached are the logs of a heat cycle from 25 to 60 degrees, for both DIV6 and stock firmware. I had to set the temperature to 1 degree on the heater instead of 0 to keep the log going after hitting the target temperature and turning the heaters off... it took a while to figure out why the log kept stopping on the down slope.

Also attached are screenshots of the octoprint graphs for these cycles, to get a sneak peek.

I see an improvement.

klippy.div6.log klippy.stock.log div6 stock

KevinOConnor commented 4 years ago

Thanks, but the provided log is not complete and the "stock" log was not running the pristine code from this repo. FWIW, it looks to me like both DIV4 and DIV6 show similar temperature "steps". Given the fear of introducing a regression on other functional boards, I'm inclined to leave the main Klipper code as it is unless we can document overwhelming evidence of an improvement.

-Kevin

inthroxify commented 4 years ago

the "stock" log was not running the pristine code from this repo.

Dunno what to tell you brother, I literally followed the instructions from Installation.md, installed the firmware, found this stepping issue, and then came here and tried the single DIV6 line. Those are the 2 firmwares I've got.

FWIW, it looks to me like both DIV4 and DIV6 show similar temperature "steps".

If you look at tbe's Marlin graph from 26 days ago and the DIV6 graph I grabbed, the remaining stepping in DIV6 eerily looks like the Marlin graph more than it looks like the DIV4 graph. IMO, DIV6 is as fixed as it is getting without breaking out the soldering iron. I will try Marlin myself to see if I get the same graph as DIV6.

Given the fear of introducing a regression on other functional boards, I'm inclined to leave the main Klipper code as it is

I'm not anybody, but I agree; if I were in your shoes I would do the same. Personally, I am fine patching this fix by hand knowing this issue is available for reference. However, if someone added some appropriate options to the Kconfigs (mentioning a workaround for SKR Mini E3 only if STM32F103 is chosen) and an ifdef in stm32f1.c, would you be open to a PR?

inthroxify commented 4 years ago

So I tested Marlin as per my previous post. The results were enlightening. I've not run Marlin on this board, because irony of ironies, I bought it to exclusively run Klipper and then ran into this issue.

I did 5 comparisons. They are a bit askew, I apologize, but the results are still easy to determine. They all have the same time scale so they are at least comparable. Sorry, no logs, just graphs.

The comparisons:

What? DIV8? I noticed that there was also a DIV8 to go along with DIV4 and DIV6 as above, so I changed DIV6 to DIV8 and compiled and tried it just as an experiment. The results were surprising. I have no idea of the consequences of using DIV8 are for real though.

fwcompare

According to these graphs at least, Marlin never had this right. BTT's own compiled version of Marlin has the same problem. Not that there was a doubt about this hardware being broken, but this definitely confirms it if BTT won't even fix the issue for their own distributed firmware.

I am going to stick with DIV8 for a bit, unless Kevin says that is an insane thing to do, and see how it goes.

brianrjones69 commented 4 years ago

Inthroxify, Nice find. I didnt even try DIV8.

Kevin,
The reason why this thread exists is because when a user looks at the temperature on the display and it is 3 degrees lower than they expected, they think something is wrong. Truth is, 3 degrees C isn't going to effect what we are doing here. But we are all trained to calibrate everything on our printer. Geez, E-Steps, flow, adjust belts, tighten eccentric nuts, print this cube, temperature towers and all. We do know that it is not 16-17 C in the room.

The problem I see is that only 3 people have attempted the change. DIV6 or DIV8 doesn't really change your sampling time much anyway.

-Brian

KevinOConnor commented 4 years ago

I am going to stick with DIV8 for a bit, unless Kevin says that is an insane thing to do, and see how it goes.

FYI, DIV4 sets the ADC frequency to 9Mhz, DIV6 sets it to 6Mhz, and DIV8 sets it to 4.5Mhz. As far as I know, any of the three should work fine.

The problem I see is that only 3 people have attempted the change. DIV6 or DIV8 doesn't really change your sampling time much anyway.

Right. We can make the change to the master branch, but I'd be much more comfortable if I saw a bunch more results. (And in particular, I'd like to see the full log files from the attempts so I have them available for analysis should we see regressions in the future.)

-Kevin

vladbabii commented 4 years ago

I didn't have to test this yet, but i'd like to do it this week. Just to be clear the results are meaningful, i should do this

  1. get latest version klipper
  2. compile and write firmware to board (with make clean)
  3. stop klipper, delete log files, clean up interface
  4. start klipper
  5. start and connect octoprint
  6. set target temp to X
  7. wait to reach temp
  8. remove target temp
  9. wait to reach ambient
  10. save screenshot and logs

Then repeat 1 to 10 while setting DIV to specified above values each time. Then post all logs and images here.

Is this correct?

KevinOConnor commented 4 years ago

Then post all logs and images here.

The screenshots aren't needed (one can graph the temperatures from the log using ./scripts/graphstats.py), but otherwise those steps make sense.

For those that would like to test, but don't want to modify the code, you can use the work-stm32f1-div8-20200421 branch: cd ~/klipper ; git fetch ; git checkout origin/work-stm32f1-div8-20200421 ; sudo service klipper stop ; make ; make flash ; sudo service klipper start

@Magoo0876 - any chance you could test on your fysetc board (to verify no regression)?

-Kevin

macminoz commented 4 years ago

very interesting conversation. I'm right now stuck at this point with v0.8.0-420-gee9657bb with a PT1000 sensor and pullup_resistor 4700 on SKR Mini E3 1.2 and have a look on my graph:

Screenshot 2020-04-21 at 23 56 15

Temperature in the room is controlled.

The print won't start until the temperature stabilise :(

EDIT: I did a try and if I set the temperature manually, everything is good. Once I start the print (Simplify3d) I get this:

image
brianrjones69 commented 4 years ago

Sorry it has taken me so long. klippy_stm32f1_div8.log

klippy_current_master.log

brianrjones69 commented 4 years ago

@macminoz You might want to do a PID calibration.

macminoz commented 4 years ago

@macminoz You might want to do a PID calibration.

PID calibration already done. This happens only when I use a slicer. If I set up the temp manually, it works

EDIT: I'm trying work-stm32f1-div8-20200421 and it seems now I fixed my PT1000 issue....I'm going to better investigate during the next days and I'll report back here (with logs and details)

Magoo0876 commented 4 years ago

Hi Kevin, as you desired I created a log from the Fysetc Cheetah 1.1b board main current and branch. I'm very busy at the moment but try to help as I can.

klippy_branch.log klippy_main.log

markwinger commented 4 years ago

I just created div8 and clean versions. I started with div8 and at the end bed temp read about 25C. I installed the unchanged version (div4) and the ambient temp (maybe 3 minutes later) read 19C confirming the temp difference reported.
klippy.log.clean.txt klippy.log.div8.txt

skyegallup commented 4 years ago

I am using an Ender 3 Pro (originally v1.1.4). The only relevant modification is a mainboard upgrade from a Creality Silent board to a BigTreeTech SKR Mini E3 v1.2. I noticed similar issues to everyone else here, and a few Google searches led me to this issue. This printer and its wiring was known to be working before the mainboard upgrade. The Marlin firmware pre-installed on my Mini E3 reported accurate temperatures, but Klipper reported unusually low ambient temperatures.

For both tests, room temperature is 70°F (just under 21°C). Extruder is commanded to 60°C, bed to 40°C. I confirmed bed temperatures with a digital kitchen thermometer, just to try and provide another point of reference.

master branch: klippy_master.log

work-stm32f1-div8-20200421 branch: klippy_branch.log

For me, the changes made in the work-stm32f1-div8-20200421 branch seem to have fixed the issue. Let me know if there's anything else I can do to help test.

Buerk commented 4 years ago

I had the same problems with a SKR mini E3 V1.2 with my Ender 3 Pro (Klipper Version v0.8.0-448-g1460e0d6): Room temperature 21 °C, Klipper showed 16°C for both the bed and nozzle. With marlin2 temperatures have been correct. After changing from RCC_CFGR_ADCPRE_DIV4 to RCC_CFGR_ADCPRE_DIV6 in stm32f1.c the Temperatures are now O.K: Klipper and thermometer both show same values within tolerance.

KevinOConnor commented 4 years ago

Okay, thanks. I committed the DIV8 change to the master branch (commit b6ebf5cb).

-Kevin

Buerk commented 4 years ago

Hi Kevin, I'm sorry to tell you, that the upstream change (DIV8) didn't work for me: I can see again a deviation in temperature of approx 3°C at ambient temperature (complete cystem cooled down to ambient temperature over night). Only the change with RCC_CFGR_ADCPRE_DIV6 in stm32f1.c currently seems to work for me (no other changes done appart from this). I've double checked the behaviour: With the upstream change I see 18°C for both temperatures (bed+nozzle) at 21°C ambient temperature. With the DIV6 change alone I see both temperature to be at 21°C like the ambient temperature. Note: I've not yet checket the accuracy of heated temperatures since it is difficult the get the very same thermal coupling like the sensor(s) and it doesn't make sense as long as the temperatures deviate from ambient temperature.

This is really odd! Probably something else is broken... I know that fast sampling from high impedance analog sources can tamper adc readings since the sampling capacitor cannot settle to the "real" value. One will see a value depending on the RC curve in this case. Even worse it can be a mixture of the previous channel in such cases. However the thermistor inputs have 10uF capacitors and "only" 100R series resistors at the BTT SKR mini E3 V1.2

thebrakshow commented 4 years ago

I'd like to chime in on this topic. I was having a look at using the E3 on an up coming printer build and was made aware of this issue. After some digging, I noticed an issue in hardware. BTT decided to add some filtering to VDDA (analog reference voltage of the ADC's) on both the positive and ground side. This is typically good practice given the cut off frequency is selected appropriately. However, in the case of the E3, they didn't reference the thermistors to the same VDDA voltage but instead 3.3V from the LDO. VDDA This leads to all sorts of noise in the measurement. They seemed to get the analog_gnd referenced to VSSA correctly, which is why it mostly works.

With that said, I wired up an SKR mini E3. For me, the turn off was where the issue was most noticeable. unknown

Unmoded_E3

I then shorted across the 2 ferrites LV1 and LV2 to essentially bypass them. I did this by creating a solder bridge over top of them so I could easily revert the change. The results looks much cleaner. modded_E3

I happened to have an SKR mini 1.1 laying around so I had a look at it. This board suffers from the same issue. The bed and hotend read 17C with the printer being off for quit some time, my house is set to 73F(~23C). I modified LV1 and LV2 (shorted across them) and sure enough klipper started reading 23C.

TL;DR There is most definitely a hardware issue with the thermistors on SKR mini 1.1, SKR mini E3, and SKR mini E3 DIP. If you are feeling experimental and want to fix the issue in HW vs FW, short across LV1 and LV2 or simply remove them and put a wire or zero ohm resistor in place. I'm not responsible for any damage you do your boards while attempting this mod :)

sedlacekdavid commented 4 years ago

@thebrakshow Hi, this is a very good catch, I think it happens on all SKR minis, but the most of the people don't care. I noticed that when I bought the printer too, I see those steps when temperature falls down and it also measures like 5 deg C below the ambient temperature.

So you just shorted the two ferrites and that's it.

sedlacekdavid commented 4 years ago

I just did your mod and it works 100 % for me. The waveform / response is finally smooth and matching with real temperatures. Thanks.

gitalpaca commented 4 years ago

@thebrakshow or @sedlacekdavid

I'd like to try this fix as well. Is this the correct spot to create the short?

thebrakshow commented 4 years ago

@gitalpaca you want to create 2 shorts across the 2 components so they effectively are not there. image

gitalpaca commented 4 years ago

@gitalpaca you want to create 2 shorts across the 2 components so they effectively are not there. image

That make a lot more sense. Re-reading your previous comment I can see it now. I'm glad I asked. Thanks!

markwinger commented 4 years ago

Great catch. I'l try this fix as soon as I can.

gitalpaca commented 4 years ago

Shorting to bypass LV1 and LV2 worked for me too. I get nice smooth temperature curves now. I don't have a way to measure real temperature, but both the bed and hotend are measuring within half a degree of 22C. That should be about room temperature where the printer is. As far as I'm concerned it's working correctly now.

macminoz commented 4 years ago

so hardware soldering is the only solution here? thanks!

markwinger commented 4 years ago

I started to make the mod but, my eyesight is not what it used to be and my hands are not as steady either (getting old). I was afraid I would accidently remove the parts and not be able to sort across without shorting something else. If anyone has any easy suggestions I'd like to hear them.

thebrakshow commented 4 years ago

@markwinger sorry to hear that. I completely understand not wanting to proceed with the mod. I too, can no longer do these mods without a microscope :D. LV1 and LV2 can be removed and their pads just shorted with a solder blob if that helps any.

@macminoz At this point we are confident this is a true hardware issue. If you read above you can try and work with the FW solution which slows down the ADC.

markwinger commented 4 years ago

I ordered some conduction paint. That should be a lot easier than trying to create a solder bridge so small. It will be a week or so and I will report back once I have tried it.

glabifrons commented 4 years ago

I started to make the mod but, my eyesight is not what it used to be and my hands are not as steady either (getting old). I was afraid I would accidently remove the parts and not be able to sort across without shorting something else. If anyone has any easy suggestions I'd like to hear them.

I'm in the same boat, but with a magnifying visor, surface-mounts are no problem. This thing is absolutely phenomenal: https://www.mpja.com/3-LEVEL-MAGNIFIER-LIGHTED/productinfo/18336+TL/ You can get them on Amazon (with free prime shipping) for only a couple dollars more. Edit: for about half that price, you can get clip-on magnifiers from Harbor Freight, but they're not remotely as clear and well focused as the above-mentioned ones (I have them and still use them a lot, but not for soldering).

Also, I did the soldering and updated via git and the temperature curves couldn't be smoother or more dead-on. Funny thing, the stock Marlin (that my Mini E3 came with) was indicating about 2C high before I reflashed! (printer was off for days, so temp was definitely stable) Nice to have the quiet board back in. Nice work, everyone!

markwinger commented 4 years ago

I bought a CircuitWriter pen, $18.39 at microcenter. Dont wast you money. It goes on easy but was non-conducting. Going to try returning.

I have a set of headword magnifiers (ProsKit MA-016) and the do work well. So I decided to go for it and made the change with a soldering iron. Removed lv1 and lv2 and bridged them.

Results look very good. Room temp of the bed is with .5 degrees of my ir scanner which seems reasonable. And the graphs are sooth. Zooming is shows only small amount of noise. Firmware was modified to run with DIV6 so I will try changing it back to DIV4 and see what it looks like when I get more time.

markwinger commented 4 years ago

Changed back to div4. Looks great. image

markwinger commented 4 years ago

image Graph is great until printing. I will change it to DIV8 when printer completes to compare graphs.

markwinger commented 4 years ago

Looks much better with DIV8 over DIV4, even with the hardware fix. image

markwinger commented 4 years ago

The next time I ran it the noise was like the first. So now it appears the DIV4 to DIV8 did not change anything. The stepping is gone and the temperatures are reasonably stable. I'll try pid tuning (again) next time I get a chance.

macminoz commented 4 years ago

Looks much better with DIV8 over DIV4, even with the hardware fix. image

I noticed the same, where I can get the DIV8 now ? thx

Magoo0876 commented 4 years ago

The hardware fix is nice, but there is still a bad behavior of the board. Heat the hotted and then switch the bed on and off. As you already see in the graphs above, the hotted temp drops when you switch the mosfets on. That destroyed the same print two times on the same spot because if you find a switching sequence the hotted temp will oscillate and reaches the max limit, klipper stops. I replaced the board with the cheetah 1.1b and i'm happy again.

ArkadiuszRaj commented 4 years ago

@thebrakshow from which schematic did you take an excerpt showing DC_3.3V labels? Happens I have checked schematic of SKR mini E3 v1.2 and there is proper voltage.

thebrakshow commented 4 years ago

@ArkadiuszRaj I think I may have put an excerpt of the skr mini 1.1 dip on accident . Either way its still wrong. What BTT should have done is made a net label after the LV1 choke on the uC side and powered the thermistors off of that net, here is a MS Paint modified image of what they should have done.. image

This allows the ADC to be exactly as the same voltage reference .

The crazy part is they got it right on the SKR 1.3

image

hope that clears things up.