Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Ich bin am durchdrehn... das Programm soll meine Kellerfensterlüftung automatisieren.
Es sieht so aus als würde "fenster_schliessen" nie durchlaufen. Ich komm nicht drauf warum ? Die Schalter "Hand_Zu" und "Hand_Auf" liefern ihre 5V sauber an den Pins ab.
Die Signale "ZylAus_I" und "ZylEin_I" sind auf dauerhigh gelegt.
Ist warscheinlich wieder son Anfängerding...

Code: Alles auswählen

//*************** HW Pinbelegung Leonardo Micro ***************************
//Pin 2 - I2C SDA
//Pin 3 - I2C SCL
//Pin 4 - OneWire Data (mit PullUp 4k7 an Vcc)
//Pin 5 - ZylAus_O Output für Signal Zylinder ausfahren
//Pin 6 - ZylEin_O Output für Signal Zylinder einfahren
//Pin 7 - ZylAus_I Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
//Pin 8 - ZylEin_I Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
//Pin 9 - Hand_Auf Input für Signal Fenster manuell öffnen
//Pin10 - Hand_Zu  Input für Signal Fenster manuell schliessen

//  ************* Libraries **************************
                             // Library starten

//  ************* Variablen ******************************
  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren
  int ZylAus_I = 7; // Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
  int Hand_Auf = 9; // Input für Signal Fenster manuell öffnen
  int Hand_Zu = 10; // Input für Signal Fenster manuell schliessen

//  ************* Setup ******************************
void setup() 
{
  Serial.begin (9600);  // UART Kommunikation initialisieren und auf 9600 Baud
  
// ************* Pinzuweisungen I/O *****************
  pinMode(ZylAus_O, OUTPUT);
  pinMode(ZylEin_O, OUTPUT);
  pinMode(ZylAus_I, INPUT);
  pinMode(ZylEin_I, INPUT);
  pinMode(Hand_Auf, INPUT);
  pinMode(Hand_Zu, INPUT);

  digitalWrite(ZylAus_O,LOW);  //Bei Programmstart Ausgänge auf LOW setzen
  digitalWrite(ZylEin_O,LOW);
  
}

// ************* Routinen für öffnen und schliessen *****
// ******** offnen *******************
void fenster_oeffnen ()   // Starten der Funktion Fenster öffnen
{
  if(digitalRead(ZylAus_I) == HIGH)    // Wenn Endschalter nicht belegt, Zylinder ausfahren sonst Ausgang auf 0 setzen
  {
    digitalWrite(ZylAus_O, HIGH);// Wenn Endschalter nicht belegt, Zylinder ausfahren über Pin ZylAus_O (9)
    Serial.println("fenster_oeffnen gelaufen");
    delay(1000);        //Nur zum testen weil noch ohne Endschalter
  }
   else
   {
    digitalWrite(ZylAus_O,0);      // Wenn Endschalter nicht belegt, Ausgang auf 0 setzen
   }
}
// ******** schließen ***************
void fenster_schliessen ()
{
  if(ZylEin_I == HIGH)
  {
    digitalWrite(ZylEin_O, HIGH);
    Serial.println("fenster_schliessen gelaufen");
    delay(1000);        //Nur zum testen weil noch ohne Endschalter
  }
   else
   {
    digitalWrite(ZylEin_O,0);
   }
}

// ************* Ende Routinen für öffnen und schliessen *****
  
// ************* Hauptprogramm ***********************

void loop() {
  // put your main code here, to run repeatedly:

  if(digitalRead(Hand_Auf) == HIGH)
   {
    fenster_oeffnen();
    Serial.println("Fenster ist offen");
   }
    else
    if(digitalRead(Hand_Zu) == HIGH)
    {
     fenster_schliessen();
     Serial.println("Fenster ist zu");
    }
      else
      {
   Serial.println("Automatik");
      }
}
ch_ris
Beiträge: 3050
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

