-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 23

Thema: serial.println blockiert Stepper

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    235

    Unglücklich serial.println blockiert Stepper

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Hallo,

    hier mein StepperCode:

    Code:
    #include <CustomStepper.h>
    
    CustomStepper stepper(8, 9, 10, 11);
    boolean rotate1 = false;
    
    void setup()
    {
      Serial.begin (9600);
    
      stepper.setRPM(12);  //   Drehzahl
    
      stepper.setSPR(4242);    //   Schritte pro Umdrehung, hier für den 28BYJ-48
    }
    
    void loop()
    {
      if (stepper.isDone() &&  rotate1 == false)
      {
        stepper.setDirection(CCW);   //   Drehrichtung  (CW, CCW, and STOP) 
    
       stepper.rotate(10);   
        rotate1 = true;
      }
      
     //      Serial.println ("ok");                  
            
      stepper.run();   
    }
    Mit diesem Code macht der Stepper prima seine 10 Umdrehungen.
    Sobald ich aber die Zeile
    Serial.println ("ok");
    scharf mache und sonst nichts ändere, dreht sich nichts mehr. Es steht nur ein Ausgang des Treibers fest an.
    das ändert sich auch nicht nach einem RESET oder mit "Serial.print ("ok");

    Wie ist das möglich?

  2. #2
    RN-Premium User Roboter-Spezialist Avatar von witkatz
    Registriert seit
    24.05.2006
    Ort
    NRW
    Alter
    47
    Beiträge
    458
    Blog-Einträge
    16
    Kenne mich zwar mit Arduino nicht aus, aber bei der Verwendung fertiger Bibliotheken schaue ich mir generell die mitgelieferten Beispiele an. In dem Fall springt mir sofort ins Auge, dass in den Arduino-Beispielen hinter Serial.begin() mit
    Code:
    while (!Serial) {
        ; // wait for serial port to connect. Needed for native USB port only
      }
    gewartet wird, dass die Initialisierung der seriellen Schnittstelle fertig ist. Vielleicht hilft das in deinem Fall auch?

  3. #3
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    235
    Irgendwie scheint es damit zu tun zu haben. Wenn ich dann aber weiter Prints einfüge, um den Programmablauf zu überprüfen, ist das Problem wieder da; besonders, wenn diese Befehle in dem kleinen Programm bei jedem Schleifendurchlauf an die USB SS gesendet werden müssen.
    Wenn ich die Prints jedoch durch ein if nur alle 100 ms ausführen lasse, dann klappt es. Bei 10 ms aber wieder nicht. Ob das dann bei einer Fehlersuch reicht , ist noch die Frage.

    vG

    fredyxx

  4. #4
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    49
    Beiträge
    1.245
    Hm, das klingt nach nem Timing-Problem.
    Die Stepper-Lib. scheint auf nen anständiges Timing angewiesen zu sein (nutzt ja keinen echten Timer), wenn du da ewig mit der seriellen Schnittstelle herummährst, klappt das nicht.
    Stell mal die Baudrate auf nen anständigen Wert rauf, die 9600er bremst so ziemlich allen Kram aus.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.435
    Hallo fredyxx,
    Zitat Zitat von fredyxx Beitrag anzeigen
    Irgendwie scheint es damit zu tun zu haben. Wenn ich dann aber weiter Prints einfüge, um den Programmablauf zu überprüfen, ist das Problem wieder da; besonders, wenn diese Befehle in dem kleinen Programm bei jedem Schleifendurchlauf an die USB SS gesendet werden müssen.
    Wenn ich die Prints jedoch durch ein if nur alle 100 ms ausführen lasse, dann klappt es. Bei 10 ms aber wieder nicht. Ob das dann bei einer Fehlersuch reicht , ist noch die Frage.
    9'600 Baud sind etwa 1'000 Zeichen/s, also 1ms für ein einzelnes Zeichen.

    Serial.println ("ok");
    sendet 4 Zeichen (Die beiden Buchstaben plus CR und LF).

    Da ist die Routine schon mal 4ms beschäftigt.

    Ist aber immer auch eine Frage wie die Bibliothek implementiert ist! Wenn der ganze Ablauf über Interrupts gelöst ist, funktioniert es recht gut im Hintergrund.
    Mit Polling wird halt alles ausgebremst.

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  6. #6
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    235
    Zitat Zitat von Rabenauge Beitrag anzeigen
    Hm, das klingt nach nem Timing-Problem.

    Stell mal die Baudrate auf nen anständigen Wert rauf, die 9600er bremst so ziemlich allen Kram aus.
    Was ist anständig?

  7. #7
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    13.01.2014
    Beiträge
    398
    Blog-Einträge
    3
    Kurz gesagt: Die run() Methode muss innerhalb eines bestimmten Zeitfensters aufgerufen werden.
    Die Zeitfenster ist kleiner als : 60000000.0/SPR/RPM µs also bei deinem Code 1179 µs.
    Abzüglich Rechenzeit der Bibliotheksfunktionen müsstest die loop() mind. jede Millisekunde aufgerufen werden.

  8. #8
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    49
    Beiträge
    1.245
    So schnell es geht?
    Meine Güte- die IDE macht bis mindestens 115200 Baud mit-wieso rödelst du in nem zeitkritischen Programm dann mit 9600 rum?
    Und zeitkritisch ist es, da der run()-Aufruf so oft wie möglich benutzt werden sollte. Diese Verrenkung (sowas löst man normal über nen Timer) wurde nur gemacht, um keinen Timer zu belegen. Aber besser wirds davon dann nich, im Gegenteil: _das_ kann nur funktionieren, wenn du das Programm wirklich schnell laufen lässt.
    Hm, eventuell könnte man da nachbessern: die Timer-Bibliothek benutzen, um sicher zu stellen, dass run() zyklisch aufgerufen wird.

    Kannst auch die Gegenprobe machen: bau mal in die Hauptschleife ein delay() ein, und schau, bis zu welcher Verzögerung es _noch_ funktioniert.
    Dann weisst du auch, wie schnell die Hauptschleife abgearbeitet werden muss.
    Wenn es _gar_ nicht geht, überleg dir eine andere Strategie:
    Beispielsweise ist es recht unsinnig, andauernd "ok" zu senden. Viel Zeit kannst du sparen, wenn du, wenns läuft, gar nix sendest, und nur, wenn irgendwas _nicht_ klappt, ne Debug-Meldung schickst.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  9. #9
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2013
    Beiträge
    235
    Hallo,

    wenn ich im Gerätemanager und im Serial.begin -Befehl auf 19200 stelle, klappt das Hochladen immer sofort.
    Bei meinem Stepperprogramm läuf das Programm selber aber nicht mehr. Auch nicht nach Arduino - und PC Neustart.

    Mit dem Blinkprogramm läuft zwar das Programm (PIN 13 blinkt), aber wenn ich mir den PIN im Seriellen Monitor ansehe,
    erscheint dort statt einer 0 ein :ø (Dopppelpunkt mit Durchschnittszeichen) und für eine 1 ein Quadrat mit einem
    seltsamen kleinen b und p übereinander geschrieben.

    Also was stimmt da nicht?

    Gruß

    fredyxx

    - - - Aktualisiert - - -

    Zitat Zitat von Rabenauge Beitrag anzeigen
    So schnell es geht?
    Kannst auch die Gegenprobe machen: bau mal in die Hauptschleife ein delay() ein, und schau, bis zu welcher Verzögerung es _noch_ funktioniert.
    Dann weisst du auch, wie schnell die Hauptschleife abgearbeitet werden muss.
    Wenn es _gar_ nicht geht, überleg dir eine andere Strategie:
    Beispielsweise ist es recht unsinnig, andauernd "ok" zu senden. Viel Zeit kannst du sparen, wenn du, wenns läuft, gar nix sendest, und nur, wenn irgendwas _nicht_ klappt, ne Debug-Meldung schickst.
    Klappt auch bei einer Mikrosekunde und 9600 nicht mehr.
    i.O. bei 57600 bis 700 Mikro, aber im Monitor erscheinen die falschen Zeichen
    i.O. bei 128000 bis 1400 Mikro darüber wird der Stepper lauter, aber im Monitor erscheinen die falschen Zeichen

    dein 2. Satz ist wohl der richtige Tipp. Wo kann ich was über die Debug-Meldung finden?

    Gruß
    fredyxx

  10. #10
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    49
    Beiträge
    1.245
    Du weisst schon, dass du in der Konsole die richtige Baudrate auch einstellen musst?
    Unten, rechts glaub ich...
    Und bitte: nimm nicht irgendwelche frei erfundenen Geschwindigkeiten (obwohl das theoretisch auch funktionieren sollte), schau unten in der seriellen Konsole, welche voreingestellten es gibt, die sollten auch wirklich gehn).
    Den Test mit dem delay() meinte ich natürlich so, dass du die serielle ausgabe weg lässt dabei, sonst hast du ja zwei Verzögerungen (das delay() und die Ausgabe).

    Ne Debug-Meldung, die schon fertig ist, wird es nich geben, die musst du dir schon selbst machen.
    Beispielsweise so:

    if(alles läuft)
    {
    debug=0;
    }
    if(debug != 0)
    {
    serial.println("wir haben Probleme!");
    debug=1;

    So wird immer dann ne Meldung abgeschickt, wenn allesLäuft false liefert, ansonsten einfach- nichts.
    Geändert von Rabenauge (03.05.2016 um 08:28 Uhr)
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. Servomotor blockiert - was geschieht?
    Von robkpc im Forum Motoren
    Antworten: 11
    Letzter Beitrag: 18.03.2014, 21:43
  2. Schrittmotor brummt und blockiert
    Von frankensteins-freund im Forum Motoren
    Antworten: 16
    Letzter Beitrag: 07.03.2012, 20:23
  3. Schrittmotor zuckt und blockiert
    Von chaosmaker im Forum Motoren
    Antworten: 6
    Letzter Beitrag: 29.05.2007, 13:34
  4. Fusing blockiert Avr !!!!!
    Von samba971 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 12
    Letzter Beitrag: 10.09.2005, 01:15
  5. Stepper-Endstufe "Econo Stepper Motor Driver"
    Von KüSä im Forum Motoren
    Antworten: 0
    Letzter Beitrag: 04.10.2004, 16:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •