Der AVR-/ARDUINO-Faden

[sysconsol]

Sehr selten, aber die Schleife kommt dann zum Erliegen. Vermutlich, weil ja die
Bedingung "geschaltetes Relais" nicht mehr kommt.

Provokant: Woher weiß der Controller denn, ob da ein Relais geschaltet wird?
Und: Soll das so sein? (frage ich zum zweiten Mal)

Ich habe den Eindruck, du kämpfst an mehreren Fronten.

Die erste Front ist die saubere Schaltung (Frelaufdioden, Stromaufnahme am Pin des µC,...).
Das kann man als letztes tun. Wenn die Steuerung sicher läuft.

Die zweite Front ist das Verstehen des Codes.
Jeder Befehl ist auf arduino.cc erklärt. Zumindest grob.
Es fehlt z.B. bei den Pins die Erklärung, wie sich digitalWrite() und pinMode() auf die Register auswirken.
Ein Grund, warum ich Arduino so mag - gerade wenn es um das Lernen und Verstehen geht

Die (vermutlich) dritte Front ist das generelle Verständnis für das, was der Code im µC selbst bewirkt.
Da kommt man hier mit Messen wohl am schnellsten zum Ziel. Die Arduino-Doku hilft da recht wenig

Ich schlage vor, zuerst mit dem Code und der Funktion des µC anzufangen.
Dann bemerkst du auch, dass es den µC von der Idee her hier nicht interessieren sollte, ob da ein Relais oder eine LED oder gar nichts am Pin hängt.
Praktisch ist da die Sache mit dem Pullup und die Frage, welches Register denn nun konkret abgefragt wird.

Was da im µC überhaupt passieren muss, wenn du am Port wackeln willst und einen Pullup-Widerstand schalten (oder auch nicht), sagt das Datenblatt des jeweiligen µC.
Hier das vom ATmega48A/PA/88A/PA/168A/PA/328/P. Die sind in den Grundfunktionen jedoch ähnlich.

Das Digital Pins Tutorial versucht auf das Verhalten der Pullup-Widerstände einzugehen.

Zusammen mit dem Kapitel 14.2.1 ff. des verlinkten Datenblattes kann man ein Verständnis dafür entwickeln, warum die Reihenfolge von pinMode() und digitalWrite() durchaus relevant ist.
Ausprobieren, messen und verstehen.
(Man könnte auch einen Port als Ausgang mit Pullup einlesen und entsprechend dem gelesene Wert auf einen anderen Port mit LED geben. Dann erfährt man, was der µC von innen am Port sieht.)


Ich deute lese nebebei heraus, dass du das im Informatikunterricht machst?
Eigentlich sollte eine Lehkraft die Herangehensweise an solche Probleme erklären ...
Ich hör ja schon auf!

[berlinerbaer]

Könnte auch sein, daß Du hier

Code: Alles auswählen

digitalWrite(RELAY1, !digitalRead(RELAY1));

timing-Probleme kriegst.

Mach doch erstmal digitalRead(RELAY1) in eine Variable, dann den seriellen output und dann das digitalWrite, notfalls nochmal mit 10 millis Wartezeit dazwischen.

Elegant ist das nicht und theoretisch müsste Dein kompakter Code funktionieren, aber so gehen wir Problemen sicher aus dem Weg...

@Anse:
Zumindest meine Relais-boards aus China haben Optokuppler, dahinter erst Transistoren und auch Freilaufdioden sowie die Möglichkeit, sie über einen Dupont-Stecker extern mit VCC zu versorgen.

[Cubicany]

Zumindest meine Relais-boards aus China haben Optokuppler, dahinter erst Transistoren und auch Freilaufdioden sowie die Möglichkeit, sie über einen Dupont-Stecker extern mit VCC zu versorgen.

So eins sollte das hier auch sein.

Ohne Last hat mein serieller Monitor übrigens schon die 500 Zyklen gezählt und es läuft noch.

Und kann es sein, dass nicht jedes Multimeter Wechselspannung Ampere messen kann?

Bei meinem ist nämlich dieser Strich mit der gepunkteten Linie neben dem Amperezeichen.

[sysconsol]

Und kann es sein, dass nicht jedes Multimeter Wechselspannung Ampere messen kann?

Das ist so.

Bei meinem ist nämlich dieser Strich mit der gepunkteten Linie neben dem Amperezeichen.

Eindeutig Gleichstrom.