mach doch mal eine ausgabe zu jeder Anweisung.
Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

ich hab ja in jedem Teil die "println" drin.
Bis auf "fenster_schliessen gelaufen" kommen auch brav die Meldungen zum passenden Moment.
Signal "ZylEin_O" (Output für Signal Zylinder einfahren) wird nie gesetzt. Daher glaube ich das das Programm nie daran vorbei kommt.

Die Signale "ZylAus_I" und "ZylEin_I" sind inzwischen auch über Schalter.

Da muß doch in der Hauptschleifenfuktion was in die Hose gehen... oder?
// ************* Hauptprogramm ***********************

void loop() {
// put your main code here, to run repeatedly:

if(digitalRead(Hand_Auf) == HIGH)
{
fenster_oeffnen();
Serial.println("Fenster ist offen");
}
else
if(digitalRead(Hand_Zu) == HIGH)
{
fenster_schliessen();
Serial.println("Fenster ist zu");
}
else
{
Serial.println("Automatik");
}
}
Benutzeravatar
Hightech
Beiträge: 11493
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Im else steht ein if hintenan, soll das so?
Da bekomme ich einen Knoten im Hirn, da müsste ich mir erstmal ein Plan zu zeichnen.
Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

das soll ein "else if" sein, das Handbuch sagt so :
zit:
'else' kann auch noch weitere 'if' Abfragen enthalten, so dass mehrfache Test zur selben Zeit stattfinden können. Es ist sogar möglich eine unbegrenzte Anzahl von diesen 'else' Abzweigungen zu nutzen. Allerdings wird je nach den Bedingungen nur ein Set von Anweisungen ausgeführt:
if (inputPin < 500)
{ doThingA; }
else if (inputPin >= 1000)
{ doThingB; }
else
{ doThingC; }
ende zit

(das if braucht nicht in der gleichen Zeile zu stehen wie das else (hab ich ausprobiert))
ch_ris
Beiträge: 3050
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

es ist ja nun nix mit breakpoints und Debugger. bleibt nur konsequent alles zu loggen, dann siehste sofort wo es klemmt.
sag ich, wasser predigend.....
Benutzeravatar
Bastelbruder
Beiträge: 11566
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Prost!
Benutzeravatar
ferdimh
Beiträge: 9430
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Ich sehe hier das größte Fehlerpotential in der Pinzuordnung.
Ich würde da mal ein Testprogramm schreiben, das den fraglichen Pin als Ausgang konfiguriert und daran irgendwas eindeutig identifizierbares tut.
Dann den Pin als Eingang konfigurieren und den Zustand ausgeben.
Dann im fraglichen Programm die "nie aufgerufenen" Bedingung durch eine 1 ersetzen, so dass sie immer aufgerufen wird.
Dann ist der Fehler schon mal sehr weit eingegrenzt.

Die Konstante "HIGH" ist mir auch neu, hier besteht auch noch eine Fehlermöglichkeit.
j.o.e
Beiträge: 552
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

Code: Alles auswählen

