Diagnose-LED, gut für 'eine Stunde Suchen'

International Deutsch
1

Hi

Mit Eurer Hilfe bastel ich gerade an einem Sketch, Der mir 5 Schieber (Wasserhähne) ansteuern soll.
Gebraucht wird Das, hoffentlich bald, an meiner Heizung, um die Wärmequelle wechseln zu können (Thermische Solar/Ölbrenner bzw., welcher Pufferspeicher geladen/entladen werden soll).
Schieber-Prototyp:

Dort managed Das ein ATtiny45 mit zwei CNY70 und einem L298.

Das soll nun bald ein Sketch auf einem MEGA machen (da ich nur dort genügend Pins frei habe, brauche pro Schieber 2 Sensoren (Drehrichtung) und 2 Aktoren (Laufrichtung Motor)).
Der Versuchs-Arduino, Der mich gerade gelinkt hat ist zwar ein NANO, sollte aber Nichts zur Sache tun.

Statt der CNY70 benutze ich am Nano einen Dreh-Encoder, um die Drehrichtung zu Simulieren.

Ebenfalls ist eine LED nebst Vorwiderstand per Jumper-Wire dazu da, den 'Zustand' eines der Pins anzuzeigen - also, ob MOTOR-AUF z.B. gerade angesteuert wird.
Das klappt auch ganz gut (wen wundert's).
Nun hatte ich aber mit der Zählerei Probleme und steckte die LED an einen der Sensor-Pins, Diese zeigte mir auch durch fröhliches Blinken, daß vom Encoder genau Das kommt, was ich erwarte.
Da die LED überhaupt was anzeigt, bin ich auch am richtigen Pin - PullUP ist dort aktiviert.
Nur zählen wollte der Rechenknecht diese Impulse nicht :o

Lange Rede, fast kein Sinn:
Die LC-LED hat es geschafft, den Pegel an dem INPUT_PULLUP-Pin so weit runter zu ziehen, daß der Eingang laufend als LOW gemessen wurde, obwohl die LED mit fröhlich HIGH/LOW-Wechsel anzeigte.
Habe in der Stunde wohl auch einige Fehler aus dem Code entfernen können, aber hier dran suchte ich jetzt doch etwas länger.

Da ich diesen Fehler schon ein bisschen fies fand, nur wegen Euch es Dazu kommen konnte (der ganze Kram basiert auf der LED-Blink-Klasse) und ich Euch ein solches Missgeschick nicht wünsche, dieser Post.
Das Video zeigt außerdem, daß ich schon fast ein Jahr mit dieser 'Schieberart' um habe und meine Heizung immer noch strunz-dumm ist.

Vll. wird's dieses Jahr ja was - die Hoffnung stirb zuletzt.

MfG

PS: Das Pollen des Drehencoder und die Abarbeitung der erzeugten drei Schieber benötigt derzeit nur ~900ns (nur heartbeat-Anzeige, allerdings mit 9600baud).
Sobald Mehr ausgegeben wird, steigt die maximale Laufzeit aber auf 90ms - passiert aber erst, wenn x ms kein Sensor detektiert wird, die Grenzen angepasst werden, da davon ausgegangen wird, daß wir am mechanischen Ende angekommen sind..
Bei normalem Drehen konnte ich hier keinen Verzähler feststellen (Werte durch die Bank durch durch 4 teilbar, da 4 Flanken pro Raste).

Nebenbei:
Ich bin derzeit etwas unschlüssig, ob ich nicht diese Drehencoder (ALPS, genauen Typ müsste ich schauen) am Schieber verbauen soll - spricht da Was gegen?
CNY70 wären ebenfalls vorhanden und die Files für die Aufnahme bereits vorhanden, Strom spielt eine untergeordnette Rolle, mit 12V und A 'ohne Ende' komme ich in den Kellerraum.

2

postmaster-ino:
Nun hatte ich aber mit der Zählerei Probleme und steckte die LED an einen der Sensor-Pins, Diese zeigte mir auch durch fröhliches Blinken, daß vom Encoder genau Das kommt, was ich erwarte.
Da die LED überhaupt was anzeigt, bin ich auch am richtigen Pin - PullUP ist dort aktiviert.
Nur zählen wollte der Rechenknecht diese Impulse nicht :o

Lange Rede, fast kein Sinn:
Die LC-LED hat es geschafft, den Pegel an dem INPUT_PULLUP-Pin so weit runter zu ziehen, daß der Eingang laufend als LOW gemessen wurde, obwohl die LED mit fröhlich HIGH/LOW-Wechsel anzeigte.
Habe in der Stunde wohl auch einige Fehler aus dem Code entfernen können, aber hier dran suchte ich jetzt doch etwas länger.

Da ich diesen Fehler schon ein bisschen fies fand, nur wegen Euch es Dazu kommen konnte (der ganze Kram basiert auf der LED-Blink-Klasse) und ich Euch ein solches Missgeschick nicht wünsche, dieser Post.

Dazu solltest du den Schaltplan liefern, wie du die Led an den Sensor-Pin angeschlossen hast. Wie groß war der Vorwiderstand? Welche Farbe hat die Led?

Eine rote Led hat 1,6-2V Schwellspannung. Sie kann den Eingang auf 2V runterziehen, was reicht, den Eingang als dauerhaft Low zu erkennen. Damit das richtig läuft bräuchtest du einen kleineren externen Pull-Up-Widerstand und einen darauf abgestimmten Vorwiderstand der Led. Es könnte sogar sein, dass alles mit einer blauen/weißen Led funktioniert, da hier die Schwellspannung 3,2-3,6V ist.

3

Eingänge und Ausgänge sollte man nicht mischen. Was soll denn an diesen Eingang angeschlossen werden?

Eventuell kann man der LED einen Vorwiderstand spendieren, und einen kleineren Pullup dranhängen.

4

Hi

Die LED ist eine 3mm rote low current-LED von unbekannter Herkunft, aber schon länger in meinem Besitz und so wohl nicht direkt in China geordert, der Widerling hat gemessene 1782Ω.
Diese LED_mit_Vorwiderstand-Verbunde wurden als Anzeige-Einheit auf einem DIP-28-Sockel benutzt.

Das Argument mit der Fluß-Spannung der roten LED hat Was - kaum denkt man drüber nach, ist's auch schon logisch!

@DrDiettrich
Die Pins sind schon entweder-oder, also die Funktionalität ändert sich während des Programm nicht.
Nur hatte ich die LED zuerst zur Anzeige, ob einer der Motor-Ansteuer-Ausgänge HIGH schaltet - und dann, um zu gucken, ob vom Drehencoder auch was Sinnvolles kommt.
Hier hatte ich die Kombination Steckbrett und kurzbeiniger Drehencoder - etwas gerader eingesteckt und die Signale waren, laut LED, sauber.
Zuvor nicht, weil der Encoder schlecht stand, der Arduino konnte also gar nicht zählen, weil nur eine der Phasen ankam.
Und danach kam Die zwar bis zur LED, aber nicht bis zum Arduino :confused:

Schaltplan halte ich für etwas übertrieben, ist wirklich nur eine 3mm-LED mit einem Widerstand verheiratet :slight_smile:
... Pegel auf Fluß-Spannung, herrlich ... kam mir nicht in den Kopf - Danke dafür!

MfG

5

Wieso machst du das mit Drehencoder und nicht mit Endschaltern?
Willst du Zwischenstellungen haben?

6

Hi

Jupp. Ob ich Zwischenstellungen brauche - kA, aber genügend Weg muß der Motor eh zurück legen, da ich eine recht hohe Untersetzung brauche. Um auf die Endposition schließen zu können, zähle ich einfach mit. Zu Allererst gibt's eine Lernfahrt, wo der Schieber bis zum mechanischem Anschlag geöffnet/geschlossen wird (Abbruchbedingung: Timeout), dadurch kann ich die Schritte/Sensor-Impuls dazwischen ermitteln und im späteren Betrieb das 'auf Block fahren' vermeiden.
Endschalter wären aber auch schwieriger, da der gemeine Heizungsschieber Nichts hat, was von außen auf die Schieberstellung schließen lässt :wink:
Dafür aber den Vorteil, daß die Handräder nicht nach oben aus dem Schieber raus wandern beim Aufdrehen - Das roch geradezu nach einem Zahnrad-Getriebe.
Der Prototyp basiert auf zwei Reflex-Lichtschranken, Die im Gray-Code überfahren werden.
Beim Encoder habe ich irgendwie das Gefühl, daß ich mir einiges an Fitzeleien ersparen kann - die CNY70 haben nicht umsonst Ihren 'guten' Ruf :wink: - teilweise etwas zickig - dafür prellfrei, was in meinem Sketch aber keine Rolle spielt, da ich schnell genug pollen kann - dann wird halt intern +1 -1 +1 -1 +1 gerechnet - dem Arduino soll ja nicht langweilig werden.
Elektronisch hätte ich noch Touch-Sensoren - Die wären auch prellfrei, müsste ich wohl eine Mutter für in eines der Zahnräder einlassen - Ideen hätte ich dazu genug ...
Nachtrag 05.05.18
Die Touch-Sensoren habe ich getestet - unterm Strich aber hierfür unbrauchbar.
Diese scheinen den 'Schaltpunkt' während des Betrieb zu lernen - wenn der Sensor 'betätigt' abgestellt wird, ist Diese nach Spannungswiederkehr unbetätigt und braucht zwei/drei Flanken, bis Er wieder 'einrastet' - unbrauchbar, wenn ich diese Flanken mitzählen will.
Wenn die Sensoren aber unbetätigt zugeschaltet werden, klappt die erste Erfassung ohne Probleme.
eBay Touch-Sensoren, Alternativ: Suchwort TTP223 (erster eBay-Treffer)
--------

Außerdem sieht's bestimmt nett aus, wenn ich vorm Nachbarn damit angeben kann - mit der Handy-App rumgefuchtelt und der Rasenspringer bewässert auf Halb-Gas den Vorgarten ...
(... Das, wenn, eher über einen PHP-Skript ...)