ESP8266-Load-Cell
ESP8266-Load-Cell copied to clipboard
Skaronator
Crash every now & then
I have all running, i added a scale set option since when i restart i would not be in bed ;)
Problem is it sometimes just 'dies'. When that happens it restarts dumping errors on the screen before restarting. Somtimes it works for a long time and sometimes it just goes into the reboot phase.
Is there anything i can do to improve this/debug?
Other then that, the instructions where just fine. Only thing i didn't know was that you need the molds otherwise it doesn't bend correctly. (i was just pressing it for testing, gives weird values)
Hi there, this might be a duplicate of #6 already. Just wanted to let you know we are working on https://github.com/bogde/HX711/pull/123, which you might want to give a try. It is an attempt to remedy some of the issues of the Arduino HX711 library, especially when it comes to appropriate ESP8266 and ESP32 support.
i have a wemos mini i believe, but if this would reduce the 'crashes' that would certainly help. Time is shorthanded but if i do i'll test it out.
@bogde confirmed that the revamped code works out of the box with a WeMos D1 mini (ESP8266) already. There are chances it might be actually behave better as the library gained minor but important improvements through suggestions from the community.
So, if you like give it a try. However I can't promise the overall system stability will actually be better using the improved HX711 code as there might be other things involved. Good luck!
@amotl i've tested it out, it does seem a lot more stable now. Only weird thing is that i get random values sometimes.
14:29:34.216 -> Pushing new result: 0 14:51:40.903 -> Pushing new result: -43 14:51:41.417 -> Pushing new result: 0 15:01:47.977 -> Pushing new result: -1 15:01:48.566 -> Pushing new result: 0 15:06:54.438 -> Pushing new result: -1 15:06:54.954 -> Pushing new result: 0 23:13:29.948 -> Pushing new result: -1 23:13:30.427 -> Pushing new result: 22 23:13:30.939 -> Pushing new result: 0 20:25:56.308 -> Pushing new result: 20 20:25:56.792 -> Pushing new result: 0 21:05:25.949 -> Pushing new result: 2 21:05:26.461 -> Pushing new result: 5 21:05:27.487 -> Pushing new result: 6 <- munually pushed on it 21:05:27.966 -> Pushing new result: 4 21:05:28.481 -> Pushing new result: 0 21:06:53.328 -> Pushing new result: -42 21:06:53.840 -> Pushing new result: 0
When it happens its pretty quick to drop back to 0, have no load on it. But its a bit weird to be so spikey (this is in kg)
Dear @riemers,
i've tested it out, it does seem a lot more stable now
Thanks for testing, sounds good.
Only weird thing is that i get random values sometimes.
The readings as displayed are obviously weird. While we did our best to incorporate all the relevant changes into https://github.com/bogde/HX711/pull/123 where some of them also account for reading the data from the hardware using faster chips, there might still be issues with the ESP8266 we dearly would like to find out about.
Research
When searching for other issues about random readings over at https://github.com/bogde/HX711, I've found two issues which might be relevant:
- https://github.com/bogde/HX711/issues/28#issuecomment-191370341
I actually stopped using the HX711 because at higher read rates (40Hz) it would seem to randomly give bad data. I have a suspicion this is actually due to the internal buffer getting updated with a new conversion while you're still clocking out the previous conversion data. I also needed 100Hz conversion, so I moved to ADS1232 with an external clock.
- https://github.com/bogde/HX711/issues/47
Thoughts
So, while the current code should account for properly slowing down the reading from the hardware appropriately (https://github.com/bogde/HX711/blob/0.7.2/src/HX711.cpp#L36-L62), let's check this twice: Can we humbly ask you to run your sketch either with reduced clock speed or by adjusting the value used within the calls to delayMicroseconds(1); there?
Advise
We would also recommend to open a corresponding issue over at https://github.com/bogde/HX711/issues/new to get more eyeballs on that.
Thanks already for your efforts.
With kind regards, Andreas.
I'll see what i can do, i still have the "test" setup on my desk. Just need some time :)
Also noticed some crashes again:
14:36:50.017 -> Pushing new result: 0
14:36:57.611 -> [WiFi] Disconnected from Wi-Fi!
14:36:58.568 -> Pushing new result: 3
14:36:59.050 -> Pushing new result: 0
14:36:59.627 -> [WiFi] Connecting to n176...
14:36:59.627 ->
14:36:59.627 -> Exception (9):
14:36:59.662 -> epc1=0x40105068 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000
14:36:59.766 ->
14:36:59.766 -> >>>stack>>>
14:36:59.766 ->
14:36:59.766 -> ctx: sys
14:36:59.766 -> sp: 3fffed10 end: 3fffffb0 offset: 01a0
14:36:59.835 -> 3fffeeb0: 40105294 21f39217 3ffee968 00000000
15:30:44.045 -> Pushing new result: 0
16:31:21.412 -> [WiFi] Disconnected from Wi-Fi!
16:31:23.395 -> [WiFi] Connecting to n176...
16:31:23.395 ->
16:31:23.395 -> Exception (9):
16:31:23.429 -> epc1=0x40105068 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000
16:31:23.531 ->
16:31:23.531 -> >>>stack>>>
16:31:23.531 ->
16:31:23.531 -> ctx: sys
16:31:23.531 -> sp: 3fffed10 end: 3fffffb0 offset: 01a0
16:31:23.600 -> 3fffeeb0: 40105294 1f4dd11d 3ffee968 00000000
Looking at this, the wifi is disconnecting for some reason, but when it reconnects it crashes.
Later on:
16:31:32.688 -> [WiFi] Connecting to n176...
16:31:33.204 -> Pushing new result: 0
16:31:33.887 -> [WiFi] Disconnected from Wi-Fi!
16:31:34.644 -> [WiFi] Connected, IP address: 192.168.1.23
16:31:34.678 -> [MQTT] Connecting to MQTT...
16:31:49.273 -> Pushing new result: -0
16:31:51.290 -> Pushing new result: 0
Seems that if it wants to push a new value while it was disconnect or just about might make it crash. (assuming not related to hx711(
Your saying to delay, but do you mean a delay in my void loop? Since it already has a 100ms delay.
Changed it to 200ms since it has 5 samples total of 1 second. Seeing if it still goes up and down, changed the decimal value to show 0.0 instead of 0 (too maybe see more too)
p.s. i normally press the weight and get about 5kg, but because of the random you can see this now:
Is it normal that it crashes totally too? I changed the sample rates:
#define SAMPLE_PERIOD 100 // sample period in ms #define NUM_SAMPLES 10 // number of samples - max 255 - published mqtt update every NUM_SAMPLES * SAMPLE_PERIOD = ms
22:43:11.645 -> [WiFi] Disconnected from Wi-Fi!
22:43:13.130 -> Pushing new result: 0.0
22:43:14.520 -> [WiFi] Disconnected from Wi-Fi!
22:43:18.154 -> Pushing new result: -0.0
22:43:19.158 -> Pushing new result: 0.0
22:43:19.503 -> [WiFi] Connecting to n176...
22:43:26.987 -> H⸮)2
Also notice no longer a blue light anymore and no reaction anymore. But with 100/10 it was not better. With 200/5 it was only a few kg minus sometimes. I'll try 300/3 now :)
Dear @riemers,
sorry that it doesn't work for you. Would there be any chance you could try this with a more recent firmware version? I believe the ESP8266 had some issue with older firmwares which have been similar to what you are reporting. Also, I haven't investigated LoadCell.ino in detail yet, where things might go wrong too.
With kind regards, Andreas.
@amotl i'am pretty new to the boards, i only know i can flash a sketch from arduino ide or use the espeasy which also seems to support hx711 in the test environment. Have a wemos d1 mini and have yet to find a newer 'firmware'. I tried espeasy too, but this is just an easy gui thing for people, not really my thing when it comes to keeping it clean and simple ;) any pointers/hints and i'll check it out.
Thanks for the insight, @riemers. Then, I would recommend to start small again by testing with one of the canonical examples provided with the HX711 library.
Why not start over with the most basic one (HX711_basic_example.ino) again, in order to check that this (hopefully!) does not crash your machine.
Ah yes, start from basic is a good idea too. I have it hooked up to the com anyways. I can just let it sit and see if its stable and then expand if it runs good for a few days etc etc. I'll keep you posted (then you know if it has any relationship with hx711)
20:50:15.387 -> HX711 reading: -150552 20:50:16.380 -> HX711 not found. 20:50:17.403 -> HX711 reading: -150494
That normal now and then?
Interesting, thanks for letting us know. I really can't tell anything about effects like that. Obviously all of us expect stable readings and I didn't hear about corresponding reports either.
As far as I learned, many things can contribute to things going wrong when reading the HX711.
"not found" would actually be a bit misleading here. It should really be called "not available" or "unable to read" or such.
Is the rate of valid readings acceptable for you? I mean, if they're actually valid then.
Well you have to tare it, but other then that the value is now around -151000 and its doesn't go higher/lower then +- 250 side ways. (From what i gather, thats pretty descent)
The not found has happened now 8 times since 20:37 till now. I would call that "acceptable" since we read it out so many times anyways.
Hi @riemers,
when taking a reading each second, eight faulty readings during more than two hours also seems acceptable for this ensemble of hardware and software, right? We are not conducting measurements for ATLAS here in the end.
With kind regards, Andreas.
Indeed, i'll leave it spitting out values for a couple of days. I normally had about 1 or 2 days tops before it went for a coffee break.
Did some more testing, found out that the example was doing just fine. Only difference was that it sits at 115200. Had mine at 9600. Weirdly enough my original sketch is running now fine for 3 days without a crash when i changed it to 115200. Might be luck? Dunno but i'll keep it running for the weekend too and if it does then that was the culprit (although i believe it should not matter at all right?)
@amotl well its been running now for more then a week and has not crashed anymore. Is it really that silly that the speed @ 115200 makes it not crash? Either way, i'am happy its running ok now :)
@riemers it does make some sense though. since serial communication is now faster, it's less likely for that to interfere with anything else. glad it works for you now. cheers!
Thanks for letting us know, have a good weekend and also cheers!
P.S.: Shall we close this or keep it open for some more cpu cycles?
We can close this, but a note somewhere might be good althought the example was with a higher rate. That was the only thing different when testing.