void fenster_schliessen ()
{
  if(ZylEin_I == HIGH)
  {
    digitalWrite(ZylEin_O, HIGH);
    Serial.println("fenster_schliessen gelaufen");
    

Code: Alles auswählen

  if(digitalRead(ZylEin_I) == HIGH)
sollte es tun

Edith meinte, ich sollte das noch erklären.

Oben schreibst Du

Code: Alles auswählen

  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
auf deinem if(ZylEin_I == HIGH) wird damit if(8 == HIGH) - und das trifft halt nie ein, höchstes es verderht dir jemand das ZylEin_I.

Da das sowieso nicht gewollt ist, schreibt man besser

Code: Alles auswählen

  const int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
oder eben

Code: Alles auswählen

#define ZylEin_I  8
Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Danke ! Werd ich morgen mal angehen. If digitalRead dürfte es gewesen sein...
Das wars! Ich habe bestimmt 20mal über die Zeile geschaut es selbst aber nicht gesehen...
EDIT:
So, es hat funktioniert :-) DANKE WIEDER MAL ANS FORUM !

Und hier der Endgültige Code - das Gesamtkunstwerk kommt mit Bildern in "Eure Projekte..." wenns fertig ist.

Code: Alles auswählen

//*************** HW Pinbelegung Leonardo Micro ***************************
//Pin 2 - I2C SDA
//Pin 3 - I2C SCL
//Pin 4 - OneWire Data (mit PullUp 4k7 an Vcc)
//Pin 5 - ZylAus_O Output für Signal Zylinder ausfahren (Relais oder SSR für Ausfahrmotor [oder Drehrichtung 1]
//Pin 6 - ZylEin_O Output für Signal Zylinder einfahren (Relais oder SSR für Einfahrmotor [oder Drehrichtung 2]
//Pin 7 - ZylAus_I Input für Signal Zylinder ausgefahren (Endschalter Endposition belegt)
//Pin 8 - ZylEin_I Input für Signal Zylinder eingefahren (Endschalter Anfangsposition belegt)
//Pin 9 - Hand_Auf Input für Schalter-Signal Fenster manuell öffnen
//Pin10 - Hand_Zu  Input für Schalter-Signal Fenster manuell schliessen

//  ************* Libraries **************************
#include <OneWire.h>            // für Dallas 18B20 Temp.-Chip
#include <DallasTemperature.h>  // für Dallas 18B20 Temp.-Chip 
#include "Wire.h"               // für SHT31 Temp./RH-Chip
#include "SHT31.h"              // für SHT31 Temp./RH-Chip

OneWire oneWire(4);                    // Data Pin von Sensor am Pin 4 angeschlossen (4)
DallasTemperature sensors(&oneWire);   // Library starten
SHT31 sht;                             // Library starten

//  ************* Variablen ******************************
  float gradC_I;   // Innentemperatur in Grad Celsius
  float gradC_A;   // Aussentemperatur in Grad C
  float humid_RH;  // Aussenfeuchte in %RH
  float tp;        // Taupunkt in Grad C

  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren
  int ZylAus_I = 7; // Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
  int Hand_Auf = 9; // Input für Signal Fenster manuell öffnen
  int Hand_Zu = 10; // Input für Signal Fenster manuell schliessen

//  ************* Setup ******************************
void setup() 
{
  Serial.begin (9600);  // UART Kommunikation initialisieren und auf 9600 Baud
  sensors.begin();      // Dallas 18B20 initialisieren

  Wire.begin();         // I2C Initialisieren
  sht.begin(0x44);      // SHT31 initialisieren
  Wire.setClock(1000);  // I2C Geschwindigkeit auf 1000 setzen

// ************* Pinzuweisungen I/O *****************
  pinMode(ZylAus_O, OUTPUT);
  pinMode(ZylEin_O, OUTPUT);
  pinMode(ZylAus_I, INPUT);
  pinMode(ZylEin_I, INPUT);
  pinMode(Hand_Auf, INPUT);
  pinMode(Hand_Zu, INPUT);

  digitalWrite(ZylAus_O,LOW);  //Bei Programmstart Ausgänge für Zylindermotoren auf LOW setzen
  digitalWrite(ZylEin_O,LOW);
}

// ***************Funktionsroutinen *****************
//void fenster_oeffnen()   // Funktion Fenster öffnen
//void fenster_schliessen()// Funktion Fenster schliessen
//float werte_einlesen     // Funktion Sensoren ausesen

// ************* Routinen für öffnen und schliessen *****

// ******** öffnen *******************
void fenster_oeffnen()   // Starten der Funktion Fenster öffnen
{
   digitalWrite(ZylEin_O,LOW);    // Sicherstellen, dass nie beide Zylindermotoren gleichzeitig laufen
   digitalWrite(ZylAus_O, HIGH);  // Zylinder ausfahren über Pin ZylAus_O (5)
   
    while(digitalRead(ZylAus_I) == HIGH) // Solange Endschalter nicht belegt, bleibt ZylAus_O = HIGH, sonst ZylAus_O zurücksetzen
   {
    digitalWrite(ZylAus_O, HIGH);
   }
  digitalWrite(ZylAus_O, LOW);
  }
// ******** schließen ***************
void fenster_schliessen()
{
  digitalWrite(ZylAus_O,LOW);
  digitalWrite(ZylEin_O, HIGH);
  
  while(digitalRead(ZylEin_I) == HIGH)
  {
   digitalWrite(ZylEin_O, HIGH);
  }
  digitalWrite(ZylEin_O, LOW);
  }
// ************* Ende Routinen für öffnen und schliessen *****

// *************Routine Werte aus Sensoren einlesen***********
float werte_einlesen()
{
// ---   Messwerte aus Sensoren einlesen   ---
    // Anfang Messung Innentemperatur ( gradC ) vom Dallas Temperatursensor
    sensors.requestTemperatures();     // Temperaturmessung starten
    gradC_I=sensors.getTempCByIndex(0);  // gemessene Temperatur der Variablen gradC_I zuweisen
    //Ende Messung Innentemperatur vom Dallas Temperatursensor. Temperatur nun in der Variable gradC

    // Anfang Messung Aussentemperatur (gradC_A) und Feuchte (humid_RH) vom SGT31 Sensor
     sht.read();         //SHT31 Messung starten
     gradC_A=sht.getTemperature(), 1;  //SHT31 Temperaturwert in Variable gradC_A speichern
     humid_RH=sht.getHumidity(), 1;    //SHT31 Feuchtewertt in Variable humid_RH speichern
    // Ende Messung Aussentemperatur (gradC_A) und Feuchte (humid_RH) vom SGT31 Sensor
// ---      Messwerte sind eingelesen      ---
}
// ************** Routine Taupunktberechnung ****************
float taupunkt_berechnen()
{
    // verwendete Variablen :
    //  float gradC_I;   // Innentemperatur in Grad Celsius
    //  float gradC_A;   // Aussentemperatur in Grad C
    //  float humid_RH;  // Aussenfeuchte in %RH
    //  float tp;        // Taupunkt in Grad C
    //--- Formel für Taupunktberechnung ---------------------
      tp = 243.12*((17.62*gradC_A)/(243.12+gradC_A)+log(humid_RH/100))/((17.62*243.12)/(243.12+gradC_A)-log(humid_RH/100));
    // *************Ende Routine Taupunktberechnung***********
// ---          Messwerte ausgeben         ---
      Serial.print("Innentemperatur:  ");
      Serial.println (gradC_I);            // Variable gradC_I auf UART ausgeben
      Serial.print("Aussentemperatur: ");
      Serial.println(gradC_A);           // Variable gradC_A auf UART ausgeben
      Serial.print("Aussenfeuchte RH: ");
      Serial.println(humid_RH);          // Variable humid_RH auf UART ausgeben
      Serial.print("Taupunkt:         ");
      Serial.println(tp);
      delay(1000);
// ---      Messwerte sind ausgegeben     ---
// *************Ende Routine Werte aus Sensoren einlesen***********
}
  
// ************* Hauptprogramm ***********************
void loop() 
{
// --- Prüfung Hand- oder Automatikbetrieb ---
  werte_einlesen();                             //Sensorwerte einlesen
  taupunkt_berechnen();                         //Routine taupunkt_berechnen anspringen
  
 if(digitalRead(Hand_Auf) == HIGH)
   {                                           //WENN "Handbetrieb öffnen" dann Routine fenster_oeffnen anspringen
    fenster_oeffnen();                          //Routine fenster_oeffnen anspringen
    Serial.println("Handbetrieb(öffnen)");      //Statusmeldung "Handbetrieb(öffnen)" auf UART ausgeben
   }
    else if(digitalRead(Hand_Zu) == HIGH)
    {                                            //SONST1, wenn "Handbetrieb schliessen" dann Routine fenster_schliessen anspringen
     fenster_schliessen();                       //Routine fenster_schliessen anspringen
     Serial.println("Handbetrieb(schliessen)");  //Statusmeldung "Handbetrieb(schliessen)" auf UART ausgeben
    }
                                                 //SONST2, wenn kein Handbetrieb ausgewählt, dann Automatikmodus
     else if(gradC_A < gradC_I)
     {                                            //WENN Aussentemperatur kleiner als Innentemperatur, dann Routine fenster_schliessen anspringen
      Serial.println("Automatik schliessen A<I"); //Statusmeldung "Automatik schliessen A<I" auf UART ausgeben
      fenster_schliessen();                       //Routine fenster_schliessen anspringen
      while(gradC_A < gradC_I)                    //So lange hier bleiben wie Aussentempertaut kleiner Innentemperatur
        {
        werte_einlesen();
        Serial.print("Innentemperatur:  ");
        Serial.println (gradC_I);            // Variable gradC_I auf UART ausgeben
        Serial.print("Aussentemperatur: ");
        Serial.println(gradC_A);           // Variable gradC_A auf UART ausgeben
        Serial.println("Aussen kälter als Innen");//Statusmeldung "Aussen kälter als Innen" auf UART ausgeben
        }                       
     }  
       else if(tp > gradC_I)
       {                                            //SONST3, wenn Taupunkt über Innentemperatur, dann Routine fenster_schliessen anspringen
        Serial.println("Automatik schliessen TP>I");//Statusmeldung "Automatik schliessen TP>I" auf UART ausgeben
        fenster_schliessen();                      //Routine fenster_schliessen anspringen
       }  
        else if(tp < gradC_I) 
        {                                          //SONST4, wenn Taupunkt unter unter Innentemperatur, dann Routine fenster_oeffnen anspringen
         Serial.println("Automatik öffnen TP<I");  //Statusmeldung "Automatik öffnen TP<I" auf UART ausgeben
         fenster_oeffnen();                        //Routine fenster_oeffnen anspringen
        }
         
}
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Auf Geheiß poste ich hier mal mein derzeitiges Problem.

Was es können soll:

Einen Motor, den ich an 24V AC habe und der im Steinmetz angeschlossen ist, in der Drehrichtung alle 10 Sekunden umschalten.
Der Motor braucht 8 Sekunden bis er eine Endlage erreicht und hat 2 Sekunden Wartezeit.

Geschaltet werden soll er über so eine China Relaiskarte mit 8 Relais. Ich brauche zwar nur eins, habe aber nur die Karte hier.

Der Programmcode dazu ist dieser:

Code: Alles auswählen

const int RELAY1 = 10;
unsigned long startzeit_1 = 0;
unsigned long laufzeit_1 = 10000;
void setup()
  {
  Serial.begin(115200);
  while (!Serial);
  digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);
  }