Und nicht jedes Multimeter zeigt den RMS-Wert an.

[Cubicany]

Ok, ohne Last 1000 Schaltvogänge hat es bei mir noch nie gehalten.

Jetzt folgt der "Mit Last dran" Test.

Edit: Mit Last dran scheint es jetzt auch besser zu laufen.

Ich hole jetzt mal wieder die Taster ins Boot und teste weiter.

[Cubicany]

Jaaa, auch mit Tastern geht es!

Und dieses Blitzen der unbeteiligten Relais ist weg.

Warum auch immer, aber man dankt.

Dann kann ich mir dieses Programm mal als Musterbeispiel für Millis und die Relais ablegen.

[Anse]

Dann kann ich mir dieses Programm mal als Musterbeispiel für Millis und die Relais ablegen.

Für millis() nicht. Schon mal überlegt was passiert wenn der millis Zähler überläuft?
Das passiert zwar erst nach 50 Tagen aber es ist nicht schön programmiert.
Das wäre eigentlich ein Job für einen Timer.

[Cubicany]

Wie sähe denn ein Timer aus?

Delay ist es ja nicht.

[Anse]

Das geht aber jetzt sehr Hardwarenahe. Weiß nicht, ob da Arduino eine Funktion bietet.
Grundlegend ist so ein TImer ein Zähler in der Hardware, welcher synchron zum Prozessortakt hochgezählt wird. Wenn der Zähler am Ende angekommen ist, läuft er über auf 0 und erzeugt einen Interrupt. Das alles läuft von der CPU unabhängig. Sie kann also irgend was anderes machen in der Zeit.
Der Interrupt reißt sie aber jetzt aus ihrer Tätigkeit und leitet sie in ein Stück Code um, in dem z.B. deine Relais geschalten werden.
Das Stückchen Code wird immer exakt zur gleichen Zeit ausgeführt. Das ist das wichtige daran.
Um so einen Timer richtig ein zustellen gibt es sog. Setup Code. Da wird z.B. der Vorteiler für die Frequenz festgelegt oder bei welchem Wert der Timer überlaufen soll.
Das steht alles im Datenblatt Deines µC. Man muss sich aber mit den Hardware Registern auseinander setzten.

Mal etwas zum Lesen: https://www.robotshop.com/community/for ... upts/13072

[Cubicany]

Hab gerade gesehen, wenn mein "Timer" eh erst nach 55 Tagen "Voll" ist, habe ich da gar keinen Stress.

Konnte man den milis nicht sogar zurücksetzen, ohne den Arduino neu zu starten?

[IPv6]

Für millis() nicht. Schon mal überlegt was passiert wenn der millis Zähler überläuft?

Ja was passiert denn, wenn millis überläuft? Mir scheint, du hättest dir das noch nicht überlegt

Ein Beisiel, zur Übersichtlichkeit nur mit vorzeichenlosen 8 Bit (0-255 für die Einsteiger):
intervall = 10
previousMillis = 100
newMillis = 112

newMillis - previousMillis = 112 - 110 = 12
Überprüfung auf "> 10" wäre true. Somit ist das Intervall rum und das Relais (oder was auch immer) wird geschaltet.

Nun mit Überlauf:
intervall = 10
previousMillis = 249
newMillis = 4 (weil übergelaufen, hat also auf 260 gezählt)

newMillis - previousMillis = 4 - 249 = 11. Bei der Berechnung gibt es ja wieder einen Überlauf.
Überprüfung auf "> 10" wäre auch hier true. Somit ist auch hier wieder die entsprechend gewählte Zeit vergangen.

Das Ganze funktioniert also auch mit überlaufendem Zähler einwandfrei für die Ewigkeit.
Damit der Überlauf der eigenen Zählvariablen zum Überlauf von millis passt muss previousMillis vom gleichen Typ sein wie das, was millis() zurück gibt - also ein unsigned long. Sonst läuft unter Umständen die Variable von der Speicherung des letzten Zeitpunkts früher über und es passt nicht mehr zusammen.

[Cubicany]

Ach Mensch, ich flippe gleich aus!!

Jetzt hängt sich die Schleife ja schon wieder auf.
Und die Relais von den Tastern aktivieren sich jetzt auch wieder ohne zutun und frieren ein.

Ich habe wirklich keine Idee mehr, was ich jetzt noch versuchen soll.

