next topic »

[Reply #30 on:]

Die abfrage des PIN registers ist leider kein erstatz fuer den interrupt. Sie ist ein ersatz fuer die funktion 'digitalRead()', welche im hintergrund etwas mehr arbeit verrichtet (pruefen auf valide pins, PWM abschalten falls noetig...) und daher mehr zeit verbrennt, als im interrupt erwuenscht oder tolerabel.

Die millis funktion als solche ist eigentlich schon minmal kurz (13 cycles). Dazu kommen noch mindestens 12 cycles fuer das aufrufen und speichern des ergebnisses (4 bytes). Der interrupt kostet auch noch etwas overhead. In summe duerfte der zeitverbrauch irgendwo im einstelligen µs bereich liegen, folglich darf der encoder nicht mehr pulse liefern.

AVR assembler befehls referenz: www.atmel.com/atmel/acrobat/doc0856.pdf

Code:

0000015e <millis>:
 15e:   8f b7           in      r24, 0x3f       ; 63
 160:   f8 94           cli
 162:   20 91 04 01     lds     r18, 0x0104  // 4 bytes fuer den timestamp
 166:   30 91 05 01     lds     r19, 0x0105
 16a:   40 91 06 01     lds     r20, 0x0106
 16e:   50 91 07 01     lds     r21, 0x0107
 172:   8f bf           out     0x3f, r24       ; 63
 174:   b9 01           movw    r22, r18
 176:   ca 01           movw    r24, r20
 178:   08 95           ret

Den assembler source code kann man sich mit

avr-objdump -D -S sourcefile.cpp.elf > assembler.txt

generieren lassen, wobei das '-S' dafuer sorgt, dass zur besseren verstaendlichkeit C-code hineingemischt wird. Unter windoof duerfte das im prinzip auch funktionieren, falls die system pfad variable auf den bin-folder im arduino ordner gesetzt ist. Vermutlich ist das sowas wie "c:\BLAH\arduino-0022\hardware\tools\avr\bin\". Das build-verzeichnis ist in "c:\Dokumente...\...\local settings\temp\buildxxxx" zu finden.

[Reply #31 on:]

Was mir gerade aufgefallen ist, ist deine inkorrekte deklaration von T1 und T2 !!

ABSOLUT ALLE variablen, welche durch einen interrupt geaendert werden, M U E S S EN als volatile deklariert sein. Sonst gibt es murks, weil der compiler sie evtl. sonst durch register zwischenspeichert. Im normalfall laeuft das programm fuer den compiler absolut deterministisch ab, d.h. er kann vorhersehen, welche variablen wo stehen und wann sie geaendert werden. Es macht daher sinn, sie in den registern auf vorrat zu halten. Ein interrupt tritt aus sicht des compilers zu voellig unvorhersehbaren zeitpunkten wie ein blitzschlag ein, daher muss das puffern der variablen in registern expilzit verboten werden. Falls nicht, verwendet dein code nur die zwischengespeicherten werte, der interrupt schreibt jedoch in die 'wahre' variable hinein.

Folglich:

Code:

volatile unsigned long T1;
volatile unsigned long T2;

[Reply #32 on:]

Hallo madworm,
ich habe jetzt Deine Anregungen übernommen (s.u.), so lange ich die Drehzahl nicht über 80RPM drehen lasse funktioniert der Code. So richtig befriedigend ist das natürlich nicht. Könnte man die Drehgeschwindigkeit mittels eines Differenzen Quotienten besser ermitteln?  Mann könnte versuchen alle 10-50 msec einen Diferenzenquotienten zu berechnen. Ein so geglättetes Signal wiederspricht zwar meiner Forderung nach Synchronität zweier Bewegungen aber was meint Ihr ist das eine bessere Idee?

/*
 Drehachsensteuerung
 
 */
int i;                     // Getriebeübersetzung
int s;                     // Sinunsfunktion
int PD2 = 2;
int R = 13;                // Rechteckausgang
int Dir = 9;                // Rechteckausgang
int En = 8;                // Rechteckausgang
double w;                  // Omega
float Speed;               // Spindeldrehzahl
volatile unsigned long T1;          //Zeitstepel 1
volatile unsigned long T2;          //Zeitstepel 2

// Encoder Interruptports
#define A 2      //Belegung der Encoderkanale A

void setup() {
  i=40;
  pinMode(R,OUTPUT);
  pinMode(En,OUTPUT);   //Enable Pin
  pinMode(Dir,OUTPUT);   //Direction Pin

  Serial.begin(9600);  // initialize the serial port:

  attachInterrupt(0,CHAInt, RISING);               // Interrupt 0 führt CHAInt aus mit steigender Flanken
  pinMode(PD2,INPUT);                               // Pin2 als Input
  digitalWrite(PD2,HIGH);                            // Interne Pull Ups benutzt
}

void loop() {

  Speed= 1000/(T2-T1);                  //Spindeldrehzahl
  //Serial.println(Speed);
  Serial.println(Speed); 
  // Rechtecksignal
  w= (Speed*36*4)/(16*200*i);
  s=5*sin(w*millis()*1000);
  if (s<0){
    digitalWrite (R, LOW);
  }
  if (s>0){
    digitalWrite (R, HIGH);
  }
  digitalWrite(En, LOW);               // Enable Pololu
  digitalWrite(Dir, LOW);               // Direktion Pololu
}
void CHAInt ()
{
  if( PIND & _BV(PD2) )
  {
    T1 = T2;
    T2 = millis();
  }
}

[Reply #33 on:]

So recht einleuchten will es mir nicht, dass bei ca. 100Hz ende sein soll.

Wenn du einen osci hasst, dann lass doch mal im interrupt eine LED blinken und schaue dir sowohl das encoder signal und das led signal an. Wenn der interrupt zu lange dauern sollte, dann muesste es im signal eine deutliche abweichung geben. Am besten zu beginn des interrupts die led an, am ende aus. Das gibt auch eine grobe abschaetzung, wie lange er braucht.

In dem zusammenhang bietet sich auch ein logik analysator an ;-)

Ich verwende den von dangerousprototypes.com (ca. 50€), den gibt's z.b. bei watterott.

[Reply #34 on:]

Evtl. liegt das problem hier:

Code:

Speed = 1000/(T2-T1);                  //Spindeldrehzahl

Wenn der interrupt waehrend der differenzbildung feuert, dann verfaelscht er z.b. T1 (setzt es zum alten T2). Das wuerde auch zu den viel zu grossen werten passen, da eine kleine differenz im nenner... usw.

Probiere mal:

Code:

cli(); // alle interrupts aus
unsigned long T1_temp = T1; // werte kopieren
unsigned long T2_temp = T2;
sei(); // interrupts wieder an

Speed = 1000 / (T2_temp - T1_temp);

So erfolt die speed berechnung immer mit sauberen werten.

[Reply #35 on:]

Hallo Leute,
ich habe jetzt den Vorschlag von madworm ausprobiert. Durch das zeitweise abschalten der Interrupts bringt man das Program bereits bei kleinen Geschwindigkeiten 80RPM aus dem Tritt, das entspricht 21,3Hz.

Ich habe jetzt von millis() auf micros() umgestellt, damit komme ich auf eine messbare Drehzahl von 90RPM.

Ist es möglich ein Unterprogramm mit deterministischer Laufzeit laufen zu lasse, dann könnte man die Position erfassen und durch die Laufzeit teilen.

Vielen Dank für Eure Unterstützung
DrFlopp

[Reply #36 on:]

Der interrupt ist mehr oder weniger deterministisch. Auf jedenfall im vergleich zu einem 21Hz signal. Er kommt dann, wenn er getriggert wird. Spaetestens nachdem ein anderer laufender interrupt abgearbeitet worden ist, also etwas spaeter als gedacht. In deinem fall soltle das dann 2 identische speed werte liefern. Ist dein encoder signal deterministisch?  

Mir faellt es sehr schwer zu glauben, dass ein 16MHz microcontroller nicht in der lage sein sollte ein quasi DC signal von 21Hz zu verarbeiten. Das sind von flanke zu flanke ca. 24ms, oder in anderen worten 384000 clock cycles, also eine halbe ewigkeit.

Wenn schon das kurzzeitige abschalten (µs bereich) der interrupts dein ergebnis bei so niedrigen zaehlraten significant veraendert... wie wahrscheinlich ist es, dass immer gerade dann, wenn der interrupt kaeme dieser abgeschaltet ist? Das will mir nicht einleuchten.

Wenn ein verwenden von micros() im vergleich zu millis() eine verbesserung bringt, dann kann das 2 gruende haben:

a) micros() ist schneller abgearbeitet als millis()
b) die zeitaufloesung von millis() is zu grob

zu a):

Code:

00000160 <millis>:
 160:   8f b7           in      r24, 0x3f       ; 63
 162:   f8 94           cli
 164:   20 91 04 01     lds     r18, 0x0104
 168:   30 91 05 01     lds     r19, 0x0105
 16c:   40 91 06 01     lds     r20, 0x0106
 170:   50 91 07 01     lds     r21, 0x0107
 174:   8f bf           out     0x3f, r24       ; 63
 176:   b9 01           movw    r22, r18
 178:   ca 01           movw    r24, r20
 17a:   08 95           ret

0000017c <micros>:
 17c:   9f b7           in      r25, 0x3f       ; 63
 17e:   f8 94           cli
 180:   20 91 00 01     lds     r18, 0x0100
 184:   30 91 01 01     lds     r19, 0x0101
 188:   40 91 02 01     lds     r20, 0x0102
 18c:   50 91 03 01     lds     r21, 0x0103
 190:   86 b5           in      r24, 0x26       ; 38
 192:   a8 9b           sbis    0x15, 0 ; 21
 194:   06 c0           rjmp    .+12            ; 0x1a2 <micros+0x26>
 196:   8f 3f           cpi     r24, 0xFF       ; 255
 198:   21 f0           breq    .+8             ; 0x1a2 <micros+0x26>
 19a:   2f 5f           subi    r18, 0xFF       ; 255
 19c:   3f 4f           sbci    r19, 0xFF       ; 255
 19e:   4f 4f           sbci    r20, 0xFF       ; 255
 1a0:   5f 4f           sbci    r21, 0xFF       ; 255
 1a2:   9f bf           out     0x3f, r25       ; 63
 1a4:   54 2f           mov     r21, r20
 1a6:   43 2f           mov     r20, r19
 1a8:   32 2f           mov     r19, r18
 1aa:   22 27           eor     r18, r18
 1ac:   28 0f           add     r18, r24
 1ae:   31 1d           adc     r19, r1
 1b0:   41 1d           adc     r20, r1
 1b2:   51 1d           adc     r21, r1
 1b4:   82 e0           ldi     r24, 0x02       ; 2
 1b6:   22 0f           add     r18, r18
 1b8:   33 1f           adc     r19, r19
 1ba:   44 1f           adc     r20, r20
 1bc:   55 1f           adc     r21, r21
 1be:   8a 95           dec     r24
 1c0:   d1 f7           brne    .-12            ; 0x1b6 <micros+0x3a>
 1c2:   b9 01           movw    r22, r18
 1c4:   ca 01           movw    r24, r20
 1c6:   08 95           ret

Alleine das bloße abzaehlen der anzahl von opcodes macht klar, dass micros() im mittel nicht schneller abgearbeitet wird als millis(). Es bleibt also punkt b).

zu b):

ist die zeitaufloesung von millis() also ungenuegend, so heisst das doch auch, dass deine pulse viel viel schneller auftreten als nur mit 21Hz. Oder zumindest, dass der interrupt oefter feuert (dreckiges signal).


Bitte ueberpruefe:

a) ob dein encoder signal wirklich sauber ist (bounce free, keine oszillationen an den flanken)
b) Liefert der encoder kurze _pulse_ konstanter laenge pro tick, oder ein echtes rechtecksignal