void loop()
  {
  if (millis() - startzeit_1 >= laufzeit_1)
    {
    Serial.println(startzeit_1);
    startzeit_1 = millis();
    digitalWrite(RELAY1, !digitalRead(RELAY1));
    Serial.println(startzeit_1);
    }
  }
Über den Monitor sollte man eigentlich die 10 Sekunden Steps ablesen können.

Was aber passiert, ist, dass der Serielle Monitor nichts mehr anzeigt, sobald das Programm läuft UND die 24V AC geschaltet werden.

Also scheint die Wechselspannung irgendwie zum disconnect zu führen. Außerdem hängt sich die Schleife
nach einiger Zeit auf.


So ist der Motor am Relais dran:
Anschluss2.JPG
Über den Mittelkontakt kommen die 24V AC rein, an den beiden äußeren Kontakten (NO/NC) hängen die beiden Leiter
für die Drehrichtungen.

Und der N geht wieder zurück.

Gespeist wird das über einen Modellbahntrafo und der Arduino versorgt sich über USB.
ch_ris
Beiträge: 3050
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

wie und wo kommt der arduino ins Spiel?
Das ist doch die wesentliche Information :!:
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Ach so, der Arduino ist dazu da, das eine Relais (und später über Taster zwei andere) zu schalten.

