Wenn der Drehenocder an die interruptfähigen IO-Pins 2 und 3 angeschlossen wird und die library NewEncoder verwendet wird dann wird der Drehencoder sehr zuverlässig ausgewertet
weil diese Sorte Encoderauswertung absolut unabhängig vom sonstigen code arbeitet.
Die andere library arbeitet mit einem festen Zeittakt und ich habe mir nicht das innere der library angeschaut wie gut die Timer_ISR_Encoder.h lib prellende Schalter abfängt.
Wenn man den Fingerprintsensor auf eine niedrigere Baudrate einstellt dann hat man weniger Zeitprobleme. Langsamere Baudrate heißt alle Impulse werden länger. Damit werden auch die Zeiträume länger die man zum Detektieren der Logig-Pegel hat. => zuverlässigere Erkennung.
Ob es jetzt am Fingerprintsensor selbst liegt kannst du dadurch herausfinden, dass du den Fingerprintsensor mal direkt mit dem PC verbindest und dann ausgiebig Fingerprints lesen lässt.
Bei deinem PC kann man davon ausgehen das das Einlesen der seriellen Daten wirklich sehr zuverlässig funktioniert. (Es sei denn deine Prozessorauslastung hängt ständig bei 95-100%)
Und dir dann jeden einzelnen Lesevorgang anschaust.
Hast du einen einzelnen USB-COM-Port-Adapter?
Wenn du jetzt am überlegen bist einen anderen Microcontroller zu nehmen dann würde ich einen ESP32-nodeMCU nehmen.
viel mehr Flash, viel mehr RAM, WLAN / Bluetooth onboard, höhere Taktfrequenz
zweiter hardware-UART, Programm Over the Air flashbar
Wie funktioniert dort denn hier die Bluetooth und Wlan Anbindung? Sicherlich mit eigener Lib? Kann ich dich vielleicht außerhalb dieses Threads bezüglich der ein oder anderen Frage kontaktieren? Vielleicht per PM?
Danke.
Zum Konverter... Nein ich habe keinen USB-COM-Port-Adapter. Über den Uno wird der Pin 0 und 1 ja zum PC durchgeschliffen. Dadurch kann ich den Fingerprintsensor mit entsprechender Software mit Fingerprints versorgen. Wobei ich dazu sagen muss, dass die im preview alle nicht so 100%ig aussehen.
Oft reagiert einfach der Sensor nicht, wenn der Finger auf dem Sensor gelegt wird. Jetzt ist es die Frage. Woran liegts?
Den USB-COM-Portadapter kannste die einfach zum Nikolaus schenken/schenken lassen.
Wie schon beschrieben. Den Fingertzipsensor an einem Empfänger testen von dem man weiß dass er sehr zuverlässig funktioniert.
Bis du einen Comport-Adapter und einen Logic-Analyser hast
Mit dem Logicanalyser kannste für scvhlappe 10 Euro zusammen mit der freeware sigrok PulseView das Bitbanging von jeder Schnittstelle aufzeichnen und dann auch noch dekodieren lassen.
zum testen des Fingerprintsensors kannst du auch für den Arduino ein Programm schreiben bei dem du zum Senden/Empfangen die IO-pins 0 und 1 nimmst.
Und dann einfach LEDs für "habe (irgendwelche) Daten empfangen
Fingerabdruck erkannt
Fingerabdruck nicht erkannt ein/ausschaltest
plus einen Taster der in den Modus
bin bereit zum neu empfangen versetzt.
Entweder man gibt viel Zeit "aus" zum Testen oder man gibt Geld aus und dann anschliessend weniger Zeit zum testen. Ganz was dir lieber ist.
Fragen zum ESP32 einfach hier im Forum posten dann haben alle was davon und du kannst auf einen viel größeren Wissens- und Ideenpool zugreifen.
Also wenn es sowas wie eine elektrische Kupplung ähnlich wie bei Klimakompressoren im Auto auch in kleinem Maßstab gäbe, (keine Ahnung ob es sowas z.B. im Modellbau gibt) dann bräuchte man keine Position zu wissen und oder sich auf einen speziellen Antrieb festzulegen.
Im Normalfall wäre die Kupplung offen und es kann von außen mit dem Schlüssel gedreht werden. Soll elektrisch verfahren werden schließt die Kupplung und der Motor dreht das Schloss entweder auf und zu. Beim Endanschlag geht der Motorstrom hoch und so weiß man dass das Ziel erreicht ist.
Ich weiß nur nicht wie schon gesagt ob es solche einfachen Kupplungen auch im Kleinen gibt oder man sie z.B. aus einem Servo der zwei Zahnkränze zusammenschiebt selber bauen kann.
Kupplung brint mich auf eine Idee:
Nur so weil mir die Phantasie gerade davongallopiert.
Passend eingestellte "Rutschkupplung" eines Akkuschraubers.
Oder eine Torsionsfeder die sich am Anschlag verdreht und ein Mikroschalter wird betätigt.
Zwei Zahnrädchen mit einer Untersetzung so das das untersetzte Zahnrad weniger als 1 Umdrehung macht => Zwei Markierungspunkte für "ganz auf" "ganz zu"
Der Rotary hat mit der angepassten Lib von dir nach aktuellen Versuchen soweit ganz gut funktioniert.
Allerdings funktioniert die Timer_ISR_Encoder.h und Timer_ISR_Encoder.cpp nicht mehr mit dem neuen ESP32... Aber nicht nur das. Die normale Servo lib funktioniert mit dem auch nicht mehr.
Ich habe mir jetzt mal <ESP32_Servo.h> besorgt... Mal sehen, ob das klappt. für den Encoder hab ich noch keine Lösung.
Für die geschlossene Tür habe ich einen HallEndstop Magnetsensor. Der erkennt ob die Tür geöffnet oder geschlossen ist.
Ich habe auch noch einen 5V Schrittmotor. Damit könnte das auch funktionieren. Lässt sich aber per Hand relativ schlecht drehen wegen der Übersetzung.
Der innere Aufbau des Prozessor des ESP32 (xTensa LX6) unterscheidet sich grundlegend von einem Atmel328. Deswegen funktioniert die Timer_ISR_Encoder.h auf dem ESP32 nicht.
Beim ESP32 ist aber fast jeder IO-pin interruptfähig. Beim Uno gibt es nur zwei interruptfähige IO-Pins. Beim ESP32 ist alles viel flexibler deswegen finde ich ja auch dass der ESP32 der bessere Ardino-"Uno" ist.
Auf dem ESP32 kannst einfach die NewEncoder-lib nehmen so lange du nicht den zweiten Kern oder auf FreeRTOS-Ebene mehrere Tasks startest.
Das heisst so lange du "klassisches C++" mit Arduino-IDE ohne Multicore spezial-libraries programmierst funktioniert das mit NewEncoder.h
Ja und auch Servos werden da anders angsteuert aber mit einer servo-library die für ESP32 programmiert wurde müsste das problemlos gehen servos anzusteuern.
Ich benötige nochmal bezüglich des Rotarys etwas Unterstützung.
Funktionieren tut er soweit wirklich gut. Das einzige was ich nicht hinbekomme ist die Variable des aktuellen Wertes auf einen anderen Wert zu setzen, sodass er von dort aus weiter zählt.
Beispiel:
Für meine Türöffnung habe ich eine Kalibrierung programmiert. Sprich sobald das Programm neugestartet wird, weil der Strom weg war, erhält er Open, Close und Direction Variablen aus dem Flash zurück. Das einzige was dann fehlt ist die Variable der aktuellen Stellung.
Problem: Beim Neustart wird natürlich auch der Rotary zurückgesetzt. Um den neuen Nullpunkt zu bestimmen, lasse ich den Servo einmal kurz nach links seine Startposition 250 verlassen und Fahre den Motor dann komplett in die Close Stellung. Nach 5 Sekunden Rotary-Stillstand stoppt der Motor und soll den current Wert mit dem Close Wert überschreiben.
Das Codefragment zeigt nicht mal den Einsprunkpunkt.
Wenn Du willst, das nach einem Neustart irgendwas ausgelöst/erkannt wird, muss das schon alles dazu enthalten...
Eine verbale Beschreibung der Funktionalität erleichtert das Verständnis was der Code macht.
Aber nur dann wenn man den kompletten Sketch lesen kann. Von der allerersten ersten bis Codezeile bis zur allerletzten codezeile.
irgendwie muss man das allen Newbees mindestens 10 mal sagen bis es auch wirklich gemacht wird.
Und was das Verständnis auch wesentlich erhöht sind selbsterklärende Funktionsnamen
"clf4" erklärt nichts! macht das 4mal serial.println()???
Wozu machst du nointerrupts() / interrupts()??
Die library NewEncoder macht das alleine. Wenn du da reinpfuschst kann es höchstens schlechter werden.
Ich helfe erst wieder wenn zwei Bedingungen erfüllt sind:
alle functions haben einen selbsterklärenden Namen
der gaaanzaktuelle sketch ist komplett als code-section gepostet