Hallo Clemens, da möchte ich doch gleich mal eine Rückmeldung geben. Im Prinzip scheint es bei mir mit dem Code 0.2.8 zu funktionieren! Super!
Wenn ich allerdings versuche den Öffnungswinkel im Automatikmodus kleiner zu stellen, stürzt das Programm bei unter 41% ab und bootet neu. Kann allerdings auch an meinen fliegenden Verkabelungen liegen, oder es ist ein Bedienfehler meinerseits. Morgen werde ich das Ganze mal in ein Gehäuse einbauen und mich erneut versuchen.
Hallo Clemens, ich bin wild am Rumprobieren, allerdings ohne für mich klare Erkenntnisse. Gibt es einen Grund, dass du Version 0.2.8 verwendet hast? Habe aus versehen wieder 0.2.9 verwendet und blicke bei den verwendeten Bibliotheken für 0.2.8 und 0.2.9 nicht mehr durch. Hier also meine Bitte: Falls du weiterkommst, kannst du bitte noch mal die Version plus die entsprechenden Bibliotheken nennen?
Und falls meine Ungeduld nervt, sorry!
Habe es auch zum Laufen bekommen. Nutze die Version 0.2.9 Ob das Display träger ist als V2 kann leider nicht sagen, da ich die V2 nicht kenne.
Glückwunsch! Da kann die neue Ernte ja kommen. 
Kannst du denn den Öffnungswinkel kleiner als 40° einstellen?
Zur “Beruhigung”, ich habe das – Absturz und reboot – beim Drehen des rotarys auch und denke, es liegt nicht an der fliegenden Verkabelungen oder anderen Dingen, und es liegt auch nicht an den 41%, sondern an Problemen in Zusammenhang mit dem rotary / hardware interrupts und der “neuen” Arduino ESP32 core ≥ 2.0, siehe auch: Was muss ich bei Verwendung von zwei Netzteilen (eines für Servo, zweites für Microcontroller) beachten? - #9 by clemens
Bei mir läuft der code stabil, wenn ich die Zeile ca. 307 (je nach code-Version) auskommentiere
// if ( rotating ) delay (1); // wait a little until the bouncing is done
Das delay in der ISR-Funktion ist an sich schon eine schlechte Idee, stammt allerdings aus code snippets, die wir damals gefunden haben und die bisher auch funktioniert haben.
Ob mit der Auskommentierung das bouncing nun schlimmer wird kann ich noch nicht eindeutig sagen, konnte da nix beobachten, allerdings habe ich ja immer noch das Problem mit der allgemeinen Reaktionszeit, was ggf. auch ein bouncing verhindert. Sprich wir müssen erst die Geschichte mit der Reaktionszeit lösen.
Sorry, typo, meine Datei war falsch benannt, habe die 0.2.9 verwendet! Bibliotheken sind alle identisch, ob 0.2.8, 0.2.9 … 0.2.12 …
Ich befürchte noch nicht!! 
Produktiv würde ich das noch nicht nutzen, die Waage reagiert so träge, dass vermutlich die Abfüllung ungenau oder mit Honigüberlauf “funktioniert”. Den Fehler müssen wir noch finden … werde dafür nochmal die verwendeten pins für die Waage tauschen und mir die ISR-Abfrage anschauen und auch nochmal den Zeitverbrauch für einen Mess-Durchlauf ansehen. @aholzhammer meinte, dass im Handbetrieb eine Schleife 180 ms inkl. Messung dauert. Mal schauen wie weit wir davon weg sind. Dann würde ich zu debug-Zwecken die Messung deaktivieren, um zu schauen, ob das der Grund der Verzögerung ist oder die Abfrage des rotary / irgendwas mit ISR. Wer mittesten möchte, gerne!
1 Like
Toll, vielen Dank für das Teilen und die Vorlage dieses Fundes. Hier sollten wir definitiv etwas tun und ein neues Pflaster draufkleben, ähnlich zu Spring cleaning with multiarch support by amotl · Pull Request #123 · bogde/HX711 · GitHub. In diesem Fall scheint es um ein Synchronisationskonstrukt per Spinlock zu gehen?
The use of such a lock is a kind of busy waiting.
Ob bei dem angewendeten delay() “busy wait” der korrekte Begriff ist, kann angezweifelt werden ;]. Zweifelsohne gehört das so jedoch eher nicht in eine ISR Routine – wir müssen sehen, ob wir anders synchronisieren können.
2 Likes
Bin etwas weiter gekommen mit der Analyse, etwas langwierig das ganze. :-( Ein Problem ist definitiv der zähe Programmablauf. Wie gesagt sollte eine Schleife im manuellen Betrieb “normal” bzw. mit bisheriger Hard- und Software ca. 180 ms dauern. Wenn man in Zeile 116 den debug-output mit level 4 aktiviert:
#define isDebug 4
bekommt man die Durchlaufzeiten im Seriellen Monitor angezeigt.
Handbetrieb: Gewicht 0 Winkel 59 Dauer 629 servo_aktiv 1
Leider ist mein subjektiver Eindruck richtig und unser Heltec V3 ist aktuell fast 4x langsamer als die alte Version!
Habe jetzt einen Heltec V2 (!) mit identischem code und als board (1. Test) Heltec V2 (Heltec board definition) bzw. dann auch (2. Test) ESP32 Dev Module (allg. ESP32 board definition) versorgt und die Durchgangszeit gemessen, auch da spuckte die Serielle beides mal ca. 630 ms aus!!
Nun habe ich die allgemeine ESP32 board definition verwendet, allerdings auf den ESP core 1.0.6 downgegradet, sonst alles gleich und sieh, nun ist der Durchlauf mit 174 ms “normal”, es liegt also nicht an irgendwelchen pins, sondern am ESP32 core. Pfff, Problem also etwas weiter eingegrenzt, aber ich habe aktuell keine Lösung oder weitere Idee, wie ich weiter eingrenzen könnte.
Leider können wir als workaround – wie oben schon mal geschrieben – auch nicht einfach den ESP Arduino core 1.x nehmen, da der den ESP32 S3 noch nicht unterstützt, wir müssen also beim core > 2 bleiben und da schauen, was klemmt.
[edit] Mit ESP Arduino core 2.0.3 habe ich die langen Reaktionszeiten, mit core 2.0.2 noch nicht. Bringt uns aber auch nicht weiter, da in 2.0.2 der ESP S3 auch noch nicht verfügbar ist.
1 Like
So, ich hab’s Heureka! Wir haben bisher das Display über Software I2C angesprochen mit (Zeile 156):
U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, /* clock=*/ 15, /* data=*/ 4, /* reset=*/ 16);
bisher hatte ich nur die pins geändert, alles andere so gelassen, funktionierte, aber eben langsam. Nun habe ich auf Hardware I2C (HW in contructor, Achtung, pin order ist dann 'ne andere, zuerst kommt Reset!) umgestellt und mit
U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ 21, /* clock=*/ 18, /* data=*/ 17);
bekomme ich auch wieder die 180 ms
21:15:43.161 -> Handbetrieb: Gewicht 0 Winkel 0 Dauer 179 servo_aktiv 0
was für ein act! Aber es scheint jetzt zu funktionieren. Servo noch nicht dran, ggf. gibts da noch Überraschungen.
2 Likes
Wahnsinn! Wie bist du denn darauf gekommen? Erste spontane Versuche auch mit Servo machen einen guten Eindruck. (mein 41 % Problem scheint allerdings weiter zu bestehen). Morgen bau ich alles noch mal in Ruhe zusammen und gebe dann Rückmeldung. Schönen Abend noch
Hast du das auskommentiert?
Gerade nochmal im manuellen Modus (ohne angeschlossenen Servo) getestet, kann alles von 0 bis 100 % einstellen.
Was passiert bei dir, reboot oder was anderes?
auskommentiert hab ich. Im manuellen Modus gibt es kein Problem. Im Automatik Modus kann ich nach wie vor nicht unter 41% stellen. Allerdings kommt es nicht mehr zu Neubooten…
Dann passt alles, im Automatikmodus ist das default der minimale Öffnungswinkel in der Grobdosierung.
Prima. (bis zu meiner jährlichen Horrorabfüllung mit Probiergläschen für den Weihnachtsmarkt ist ja Gott sei Dank noch viel Zeit)
Ich habe jetzt mal den Servo dran gehängt, und ich glaube deine Befürchtungen bestätigen sich. Alles läuft furchtbar zäh und zwischendurch friert alles ein.
Wieder -ich zu doof, oder gehts dir auch so?
Code ist jetzt upgedated im HaniMandl developer branch mit den bisher auch hier besprochenen Änderungen:
- pins für den Heltec V3 geändert
- U8g2 display contructor auf HW umgestellt
- den de-bouncing code in der ISR-Funktion auskommentiert
Der Servo läuft auch bei mir!
Falle es bei dir, @Kasimir noch Probleme mit dem Servo, gibt ist meist eine insuffiziente Stromversorgung schuld. Bei mir ist – zum Testen – der Servo am 5 V-pin des Heltec angeschlossen. Wenn ich den Heltec dann über meinen USB-Hub am Monitor anschließe resettet der Heltec auch, direkt am Rechner nicht und auch nicht mit einer Power Bank.
1 Like
Hier nun auch die zugehörige Fritzing-Abbildung:
wiring-Diagramme für den Heltec, Version 3
Externe 5V-Stromquelle
2 Likes
Ich weiß das es mal wohl wieder eine dumme Frage sein wird aber wo kann ich die neue Software downloaden??? Gruß
Oder direkt: https://raw.githubusercontent.com/ClemensGruber/hani-mandl/develop/hani-mandl.ino (rechte Maus > Ziel speichern unter).
Und wenn ein Wackelkontakt in der 220V Leitung des Netzteils ist, macht es auch Probleme 
.Das wars bei mir, jetzt läuft alles! Danke!!
1 Like
Hallo nochmal,
Ungeachtet der bei Kann ich auch das Heltec "WiFi Kit 32" in der neuen Version V3 verwenden? - #38 by Andreas geschriebenen Dinge, wollte ich nachfragen, ob Ihr den von Johannes Arndt bei fixed #32 crashing program when using rotary encoder by InstructionDecode · Pull Request #33 · ClemensGruber/hani-mandl · GitHub eingereichten Patch schon einmal ausprobiert habt?
Viele Grüße,
Andreas.
Ich weiß gerade das mapping der Espressif Versionen zu den ESP Arduino cores nicht, er nagelt im fix ja nur auf espressif32@^3.5.0 fest, wäre zu prüfen, ob es da den S3 schon gibt, ich denke nicht.