Spannung für die Relais und der Steuerpin kommen vom Arduino und gehen da drauf.

Hätte nicht gedacht, dass eine Anwendung, die eigentlich jedes Zeitrelais drauf hat, so schwer sein würde.
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

Was mir als erstes auffällt:

Code: Alles auswählen

digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);
Du setzt irgendwas und definierst dann die Richtung.
Soll das so?
Cubicany hat geschrieben: Mi 24. Jun 2020, 11:00 Spannung für die Relais und der Steuerpin kommen vom Arduino und gehen da drauf.
Wie viel Strom zieht das Relais?
Freilaufdiode vorhanden?
Was macht die Betriebsspannung vom Arduino, wenn das Relais schaltet?

Ggf. kommt da noch ein Transistor als Schalter rein.
Und eine stabile 5V-Versorgung, für das Relais gern extra.


Hängt sich die Schleife auch auf, wenn die 24V AC nicht vorhanden sind, jedoch das Relais schaltet?
Hängt sich die Schleife auch auf, wenn weder Relais noch 24V AC vorhanden sind?
berlinerbaer
Beiträge: 1063
Registriert: Di 22. Aug 2017, 05:19
Wohnort: Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von berlinerbaer »

Cubicany hat geschrieben: Mi 24. Jun 2020, 08:22
Was aber passiert, ist, dass der Serielle Monitor nichts mehr anzeigt, sobald das Programm läuft UND die 24V AC geschaltet werden.