Ich habe den durch euch verbesserten Code drin, ein Netzgerät mit genug Leistung und trotzdem setzt es wieder aus.

Kann es den sein, wenn die Signalleitungen neben den AC Leitungen im Kanal liegen, dass es dann zu Störsignalen kommt?

Das ist das einzige, was mir noch einfällt.

[Anse]

Mir scheint, du hättest dir das noch nicht überlegt

Stimmt, aber da ich bei so Sachen nie mit Überlauf programmiere hab ich es auch dabei belassen.
Aber halten wir fest.
Erstens ist ein Überlauf unwahrscheinlich weil Dauerlauf >50 Tage. Aber nicht unmöglich.
Zweitens, beim Überlauf ist mit keinen ernst zunehmenden Auswirkungen zu rechnen.

newMillis - previousMillis = 4 - 249 = 11. Bei der Berechnung gibt es ja wieder einen Überlauf.

Und was wenn mal <10 bei der Rechnung raus kommt wird eine Periode etwas länger.

[Cubicany]

Sieht jemand hier ein Problem?

Die dicke Leitung ist für die Taster.

Die dünnere ist für die Wechselspannung an die Motoren raus und die beiden braunen bringen AC rein.
die schwarzen sind für die 7,5V DC ans Arduino.

Das liegt halt alles gemeinsam in einem Kanal, wobei die AC Leitung ab der Verschraubung
abisoliert ist und somit der Schirm entfernt ist. Könnte das der Fehler sein?

[IPv6]

Stimmt, aber da ich bei so Sachen nie mit Überlauf programmiere hab ich es auch dabei belassen.

Hat das einen bestimmten Grund oder ist das nur Gewohnheit?
Ich bin kein Softwareentwickler und mache so Krams auch nur hobbymäßig, habe aber schon öfters mit Überläufen gearbeitet. Mir wäre kein Grund bekannt, wieso man das vermeiden sollte, spricht da irgendwas dagegen? Man muss es halt anständig dokumentieren damit man auch in zwei Jahren noch sofort weiß wie der Code funktionieren soll.

Erstens ist ein Überlauf unwahrscheinlich weil Dauerlauf >50 Tage.

Das würde ich so nicht sagen. Ich habe doch schon ein paar µC hier verteilt, die 24/7 irgendwelchen Aufgaben nachgehen. Da dauert es zwar immer bis die 50 Tage voll sind aber die wurden schon einige Male überschritten und werden es weiter tun. Da wäre es recht nervig wenn es da alle 7 Wochen zu Störungen kommen würde.

Und was wenn mal <10 bei der Rechnung raus kommt wird eine Periode etwas länger.

Das verstehe ich jetzt nicht so ganz. Dieses System ist ja von vornerein, egal ob mit oder ohne irgendwelchen Überläufen nicht dazu geeignet, exakt Zeiten einzuhalten. Der µC läuft halt so oft durch seine Schleife bis die vorgegebene Zeit mindestens erreicht ist. Wenn der Schleifendurchlauf halt aus irgendwelchen Gründen auch mal 10 ms dauern kann ist die die millis()-Methode auch maximal so genau.
Reicht aber für die allermeisten Anwendungen locker aus, meistens dauert ein Schleifendurchlauf ja weit unter 1 ms. Und ob das Relais nun nach 1000 ms oder 1010 ms schaltet...
Dafür kommt man ohne Timer und Interrupts aus und blockiert nicht mit einem delay() die Ausführung von weiterem Code.

@Cubicany:
Du hast da irgendeinen grundlegenden Fehler im Aufbau. Das hat alles mit den paar Zeilen Code sicher nichts zu tun. Entweder irgendwelche Störungen auf der Spannungsversorgungen oder andere Probleme mit Einsteuungen usw.
Um den Fehler einzugrenzen wirst du den Aufbau Stück für Stück aufbauen müssen und zwischendurch ausreichend testen. An irgendeinem Punkt wird es dann Fehler geben.
Dein Aufbau ist mir aber noch nicht ganz klar.
Hängen da recht lange, ungeschirmte Drähte direkt ohne weitere (Schutz)Beschaltung an Eingängen vom Arduino? Und liegen diese dann parallel zu stromführenden Leitungen? Falls ja klingt das durchaus problematisch.
Das so genau aus der Ferne zu analysieren ist aber sehr schwer bis unmöglich.

[Anse]

Hat das einen bestimmten Grund oder ist das nur Gewohnheit?

