Guten Abend, mein Name ist Marco Gebhardt und ich bin neu hier im Forum. Ich hoffe mit der Frage bin ich in der richtigen Abteilung. Mit dem ganzen Mikrocontrollerthema würde ich mich als Neulich bezeichnen. Ich habe für unser Terrarium (welches konstant 28° benötigt) einen Dimmer gebaut, zuerst nur aus einem ESP8266 später aus dem ESP und einem Arduino Uno. Anfänglich: Der ESP8266 (NodeMCU) erhällt alle 5 min Sensorwerte von einem DHT22 Temperatursensorwerte, auf ihm läuft ein Webserver sodass ich von unterwegs die Werte abrufen kann und er steuert den Dimmer. Der Dimmer ist Mittels Phasenanschnittssteuerung realisiert (Triac + 2 Optokoppler). Der Controller erhällt also bei Nullphasendurchgang ein Interrupt und schickt dann mit einer eingestellten Zeitverzögerung das Signal zum Durchschalten des Triacs. Nun war es aber so dass alle paar Sekunden wenn der ESP andere Aufgaben wie z.B. das bearbeiten des Webservers, Temperatur oder WIFI bearbeitet hat, die Lampe flackerte. Also habe ich: jetzt auf einem Arduino Uno nur die Interrupts (Nullphasendurchgang) sowie das Schalten des Triacs laufen. Über I2C erhällt er alle 5 Minuten entweder den Befehl das Dimm-delay zu erhöhen oder zu verringern (je nach Temperatur). Der Loop()-Teil vom Arduino ist leer, bzw. stand da nur ein delay(100) drinnen die ganze Zeit. Nun das Problem: Jeden Tag zwischen 12 und 14 Uhr flackert irgendwann das Licht oder geht ganz aus für 10-20 Minuten, den Rest vom Tag macht alles genau was es soll. An was könnte das liegen? im Loop Teil ist ja nur ein Delay(100)... gibt es Probleme wenn der eingebaute Timer einen gewissen Wert erreicht? (Arduino startet jeden Morgen neu, Nachts ist er vom Netz genommen) Und die zweite Frage: Wenn ich beim Arduino den Loop() Teil ganz weglasse oder leer lasse, wird der Prozessor dann so stark beansprucht wie wenn er permanent rechnen würde? Da ja kein Delay mit dabei ist was ihn bremst? Ich weiß, blöde Formulierung aber ich weiß nicht wie ich es gerade besser beschreiben kann. Liebe Grüße Marco
Der UNO läuft immer auf Vollgas. Auch im Delay. In den Sleep könntest du ihn zwingen. Bringt aber nicht viel, wg. dem restlichen Gedöns auf dem Board. Marco G. schrieb: > Nun das Problem: Jeden Tag zwischen 12 und 14 Uhr flackert irgendwann > das Licht oder geht ganz aus für 10-20 Minuten, den Rest vom Tag macht > alles genau was es soll. An was könnte das liegen? Wie soll man das beurteilen? Schaltung geheim Code geheim Am UNO selber liegts eher nicht. Weder das Board, noch das Framework hat solche Probleme. Es liegt meist an dem, was ausblendet wird. Hier: Code oder Schaltung
Hallo und danke für die Antwort, dann schicke ich mal meinen Code
hinterher. Vielleicht fällt ja einem was auf:
#include "Wire.h"
int Triac = 5;
int ZC = 3;
int dimming = 4; // Dimming level (0-128) 0 = ON, 128 = OFF
int c;
void setup()
{
pinMode(Triac, OUTPUT);
pinMode(ZC, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(ZC) , zero_crosss_int, RISING);
Wire.begin(8);
Wire.onReceive(receiveEvent);
}
void loop()
{
}
void receiveEvent() //Befehle vom ESP kommend um
{ //Dimmer anzupassen
while(0<Wire.available())
{
c = Wire.read();
}
if(c == 1 && dimming <= 115.2)
{
dimming = dimming + 6.4;
}
if( c== 0 && dimming >= 10.4)
{
dimming = dimming - 6.4;
}
}
void zero_crosss_int()
{
// 50Hz-> 10ms (1/2 Cycle) -> maximale Zeit damit Lampe komplett aus
bl.
// (10000us - 10us) / 128 = 78
int dimtime = (78*dimming);
delayMicroseconds(dimtime);
digitalWrite(Triac, HIGH); // triac ein
delayMicroseconds(10);
digitalWrite(Triac, LOW); // triac aus
}
:
Bearbeitet durch User
'dimming' ist Integer aber du vergleicht und rechnest mit float-Konstanten. 'dimming' wird in zwei Interrupt Routinen verwendet => mach es zu volatile. Innerhalb einer ISR machst du ein delay => Niemals in einer ISR warten, setze Flags und behandelt es in der Main über ein Zustandsautomat. Soll dein while in der receiveEvent() nur über Wire.read() gehen?
:
Bearbeitet durch User
Angehängte Dateien:
-
asdasdadasd.JPG
73 KB
Danke für die Antwort, wie gesagt bin Neuling und für jeden Tipp dankbar. Die ersten beiden Fehler habe ich beseitigt. Delays in Interrupts sollte man vermeiden weil der restliche Programmfluss aufgehalten wird. In meinem Fall gibt es außer der Dimmer Steuerung aber sonst nichts außer den Erhalt von Daten vom ESP was nur alle 10 min einmal passiert. Ist es dann trotzdem noch wichtig? Ja das while bezieht sich nur auf das wire.read(), ich glaube ich hatte anfänglich noch etwas anderes drinnen deswegen eine while Schleife, könnte ich dann auch rausnehmen. Aber anhand des Codes gibt es keine Anzeichen warum er den ganzen Tag perfekt arbeitet außer Mittags, meistens um die selbe Zeit erst flackert und dann für ca. eine halbe Stunde ausfällt? Wenn das passiert ist es unabhängig ob bereits gedimmt ist oder die Lampe noch auf 100% gefahren ist. Verwende das Modul im Anhang (BTA-16 Triac mit 2 Optokopplern)
:
Bearbeitet durch User
Marco G. schrieb: > Aber anhand des Codes gibt es keine Anzeichen warum er den ganzen Tag > perfekt arbeitet außer Mittags, meistens um die selbe Zeit erst flackert > und dann für ca. eine halbe Stunde ausfällt? Macht vielleicht der ESP zu der Zeit faxen?
Marco G. schrieb: > Der Controller erhällt also bei Nullphasendurchgang ein > Interrupt Das kann im Fehlerfall einen Interrupt neu auslösen, während in demMoment der aktuelle Interrupt noch nicht fertig bearbeitet ist. möglicher Auslöser: https://de.wikipedia.org/wiki/Rundsteuertechnik
2 Cent schrieb: > möglicher Auslöser: > https://de.wikipedia.org/wiki/Rundsteuertechnik Aber nur, wenn das Netzteil großer Mist ist. Auf dem Klo habe ich einen 12V 60VA Trafo, wo anstatt der Halogenlampen nun fertige China-LED-Strahler dran hängen. Die habe im Innenleben einem Brückengleichrichter und einen sehr kleinen Laddelko vor dem Schaltregler (MC 34063) - da flackert es abends um die volle Stunde herum. An anderen Stellen habe ich Schaltnetzteile vor den LEDs, da kommen keine Rundsteuersignale durch.
Falls es wirklich Störsignale durch Rundsteuertechnik sind, was hätte das mit dem Netzteil zu tun? Die Nullphasendurchgänge werden doch direkt an der Steckdose abgegriffen/gemessen
Manfred schrieb: > 2 Cent schrieb: >> möglicher Auslöser: >> https://de.wikipedia.org/wiki/Rundsteuertechnik > > Aber nur, wenn das Netzteil großer Mist ist. ??? Die Nulldurchgangserkeunnung des TO (und der Interruptauslöser) hat irgendwas mit "Mist" des NT zu tun??? ??? > Auf dem Klo habe ich einen 12V 60VA Trafo, wo anstatt der Halogenlampen > nun fertige China-LED-Strahler dran hängen. Die habe im Innenleben einem > Brückengleichrichter und einen sehr kleinen Laddelko vor dem > Schaltregler (MC 34063) - da flackert es abends um die volle Stunde > herum. Dann mach dir mal Gedanken. Und einen neuen Thread. > An anderen Stellen habe ich Schaltnetzteile vor den LEDs, da kommen > keine Rundsteuersignale durch. Auch dies kann vorkommen. Prima :D
Marco schrieb: > Die Nullphasendurchgänge werden doch direkt > an der Steckdose abgegriffen/gemessen Anscheinend.
Gnorm schrieb: > Marco G. schrieb: >> int dimtime = (78*dimming); > > Wie gross ist denn ein int auf Arduino??? groß genug?! (78*128 = 9984) https://www.arduino.cc/reference/de/language/variables/data-types/int/
Die dimming Variable muss auf jeden Fall volatile sein. Du musst dein Problem in Teile zerlegen. Ich würde dazu als die Lampe in einen gedimmten Zustand bringen und dann die I²C Verbindung zwischen AVR und ESP trennen. Die Lampe sollte dann ihre aktuelle Helligkeit beibehalten, richtig? Tut sie das denn auch den ganzen Tag lang? Danach weisst du, ob das Problem vom ESP aus geht, oder von woanders her kommt. Wie hast du denn die Stromversorgung realisiert? Woher bekommt der AVR seine Versorgung, woher der ESP? Zeige den vollständigen Schaltplan. Welche Netzteile hast du verwendet? Wie ist die Leitungsführung (mache Fotos)? All das sind wichtige Fragen, ganz besonders bei sporadischen Aussetzern.
Angehängte Dateien:
-
Plan.jpg
220 KB
Danke für deine Antwort! Ich wollte erst alles verlöten wenn es richtig funktioniert, daher ist es derzeit noch auf dem Breadboard gesteckt. Die Spannungsversorgung über dieses Standart 5 Volt Breadboard Netzteil was es immer dazu gibt... sollte ich das mal tauschen? Ich habe keine geeignete Software um professionelle Pläne zu erstellen, aber habe trotzdem mal einen groben Plan in den Anhang gesetzt. Also seinen gedimmten Zustand behällt er eigentlich... es wird ja meistens gegen 11-12 Uhr in der Wohnung so warm, dass das Dimmen einsetzt und angenommen er dimmt bis 60 Prozent runter, dann bleibt es auch so bis Abends. Er setzt nur um die Mittagszeit zwischen 12.30 und 14 Uhr mal für eine halbe Stunde komplett aus eingeleitet von heftigem Flackern. Ich habe heute den Uno mal durch einen Nano ersetzt und beobachte das Phenomen. Sollte es heute wieder passieren werde ich den Code für die Kommunikation mit dem ESP mal auskommentieren und schauen was passiert. Danke
winnetu schrieb: > Code Murks > Technik Murks > = > Ergebnis Murks Ok, das mag sein. Aber dann bitte mit Verbesserungsvorschlag sonst ist das ein ziemlich unproduktiver Kommentar.
Marco G. schrieb: > Die ersten beiden Fehler habe ich beseitigt. > Delays in Interrupts sollte man vermeiden weil der restliche > Programmfluss aufgehalten wird. In meinem Fall gibt es außer der Dimmer > Steuerung aber sonst nichts außer den Erhalt von Daten vom ESP was nur > alle 10 min einmal passiert. Ist es dann trotzdem noch wichtig? Ja, das ist wichtig. Die I2C Kommunikation läuft ja auch Interrupt getrieben, und eventuell kommen sich deine zero_crosss_int() ISR und die Wire ISR zu bestimmten Zeiten so in die Quere, daß die Wire Interrupt Routine an irgendeiner Stelle noch auf ein Ereignis wartet das nicht mehr eintritt, und damit weitere Interrupts blockiert. Bis dann nach 5 oder N x 5 Minuten weitere I2C Datenpakete vom Master den Fehler auflösen. Soweit erst mal nur eine Theorie. Du könntest das testen, indem du deine Delays erst noch in der ISR belässt, und einfach nur in der Loop() eine LED blinken läßt. Falls die Wire ISR längere Zeit blockiert, wird die LED nicht mehr blinken. Da die 50Hz Netzfrequenz und dein 5 Minuten Kommunikationszyklus nicht synchronisiert sind, wird irgendwann der Nulldurchgang und eine I2C Kommunikation quasi gleichzeitig stattfinden, und anschließend wieder auseinanderlaufen (Schwebung). Das könnte den langen Zeitraum zwischen den Fehlverhalten erklären.
Marco G. schrieb: > Ich wollte erst alles verlöten wenn es richtig > funktioniert, daher ist es derzeit noch auf dem Breadboard gesteckt. Schöne Zeichnung. An SDA und SCL gehören Pull-Up Widerstände mit 4,7kΩ. Breadboards eignen sich nicht zur Stromversorgung von ESP Modulen, sie haben zu hohe Kontaktwiderstände. Dein kleines Spannungsgregler Board könnte überfordert sein. Wenn da nur 100mA fließen, muss es bereits 700 mW verheizen, was für Chips dieser Größe schon sehr grenzwertig ist. Hast du ein Oszilloskop, mit dem du die Stabilität der Versorgungsspannung prüfen kannst? Hast du ein Oszilloskop? Wenn nicht, besorge Dir eins. Wenn es billig sein muss, dann wenigstens ein DSO138. Damit kannst du die Stromversorgung und die I²C Kommunikation prüfen.
Cubalibre schrieb: > Da die 50Hz Netzfrequenz ... Die 50Hz Netzfrequenz tritt beim Dimmen nicht zu Tage. Der Dimmer muss die Halbwellen mit 100Hz Wiederholfrequenz zünden. Bei einem durch den 5min Kommunikationszyklus ausgelösten Flackern, müsste das Flackern auch diesen 5min Rhythmus zeigen. Grundsätzlich hört sich Flackern nach fehlenden Zündungen an, was man am besten mit passenden Messgeräten, z.B. einem kleinen Logikanalysator erfassen könnte. Alles andere ist Kaffeesatzleserei.
Die Pull-Up Widerstände müssen nach 3,3V gehen. Wenn du keine 4,7kΩ
vorliegen hast, nimm weniger Ohm (nicht mehr).
> Grundsätzlich hört sich Flackern nach fehlenden Zündungen an
Warte erst mal ab, ob das Problem nicht schon von der Steuerung durch
den ESP ausgeht.
Wenn mein Auto nicht fährt, kann ich natürlich auch den Reifendruck
messsen, falls ich möchte. Aber erst einmal sollte man gucken, ob der
Motor überhaupt läuft.
Marco G. schrieb: > int dimming = 4; // Dimming level (0-128) 0 = ON, 128 = OFF Weiss jetzt nicht ob es hier relevant ist, aber bei int8 ist der positive Zahlenbereich 0-127. Was kommt also bei der multiplikation 78*128 heraus? Also besser "volatile unsigend int dimming"
Hubert G. schrieb: > Weiss jetzt nicht ob es hier relevant ist, aber bei int8 ist der > positive Zahlenbereich 0-127. Was kommt also bei der multiplikation > 78*128 heraus? Also besser "volatile unsigend int dimming" Du hast die beiden Variablen "dimming" und "dimtime" verwechselt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.