Closed Magoo0876 closed 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.
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.
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.
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.
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.
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?
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.
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:
and these were after i changed the timing and ran the PID again:
I did not save the pid values from before, but this my current setting with div6:
I understand basically how pid works but not what to expect with the values.
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
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.
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
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?
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.
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.
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
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
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
Then repeat 1 to 10 while setting DIV to specified above values each time. Then post all logs and images here.
Is this correct?
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
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:
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:
Sorry it has taken me so long. klippy_stm32f1_div8.log
@macminoz You might want to do a PID calibration.
@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)
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.
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
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.
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.
Okay, thanks. I committed the DIV8 change to the master branch (commit b6ebf5cb).
-Kevin
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
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. 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.
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.
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 :)
@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.
I just did your mod and it works 100 % for me. The waveform / response is finally smooth and matching with real temperatures. Thanks.
@thebrakshow or @sedlacekdavid
I'd like to try this fix as well. Is this the correct spot to create the short?
@gitalpaca you want to create 2 shorts across the 2 components so they effectively are not there.
@gitalpaca you want to create 2 shorts across the 2 components so they effectively are not there.
That make a lot more sense. Re-reading your previous comment I can see it now. I'm glad I asked. Thanks!
Great catch. I'l try this fix as soon as I can.
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.
so hardware soldering is the only solution here? thanks!
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.
@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.
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.
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!
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.
Changed back to div4. Looks great.
Graph is great until printing. I will change it to DIV8 when printer completes to compare graphs.
Looks much better with DIV8 over DIV4, even with the hardware fix.
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.
Looks much better with DIV8 over DIV4, even with the hardware fix.
I noticed the same, where I can get the DIV8 now ? thx
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.
@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.
@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..
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
hope that clears things up.
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