Es gibt Programmiersprachen und Prozessor-Architekturen, die einen Überlauf nicht so gutmütig handhaben wie der GCC auf dem AVR. C# wirst Du jetzt wahrscheinlich nie auf einem µC finden aber dort gibt es z.B. die OverflowException. Wenn die nicht gefangen wird, crasht die Anwendung. Generell ist ein ungeordneter Überlauf nie gut. Wenn man z.B. eine PID Regelschleife Programmiert, muss man sicherstellen, dass die Multiplikation von Fehler und Parameter nie größer wird als der Umfang der Stellgröße. Sonst kann es passieren, dass der Regler ab einer bestimmten Fehlergröße nichts mehr macht, weil der Output durch den Überlauf plötzlich kleiner wurde als zuvor.
Das ist aber ein Überlauf, der nicht wie in dem Zähler Beispiel funktioniert.
Anderseits habe ich schon mal mit gezielten Überlauf gearbeitet. Ich habe einen Array-Index von 0-3 gebraucht in einer Endlosschleife. Eine Möglichkeit wäre gewesen:

Code: Alles auswählen

int Array[4]={2,4,3,5};
uint8_t Index=0;
while(1)
{
  PORTB=Array[Index];
  Index++;
  if(Index==4) Index=0;
}

So hab ich es dann gelöst:

Code: Alles auswählen

int Array[4]={2,4,3,5};
uint8_t Index=0;
while(1)
{
  PORTB=Array[Index&0b11];
  Index++;
 
}

Ein If gespart dadurch dass ich mir nur die untersten 2 Bit des Indexes heraus picke. Das sollte man aber nur einsetzten, wenn man das Überlaufverhalten kennt.

[Cubicany]

Gefühlt bin ich gerade kurz vor "ich werf das Ding aus dem Fenster"
3 tage schon dran und es läuft überhaupt nicht richtig.

Jedenfalls sind die Leitungen eigentlich gar nicht so lang. 10 cm höchstens.

Was soll ich denn da statt der Flachbandkabel für Leitungen nehmen?

Für die Versorgung habe ich extra ein stabilisiertes Netzgerät genommen.
Also Spannung einbrechen kann ich mir fast nicht vorstellen.

Und die Leitung, wo die Drähte für die Motoren raus kommen, ist ja geschirmt.

Außerdem hat mein früheres Projekt doch auch funktioniert und ich habe seit dem nichts umgebaut.

Edit: Habe die "gefährlichen AC Stränge mal genommen und hoch gebogen, so das sie etwa 4 cm Luft zu
den Steuerleitungen haben und selbst das stört noch.

[Später Gast]

@Überlauf von millis(), kann man das irgendwie testen, ohne 55 Tage zu warten? kann ich millis() manuell hochsetzen, um den Überlauf zu provozieren?

Ich hab das bei meinem Lichtwecker auch im Einsatz und vergleiche das zwar mit ner unsigned long, hab aber bei Überläufen generell nen üblen Knoten im Hirn und wäre mir gerne sicher, dass der Wecker nicht nach 55 Tagen uptime plötzlich unerwartetes Verhalten an den Tag legt.

[IPv6]

@Später Gast
Durch tieferen Eingriff in die Arduinofunktionen geht das sicherlich irgendwie.
Zum testen könntest du einfach jedes "millis()" im Code durch "millis() + XXX" ersetzen, wobei XXX irgendein Wert nahe am Maximalwert einer unsigned long Variablen ist - in dem Fall 4,294,967,295. So könntest du die Zeit künstlich vordrehen.
Du könntest zum nachvollziehen auch eine Testfunktion basteln, die mit einer uint8_t arbeitet statt mit unsigned long, dann gehts nur bis 255.
Was deinen Lichtwecker angeht wirst du aber einfach überhaupt gar nichts merken.
Vielleicht hilft es gegen den Knoten im Hirn den Bereich einer Variablen als Uhr zu betrachten. Da gibt es auch ständig den Überlauf von 12 auf 1 und niemand stört sich daran. Würde die Zeit rückwärts laufen käme nach der 1 eben wieder die 12. Nicht anders ist es bei einer vorzeichenlosen Variablen.