Also scheint die Wechselspannung irgendwie zum disconnect zu führen. Außerdem hängt sich die Schleife
nach einiger Zeit auf.
Das müsste eigentlich funktionieren.

Jetzt gilt es, potentielle Fehlerquellen einzukreisen:

• Läuft die Schleife störungsfrei, solange die 24V nicht anliegen?
• Immer noch, wenn die Verkabelung zu Trafo und Motor hergestellt sind, aber noch kein Strom auf dem Trafo ist?
• Probier mal ein anderes Relais, sieben haste ja noch ;-)
• Und ein anderes, bekannt verlässliches, kurzes USB-Kabel
• Mach mal lieber Serial.begin(9600); , wir hams ja nicht eilig
• Schau Dir mal die Relais-Platine genau an. Sind da vielleicht Fluxreste drauf, die Kriechströme vom Wechselstrom auf die Arduino-Versorgung ermöglichen?
• Lass den Arduino mal über einen Akku-versorgten laptop laufen, vielleicht ist das 230V-Netz am Problem beteiligt

Das ist jetzt natürlich alles stochern im Nebel, denn eigentlich sollte der Aufbau so elektrisch funktionieren, Code hab ich mir nicht angeguckt.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Ich gehe das alles mal von oben nach unten durch.

Der Code wurde mir im den Arduino Forum so empfohlen.
Den habe ich noch nicht mal selber gemacht.
Ich verstehe noch nicht mal alles, was da steht.

Wie viel Strom das Relais zieht?

Kann nicht so viel sein. Außerdem hatte ich ein anderes Programm, wo
alle Relais an sind und das lief. Also ein Spannungseinbruch schließe ich
mal gewagt aus.

Freilaufdiode?

Haben diese China Karten eventuell schon eine drauf? Ich weiß es ehrlich gesagt nicht.

Die Schleife hängt sich auch auf, wenn weder Last, noch Trafo oder so in egal welcher
Konstellation da sind.

Es ist auch egal, welches Relais, welches Kabel oder Rechner.