c)

Bitte nutze einen I/O pin, setze diesen innerhalb und zu begin des interrupts und loesche ihn gegen ende wieder. Mit dem oszilloskop kann so _sehr leicht_ festgestellt werden, wie lange der interrupt benoetigt und v.a. wie oft er feuert im vergleich zum encoder signal. Das ist essenziell zu wissen, alles andere ist mehr oder weniger nur zeitverschwendung.

Screenshots vom osci waeren nett ;-)

d)

vielleicht lohnt es sich zu ueberpruefen, ob die serielle kommunikation stoerend ist. Ich habe mir bis jetzt nicht die muehe gemacht nachzusehen, ob das andere interrupts blockiert. Sollte das der fall sein, dann am besten von 9600 auf einen wesentlich hoeheren wert gehen.

[Reply #37 on:]

Der interrupt ist mehr oder weniger deterministisch. Auf jedenfall im vergleich zu einem 21Hz signal. Er kommt dann, wenn er getriggert wird. Spaetestens nachdem ein anderer laufender interrupt abgearbeitet worden ist, also etwas spaeter als gedacht. In deinem fall soltle das dann 2 identische speed werte liefern. Ist dein encoder signal deterministisch?  

Mir faellt es sehr schwer zu glauben, dass ein 16MHz microcontroller nicht in der lage sein sollte ein quasi DC signal von 21Hz zu verarbeiten. Das sind von flanke zu flanke ca. 24ms, oder in anderen worten 384000 clock cycles, also eine halbe ewigkeit.

Man verliert einen Interrupt während derZeit, in der die Interrupt deaktiviert sind. Falls in der Interruptroutine die Interrupt nicht deaktiviert sind arbeitet ein Interrupt der während des Durcharbeiten der Interruptroutine kommt die Interruptroutine von neuem ab, Das zu komischen reaktionen.
Ich teile Deiner Auffassung, daß ein 16MHz Arduino mit einem 21Hz Signal allemal zurechtkommen muß.
Viele grüße Uwe

[Reply #38 on:]

Hallo zusammen,
ich habe ebenfalls den Verdacht es liegt an der seriellen Schnittstelle, doch ich habe zur Zeit keine andere Anzeigemöglichkeit für die Drehgeschwindigkeit. Später kann ich darauf verzichten, doch zur Inbetriebnahme habe ich schlechte Karten.
Ich könnte mir auch vorstellen, dass die Float-Werte ein Problem darstellen. Ich werde mal versuchen auf die Periodendauer statt die Drehzahl zu gehen.
Das wird dann vielleicht besser.

[Reply #39 on:]

Hallo,
 mir fällt gerade noch auf, dass auch die Sinusfunktion ein Problem sein könnte. Ich benutze den Sinus ja nur als Hilfsgröße um ein Rechtecksignal zu erzeugen. Gibt es da vielleicht eine bessere Lösung?
Gruß
DrFlopp

[Reply #40 on:]

Hallo zusammen,
ich habe ebenfalls den Verdacht es liegt an der seriellen Schnittstelle, doch ich habe zur Zeit keine andere Anzeigemöglichkeit für die Drehgeschwindigkeit. Später kann ich darauf verzichten, doch zur Inbetriebnahme habe ich schlechte Karten.
Ich könnte mir auch vorstellen, dass die Float-Werte ein Problem darstellen. Ich werde mal versuchen auf die Periodendauer statt die Drehzahl zu gehen.
Das wird dann vielleicht besser.

Wenn die Seriele Schnittstelle das Nadelöhr ist dann erhöhe die Baudrate.
 
schreibe statt
Serial.begin(9600);  // initialize the serial port:

Serial.begin(115200);  // initialize the serial port:
und ändere den Wert auch im Terminal.

Eine Bautrate von 9600 verbraucht ca 1 mSek pro übertragenen Byte und bremst den Controller aus wie delay().


Grüße Uwe

[Reply #41 on:]

Ich habe das schon öfter probiert, scheinbar macht das mein PC nicht mit. Immer wenn ich einen schnellere Überttragugsrate ausprobiere kommt nur Schrott heraus.
Gruß
DrFlopp

[Reply #42 on:]

Hast Du den Wert unten rechts in Terminal des IDE auch geändert?

Grüße Uwe

[Reply #43 on:]

Also am serial port liegt es definitiv nicht, jedenfalls wenn man nicht auf dem selben board das trigger signal in loop() erzeugt. Ich habe gerade mit 2 arduinos herumprobiert.

Ich schicke ein 5kHz signal auf den interrupt pin (digital2) und verwende die micros() funktion fuer gute zeitaufloesung.

Da ich mal davon ausgehe, dass du keine HF spindel hast, nehme ich von nun an 1kHz als signal, was bei 16 pulsen per revolution ca. 3750 rpm entspricht.

micros() hat eine granularitaet von 4µs, was hier ca. +- 10rpm entspricht. Daher macht speed als float-variable keinen sinn.

Hier der code fuer den frequenz generator:

void setup() {
  // put your setup code here, to run once:
  DDRD |= _BV(PD2);
}

void loop() {
  // put your main code here, to run repeatedly:
  //delayMicroseconds(500); // fuer hohe RPM
  delay(10); // fuer niedrige RPM
  PORTD &= ~_BV(PD2); // low
  //delayMicroseconds(500);
  delay(10);
  PORTD |= _BV(PD2); // high  
}

und dein code in etwas veraenderter/verkuerzter form:

int i;                     // Getriebeübersetzung
int s;                     // Sinunsfunktion

////
int R = 12;                // Rechteckausgang
////

int Dir = 9;                // Rechteckausgang
int En = 8;                // Rechteckausgang
double w;                  // Omega

////
unsigned int RPM;        // Spindeldrehzahl pro minute
#define PPR 16UL         // pulse per revolution
////

volatile unsigned long T1;          //Zeitstepel 1
volatile unsigned long T2;          //Zeitstepel 2

// Encoder Interruptports
#define A 2      //Belegung der Encoderkanale A

void setup() {
  i=40;
  pinMode(R,OUTPUT);
  pinMode(En,OUTPUT);   //Enable Pin
  pinMode(Dir,OUTPUT);   //Direction Pin
  pinMode(13,OUTPUT); // fuer diagnose LED

  Serial.begin(9600);  // initialize the serial port:

  attachInterrupt(0,CHAInt, RISING);               // Interrupt 0 führt CHAInt aus mit steigender Flanken
  pinMode(A,INPUT);                               // Pin2 als Input
  digitalWrite(A,HIGH);                            // Interne Pull Ups benutzt
}

void loop() {
  cli();
  unsigned long T1_temp = T1; // in microsekunden
  unsigned long T2_temp = T2;
  sei();

  unsigned long DELTA = T2 - T1;
  
  RPM = (unsigned int)( 1000000UL * 60UL / ( PPR * DELTA ) );
  
  Serial.print("rpm: ");
  Serial.println(RPM);
  Serial.print("delta T in microsekunden: ");
  Serial.println(DELTA);
}

void CHAInt ()
{
  // PORTB |= _BV(PB5); // L-LED (13) an
  if( PIND & _BV(PD2) )
  {
    T1 = T2;
    T2 = micros();
  }
  // PORTB &= ~_BV(PB5); //L-LED (13) aus
}

Das funktioniert wunderbar, wohlgemerkt mit 2 boards. Beides auf einem laufen zu lassen ist verboten. Sollte der sinn deiner 'sinus' funktion darin bestehen auf dem selben board das rechtecksignal zu erzeugen, welches dann wiederum den interrupt triggert... autsch!

[Reply #44 on:]

Das Ziel des Projektes ist es, eine Drehachse mit der Spindel synchron zu bewegen, das ist wichtig um damit schrägverzahnte Zahnräder fräsen zu können. Das Rechtecksignal benötige ich um einen Schrittmotor anzusteuern der den Rundtisch bewegt. Ich trigger also nicht den Inerrupt sonder den Stepp-Pin für den Stepperdriver.

@ madworm:
Vielen Dank für Deinen Code, ich habe natürlich einpaar Anfängerfragen. Ist es besser die Rechnung in einer Formel auszudrücken oder in zwei Formeln:

"unsigned long DELTA = T2 - T1;
 RPM = (unsigned int)( 1000000UL * 60UL / ( PPR * DELTA ) );"

Wann benutzt man eine Variablendeklaration in der Loop und warum? Ich habe das bei den Experten schon so oft gesehen, dass ich glaube das muss Vorteile bringen.
 
Was bedeutet das UL (#define PPR 16UL, 1000000UL * 60UL)?

Viele Grüße
DrFlopp