@Anse:
Klingt einleuchtend. Meine Überläufe waren auch solche Geschichten, Werte per Display und Drehencoder zwischen 0 und 255 einstellbar (Farbwahl für ein RGB LED-Band), da war das mit einer uint8 unkompliziert zu lösen statt den Wert von Hand rückzusetzen.
Bei stumpf hochzählenden Variablen (per Drehencoder, als Zähler, millis()...) würde ich das Überlaufverhalten mal als berechenbar einschätzen. Ist ja bequem wenn man mit der millis() Funktion einfach zeitgesteuerte Sachen machen kann, die auch länger als 50 Tage laufen ohne weiteren Code zu benötigen.

Man muss eben nur aufpassen, dass man bei "(neueZeit - alteZeit) >= intervall" bleibt, mit "neueZeit >= (alteZeit + intervall)" funktioniert es nicht.

Gefühlt bin ich gerade kurz vor "ich werf das Ding aus dem Fenster"
3 tage schon dran und es läuft überhaupt nicht richtig.

Mach doch, ist dein Projekt, aus den Fenster geworfen könnte es immerhin noch als moderne Kunst durchgehen
Wegen der Leitungslänge habe ich nur wegen den Tastern gefragt, das scheinen mir etwas mehr als 10 cm zu sein.
Fürs Verständnis würde es denke ich helfen, wenn du mal eine Skizze mit allen beteiligten Komponenten machst wo auch die Leitungen und ihre Längen ersichtlich sind. Und ein paar mehr Bilder vom Aufbau.
Anhand der hier eingestellten Informationen ist es mir jedefalls nicht möglich, einen Fehler zu finden. Ich kann dir nur sagen, dass das Verhalten definitiv nicht normal ist und da irgendwo ein größeres Problem vergraben ist, vermutlich im Hardwareaufbau.

Für heute wird es wohl das beste sein, die Finger davon zu lassen. Da kommt nur noch mehr Ärger bei raus. Lieber eine Nacht drüber schlafen und ausgeruht nochmal drangehen.

[Cubicany]

Ist wohl auch besser.

Was ich aber abschließend eingrenzen kann ist, wenn ich die ganzen AC Leitungen aus dem
Deckel kommen lasse und zwar so von oben, dass die auf ihrem Weg an nichts
anderem vorbei kommt, läuft es ohne Ausfall. Nur der serielle Monitor bleibt stehen.

Ich befürchte daher, dass das Schalten der Wechselspannung Fehler einbringt.

[Anse]

Schon mal alles Serial Prints raus aus dem Programm?

[Cubicany]

Heißt das, ich soll den Monitor da komplett raus nehmen, damit der nicht mehr ausgibt?

Meinst du, dadurch das der Monitor stoppt, könnte es hängen bleiben?

Kenne mich da nicht so aus, deshalb die Frage.

Ich lege das jetzt erst mal alles lose ausgebaut auf den Tisch und versuche mal, wie
es sich verhält.

[Raja_Kentut]

Ach Mensch, ich flippe gleich aus!!

Jetzt hängt sich die Schleife ja schon wieder auf.
Und die Relais von den Tastern aktivieren sich jetzt auch wieder ohne zutun und frieren ein.

Ich habe wirklich keine Idee mehr, was ich jetzt noch versuchen soll.

Ich habe den durch euch verbesserten Code drin, ein Netzgerät mit genug Leistung und trotzdem setzt es wieder aus.

Kann es den sein, wenn die Signalleitungen neben den AC Leitungen im Kanal liegen, dass es dann zu Störsignalen kommt?

Das ist das einzige, was mir noch einfällt.

wie hast Du die Taster angeschlossen ? Einfach Vcc -> Taster (Schließer) -> Portpin ?
In dem Fall löte mal einen 10k "Pulldown" vom Portpin an GND

Guckst du hier : https://www.fingers-welt.de/phpBB/viewt ... 14&t=15537

[Sir_Death]

Üblicherweise macht man das bei Micorcontroller so, dass Masse=aktiver Schalter gilt. Dann können Einstreuungen den nicht auslösen.
Dazu gibt es dann bei der Eingangsdefinition bei Arduino

Code: Alles auswählen

pinMode(ZylAus_I, INPUT_PULLUP);

Damit zieht er sich selbst den Eingangspin auf 1 wenn nichts passiert und Störungen bringen den selten (bis nie) auf 0.
Taster schließt dann gegen Masse.

[Später Gast]