Ich habe auch echt keine Idee mehr, was ich noch machen soll.

Ich bin echt drauf und dran, das alles raus zu schmeißen und einfach ein Zeitrelais mit
zwei Tastern dran zu machen. Geht auch.
ch_ris
Beiträge: 3050
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

war quatsch.

wie jetz? der code läuft nicht sobald du das relais anschließt?
Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Probier mal aus was sysconsol schrub. ERST die Richtung definieren, dann DigitalWrite.
Ich hatte auch sonderliche effekte, ihne das der Compiler meckerte.
berlinerbaer
Beiträge: 1063
Registriert: Di 22. Aug 2017, 05:19
Wohnort: Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von berlinerbaer »

sysconsol hat geschrieben: Mi 24. Jun 2020, 11:39 Was mir als erstes auffällt:

Code: Alles auswählen

digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);
Du setzt irgendwas und definierst dann die Richtung.
Das ist schonmal ein sehr berechtigter Einwand.

Diese beiden Zeilen sollten die Plätze tauschen, denn sonst ist der interne pullup beim digitalWrite noch aktiv, es sei denn, der compiler biegt das hinter Deinem Rücken wieder gerade. Würde ich mich nicht drauf verlassen und stattdessen sauber arbeiten.

Das könnte die beim Relais ankommende Spannung derart begrenzen, daß es nicht mehr verlässlich schaltet.