@Später Gast
Durch tieferen Eingriff in die Arduinofunktionen geht das sicherlich irgendwie.
Zum testen könntest du einfach jedes "millis()" im Code durch "millis() + XXX" ersetzen, wobei XXX irgendein Wert nahe am Maximalwert einer unsigned long Variablen ist - in dem Fall 4,294,967,295. So könntest du die Zeit künstlich vordrehen.
Du könntest zum nachvollziehen auch eine Testfunktion basteln, die mit einer uint8_t arbeitet statt mit unsigned long, dann gehts nur bis 255.
Was deinen Lichtwecker angeht wirst du aber einfach überhaupt gar nichts merken.
Vielleicht hilft es gegen den Knoten im Hirn den Bereich einer Variablen als Uhr zu betrachten. Da gibt es auch ständig den Überlauf von 12 auf 1 und niemand stört sich daran. Würde die Zeit rückwärts laufen käme nach der 1 eben wieder die 12. Nicht anders ist es bei einer vorzeichenlosen Variablen.

Danke, den Test ### draufaddieren werd ich mal ausprobieren. Uint8_t is ja synonym mit byte, da musste ich schon feststellen, dass byte unsigned ist und nach 255 überläuft und nie <0 wird. Das ist aber für die Funktionen, die da laufen zu klein um da sinnvoll was zu testen, die Intervalle sind im Bereich von 10-40 Minuten.
Warum sagst du, dass ich nichts merken werde, hast du den Code schon so genau angeschaut und weißt es halt? Ich verwende da millis() mit ner Timervariablen, um den Alarmablauf zu steuern, wenn da was schiefgeht, wird u.U. der laute Teil der Weckroutine nicht gestartet, oder der Sonnenaufgang wird von ner plötzlichen Mondfinsternis überschattet.
Die Finsternis dauert wenns blöd läuft halt 55 Tage
Wer so lange verschläft braucht keinen Wecker mehr.

Der Hirnknoten entsteht nicht beim Überlauf selbst, sondern beim Workaround mit Addition/Substraktion und dem Vergleich. Von hinten durch die Brust ins Auge oder so.

[Anse]

Heißt das, ich soll den Monitor da komplett raus nehmen, damit der nicht mehr ausgibt?

Ja, auch wenn das eher eine Verzweiflungstat ist. Könnte ja sein, dass sich der Prozessor irgend wo in den Send Funktionen verläuft. Hatte ich aber noch nie. Es hielt aber, den Code so weit zu vereinfachen, wie nur möglich.

Aber beachte erst mal das was über Portpins und Pullups gesagt wurde. Ich gehe sogar noch weiter. Eine Leitung direkt an den Eingangspin sollte die Platine nicht mal verlassen. z.B. Entkoppeln mit Optokoppler wäre da eine Option. Durch die Tasten sollte ja auch für eine zuverlässige Funktion etwas mehr Strom fließen.

[berlinerbaer]

Außerdem hat mein früheres Projekt doch auch funktioniert und ich habe seit dem nichts umgebaut.

Das ist eine wichtige Anmerkung.

Überleg' mal ganz genau, was sich seit dem früheren Projekt geändert hat bzw. was am neuen anders ist.

Spiel den alten Code nochmal ein und schau, ob es dann immer noch geht.

Wenn Du ein Oszilloskop hast, solltest Du recht schnell sehen können, wo was schief geht.

Weil es hier wahrscheinlich um sehr niederfrequente Probleme geht, würde auch ein super-billig-Teil wie das hier

https://de.aliexpress.com/item/33021093041.html

tun oder noch besser, Dir veraalt jemand ein altes analoges Schätzchen....

[Cubicany]

Üblicherweise macht man das bei Micorcontroller so, dass Masse=aktiver Schalter gilt. Dann können Einstreuungen den nicht auslösen.
Dazu gibt es dann bei der Eingangsdefinition bei Arduino

Code: Alles auswählen

pinMode(ZylAus_I, INPUT_PULLUP);

Damit zieht er sich selbst den Eingangspin auf 1 wenn nichts passiert und Störungen bringen den selten (bis nie) auf 0.
Taster schließt dann gegen Masse.

Ähm, guter Einwand.

Ich weiß gerade selber nicht genau, ob die jetzt Pull up oder down sind.

Ich habe die taster so angeschlossen, dass eine Leitung auf mehrere parallele Widerstände geht, dann HINTER den Widerständen
jeweils sowohl der Abgriff als auch der Taster. und vom Taster nochmal eine Leitung raus geführt.

Wie jetzt "gepullt" wird, kann man doch einfach über die Polung bestimmen oder nicht?

[Sven]

Ich habe die taster so angeschlossen, dass eine Leitung auf mehrere parallele Widerstände geht, dann HINTER den Widerständen
jeweils sowohl der Abgriff als auch der Taster. und vom Taster nochmal eine Leitung raus geführt.

Mach mal einen Schaltplan. Dann versteht man das auch, was du da zusammengebaut hast.

[Cubicany]

Ich mal das mit den Tastern mal auf:

Nicht schön aber selten.

Etwa so.

[Sven]

Wenn du oben VCC anschließt und unten Masse, dann hast du Pullups. Die ziehen den Pin nach oben, also auf positive Potential gegenüber Masse.
Bei umgekehrter Polung (Oben Masse, unten VCC) Pulldowns. Die ziehen dann den Pin gegen Masse, also quasi "runter".

Ich arbeite meistens mit Pullup Widerständen. Schalter oder Taster ziehen dann den Pin gegen Masse.

Schau dir mal auf dem Oszilloskop an, was an den jeweiligen Eingangspins vom Arduino passiert

[Cubicany]

Schau dir mal auf dem Oszilloskop an, was an den jeweiligen Eingangspins vom Arduino passiert

Hach ja, da müsste ich mir ja wirklich mal eins zulegen.

Nur mit dem Multi ist man ja recht schnell an der Grenze des Machbaren.

Sind denn Pull Ups oder Downs weniger störanfällig?

[Cubicany]

Aber das erklärt trotzdem noch nicht, warum die Schleife hängen bleibt.

Denn auch, wenn die AC Leitungen an keiner Steuerleitung des Arduino vorbei kommen, hängt sich das auf.

[Raja_Kentut]

damit 100% sichergestellt ist, das das Programm läuft, lade mal dieses Programm :
Ich habe in jeder Zeile einen Kommentarwas sie genau tut.
Es läuft, hab ich gerade auf nem Leonardo am laufen.

Code: Alles auswählen

//*************** HW Pinbelegung Arduino ***************************
//Pin10 - Ausgang schalter Relais

//  ************* Variablen ******************************

  int Relay1 = 10; // Pin 10 soll Relay1 heissen

//  ************* Setup ******************************
void setup() 
{
  Serial.begin (9600);  // UART Kommunikation initialisieren und auf 9600 Baud
  
// ************* Pinzuweisungen I/O *****************
  pinMode(Relay1, OUTPUT);  // Der Pin 10 der jetzt Relay1 heisst soll ein Ausgang sein
  digitalWrite(Relay1,LOW);  //Bei Programmstart soll das Relais definiert ausgeschaltet sein 
}

// Programmfunktion : Alle 10 sekunden soll das Relais abwechselnd ein / aus geschaltet werden (8s hochlauf, 2s warten)
void loop()                     // Alles was zwischen den geschweiften Klammern steht wird ewig ausgeführt
{
 Serial.println("Relais EIN"); // Meldung an Serial-Monitor ausgeben
 digitalWrite(Relay1, HIGH);   // Relais wird eingeschaltet
 delay (10000);                // 10 sekunden warten
 Serial.println("Relais AUS"); // Meldung an Serial-Monitor ausgeben
 digitalWrite(Relay1,LOW);     // Realis wird ausgeschaltet
 delay (10000);                // 10 sekunden warten
}

[Cubicany]

Dann habe ich ja wieder delays drin.

Ich habe ja noch eine Funktion mit Tastern, die parallel funktionieren soll.

Ich ziehe das trotzdem mal drauf.

Ach so, hast du denn auch eine Wechselstrom Last dran?

[Raja_Kentut]

den millis() bauen wir ein wenns so funzt...
Wg. Analogosziveraalung : Ich hätte eins gegen Aal abzugeben...

[Cubicany]

Hah!

Und er kickt den seriellen Monitor wieder raus!

in der einen Zeile hat er noch Rel geschrieben und dann nichts mehr.

[Raja_Kentut]

dann liegts an der Verbindung UNO - PC.
Hast Du evtl. einen Leonardo ? Dann entfällt der manchmal unzuverlässige Teil Seriell - USB Wandlung
Probier mal mit noch kleinerer Baudrate, ist das Kabel ok ?

[Cubicany]

Ich habe nur den einen Controller.

Kabel könnte ich mal tauschen, aber das dürfte doch der Schleife egal sein, oder?