Ansonsten ist das Deine Baustelle, wenn also Dein Code nicht funzt und Du auch nicht den Ehrgeiz hast, herauszufinden woran das liegt, weil irgendwelche Arduino-Foristen, die nicht in der Lage sind, die Doku sinnentnehmend zu lesen (https://www.arduino.cc/reference/de/lan ... italwrite/) und meinen, das passt schon, dann sieht das nicht sehr erfolgversprechend aus.

Klar kann das frustrierend sein, aber auch eine Herausforderung, an die man positiv herangehen kann...

Verstehe ich das richtig, daß, auch wenn Du nur die Relais-Platine schaltest, jedoch keine Kabel mit dem Leistungsteil der Relais verbunden sind, trotzdem Probleme auftreten?
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Das eben war gerade wtwas in Rage in die Tastatur gehauen.

Ich kniffel da schon gerne dran rum.

Aber um auf die Frage zu kommen:

Tatsächlich tritt das auch ohne Last auf.

Sehr selten, aber die Schleife kommt dann zum Erliegen. Vermutlich, weil ja die
Bedingung "geschaltetes Relais" nicht mehr kommt. Ich versuche mal, das mit den
getauschten Zeilen drauf zu ziehen.

Mit Last tritt der Effekt schneller auf.

Nur wundert es mich, dass die Arduino.cc Leute das genau so empfohlen haben.

Aber da gibt es so viele Ansichten wie Widerstandswerte in der Norm. Das durfte
ich da schon lernen.
Benutzeravatar
Sven
Beiträge: 4423
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

Mal dir mal als Ablaufdiagramm auf, was dein Programm tun soll. Daraus lässt sich dann leichter funktionierender Code ableiten als aus nicht funktionierendem Code und Beschreibungstext zur gewünschten Funktion.
ch_ris
Beiträge: 3050
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ich hab mir den code nicht angesehen...
mach mal n 9v block dran, vielleicht taugt der usb nix?
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Ich habe den auch an Netzgerät gehabt und über USB dann ausgewertet. Den Port habe ich auch mal gewechselt.

Momentan läuft es und ich bin mal vorsichtig optimistisch, das es jetzt geht.

Ablaufdiagramm habe ich bisher nur einmal eins gemacht und das war ein Krampf, wie ich damals fand.

Wie gesagt, ich hatte ganze 2 Stunden Info.
Benutzeravatar
Sven
Beiträge: 4423
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

Cubicany hat geschrieben: Mi 24. Jun 2020, 14:06 Ablaufdiagramm habe ich bisher nur einmal eins gemacht und das war ein Krampf, wie ich damals fand.

Wie gesagt, ich hatte ganze 2 Stunden Info.
Es muss ja nicht nach Norm sein. Allerdings funktioniert planloses Programmieren nicht. Gerade Anfänger sollten
sich tunlichst erstmal klar machen, was sie überhaupt erreichen wollen. Also mal dir eben auf, was dein Programm überhaupt tun soll. Außerdem erleichtert es uns dann, dir zu helfen.
Wenn die logische Struktur in der Programmidee schon nicht korrekt ist, wie soll dann das Programm denn richtig funktionieren?


Ich bin seit vielen Jahren als Softwareentwickler unterwegs und kritzel mir immer noch Pläne, Zustandsmatrizen und ähnliches, wenn komplexere
Dinge angegangen werden. Das ist nämlich 75% der eigentlichen Arbeit. Der Rest ist dann "nur noch" übersetzen in eine dem System verständliche Sprache.
Für einfachen Kram braucht man sowas später nicht mehr, das ist klar.
Anse
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Cubicany hat geschrieben: Mi 24. Jun 2020, 13:47 Nur wundert es mich, dass die Arduino.cc Leute das genau so empfohlen haben.
Arduino ist für Quereinsteiger entwickelt. Was hast Du erwartet? Wirst in so einem Forum nur sehr wenige µC Profis, wenn überhaupt, finden.
Denkt mal, die Erfahrungs-Dichte ist hier deutlich größer.

Zur eigentlichen Frage, um eine AVR so richtig aus dem Tritt zu bringen braucht es schon mehr. Off kommt das von Störungen auf der Versorgung. Also mal einen Elko parallel und eine Induktivität in reihe in die Versorgung. Kann auch sein, dass der Spannungsregler auf dem Board bei kurzer Überspannung für einen Moment zu macht.
Dann eventuell auch mal die Relais Ansteuerung mit einem Optokoppler abtrennen. Ist zwar doppelt aber so ein Relais kann gerade bei AC auch Störungen übertragen. Freilaufdiode übers Relais ist aber hoffentlich selbstverständlich.
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

Cubicany hat geschrieben: Mi 24. Jun 2020, 13:47 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 :twisted:

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 :roll:

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
Beiträge: 1063
Registriert: Di 22. Aug 2017, 05:19
Wohnort: Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

berlinerbaer hat geschrieben: Mi 24. Jun 2020, 14:57
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
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Jaaa, auch mit Tastern geht es! :D

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
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Cubicany hat geschrieben: Mi 24. Jun 2020, 17:07 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Wie sähe denn ein Timer aus?

Delay ist es ja nicht.
Anse
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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
Beiträge: 2212
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Anse hat geschrieben: Mi 24. Jun 2020, 17:39 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

IPv6 hat geschrieben: Mi 24. Jun 2020, 20:23 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.
IPv6 hat geschrieben: Mi 24. Jun 2020, 20:23 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

IMG_9021.JPG
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
Beiträge: 2212
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Anse hat geschrieben: Mi 24. Jun 2020, 21:43 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.
Anse hat geschrieben: Mi 24. Jun 2020, 21:43 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.
Anse hat geschrieben: Mi 24. Jun 2020, 21:43 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
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

IPv6 hat geschrieben: Mi 24. Jun 2020, 22:29 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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Später Gast
Beiträge: 1705
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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
Beiträge: 2212
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Cubicany hat geschrieben: Mi 24. Jun 2020, 23:00 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 :D
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.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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
Beiträge: 2307
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Schon mal alles Serial Prints raus aus dem Programm?
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Raja_Kentut
Beiträge: 1560
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Cubicany hat geschrieben: Mi 24. Jun 2020, 21:32 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
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von 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.
Benutzeravatar
Später Gast
Beiträge: 1705
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

IPv6 hat geschrieben: Mi 24. Jun 2020, 23:26 @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.
Antworten