Die Rate kann ich mal runter setzen.

[Sven]

Hört das Relais dann auch auf zu schalten, wenn dir die serielle wegbricht oder tuts weiterhin?
Deine Relaiskarte hat doch Status LEDs für jedes Relais. Blinkt die weiterhin im Takt oder hörst du das Relais schalten?

Was passiert, wenn du keinen seriellen Monitor offen hast?

[Cubicany]

Das Relais tickt fröhlich weiter vor sich hin.

Und wie gesagt, OHNE Last dran läuft das bis in alle Ewigkeiten, aber wenn
ich den mit Last starte, bleibt das irgendwann hängen.

Dabei sind das doch eigentlich zwei getrennte Kreise.

[Anse]

Ich mal das mit den Tastern mal auf:

Taster.JPG

Nicht schön aber selten.

Etwa so.

Welchen Wert haben die Widerstände?
Was auch helfen kann, ist einen 100 nF Kerko zwischen Pin und Versorgung "gegenüber" vom Widerstand.

[Cubicany]

Ich mal das mit den Tastern mal auf:

Taster.JPG
Nicht schön aber selten.

Etwa so.

Welchen Wert haben die Widerstände?
Was auch helfen kann, ist einen 100 nF Kerko zwischen Pin und Versorgung "gegenüber" vom Widerstand.

Die Taster sind mir gerade so egal, ich will, dass die Schleife endlich mit Last am Laufen bleibt.

[Raja_Kentut]

Tickt es auch mit diesem Programm, ohne Seriell Monitor und Last dran weiter ?

[Cubicany]

Ich habe erst mal ein anderes USB kabel geholt und den Uno jetzt an der "kurzen" Leine hängen.
Außerdem die Rate auf 4800 runter gesetzt.

Ohne Last scheint es auf jeden Fall zu laufen.

Ich hänge die AC gleich mal dran und schaue, ob der Monitor wieder ausfällt.

[Cubicany]

Ich habe jetzt erst mal nur den AC Teil dran, aber ohne Motor angeschlossen, nur zum schauen, ob ihn das auch stört.

Als nächstes kommt der Motor wieder dran.

[IPv6]

Warum sagst du, dass ich nichts merken werde, hast du den Code schon so genau angeschaut und weißt es halt? Ich verwende da millis() mit ner Timervariablen, um den Alarmablauf zu steuern, wenn da was schiefgeht, wird u.U. der laute Teil der Weckroutine nicht gestartet, oder der Sonnenaufgang wird von ner plötzlichen Mondfinsternis überschattet.

Ich meinte damit nur, dass der Überlauf problemlos funktioniert wenn er so wie weiter oben beschrieben umgesetzt wurde.
In fast jedem Projekt hats bei mir irgendwas zeitgesteuertes mit millis() drin und da bekommt man von den Überläufen einfach nichts mit.
Weiter oben habe ich ja mit einem Beispiel erklärt wieso der Überlauf problemlos ist wenn man die richtigen Datentypen und die richtige Abfrage verwendet.

[Cubicany]

Und mit Last kickt er den Monitor schon wieder:

[Sven]

Na das sieht doch nach einem anständigen EMV Problem aus!

Lass das Relais doch mal eine anständige Ohmsche Last schalten, ne Glühbirne z.B.


PS: Die millis() Geschichte ist völlig unkritisch. Derartige Konstrukte laufen hier seit Jahren völlig Problemlos. Wenn man wie gesagt auf die richtigen Datentypen achtet und auf die richtige Reihenfolge der Operanden erhält man exakt das gewünschte Ergebnis.
Das nutze ich hier für alle "unkritischen" Timing Aufgaben, bei denen es nicht auf ein paar Zehn Taktzyklen mehr oder weniger ankommt.

Code: Alles auswählen

unsigned long tStart;
const unsigned long tIntervalMs = 10000;  // oder was auch immer als Intervall in Millisekunden gewünscht ist
/*setup code here...
tStart = 0; // oder millis() oder was auch immer als Startwert gewünscht ist
*/

if (millis() - tStart >= tIntervalMs)
	{
		/* do stuff here*/
		tStart = millis();
	}

[Cubicany]

Gute Idee, ich habe doch noch die Leuchtmelder hier.

Sind 24V, 80 mA Birnchen.

Wenn es EMV ist, was wäre bei den Birnchen zu erwarten?