Optischer Geschwindigkeitssensor

Zuviel Werbung?
-> Hier kostenlos registrieren
Die steigende Flanke des GPIO-Signals sieht schon richtig gut aus!
Bitte zum Vergleich doch nochmal das gleiche mit dem ursprünglichen R3 = 3,3 kΩ! Nochmals sorry - ich war wohl etwas zu voreilig mit meiner Unzufriedenheit bezüglich der ursprünglichen Werte von R3 und R4 :oops:.

Schon erledigt [emoji6] hab meine Antwort vorher nochmal bearbeitet.
 
Wird immer besser, habe ich den Eindruck!
Vielleicht noch ein Bisschen mehr für den R3. Hast Du 3,9 kΩ oder 4,7 kΩ zur Verfügung?
So langsam nerve ich Dich sicherlich ;) !
Wie sieht es denn mittlerweile mit der Auswirkung auf zu viel gezählte Impulse aus? Ist da denn auch ein (hoffentlich positiver) Unterschied zu bemerken?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ne nervt nicht, bin ja froh um Deine Hilfe!

Also so ne richtig positive Veränderung kann ich leider nicht feststellen. Werden mal mehr mal weniger zusätzliche Impulse erfasst. Stabil würde ich das noch nicht nennen...

Ich hab nochmal mit den Werten von R3 und R4 rumgespielt und da ist mir aufgefallen, dass es besser funktioniert, wenn R3 = 3,3 kOhm und R4 = 4,7 kOhm

Dann bin ich mit R4 noch weiter runter gegangen und bei 2,2 kOhm tut sich gar nichts mehr. Also irgendwas dazwischen... Der Hebel zwischen ganz ok und schlecht ist halt auch sehr klein und unsicher... ein bisschen zu hoch oder zu niedrig und es passt wieder nicht...

Denkst du, dass es besser wäre mit dem Opto-Koppler?
 
Denkst du, dass es besser wäre mit dem Opto-Koppler?
Das dachte ich zeitweise tatsächlich, aber weil wir dann nicht so viele Möglichkeiten haben, dran herum zu probieren. ;)

Da wir aber schon am Probieren sind ...
Frier jetzt bitte mal die Änderungen an R3 und R4 ein und versuch bitte mal R2 von 150 Ω zu verkleinern auf 68 Ω (notfalls Dein 47 Ω, aber möglichst nicht noch kleiner, sondern lieber 56 Ω).
Dann mach bitte noch mal ein Video und informier mich bitte, welche Werte R3 und R4 haben.
 
Das dachte ich zeitweise tatsächlich, aber weil wir dann nicht so viele Möglichkeiten haben, dran herum zu probieren. ;)

Ok, dann probieren wir mal noch weiter :D

Da wir aber schon am Probieren sind ...
Frier jetzt bitte mal die Änderungen an R3 und R4 ein und versuch bitte mal R2 von 150 Ω zu verkleinern auf 68 Ω (notfalls Dein 47 Ω, aber möglichst nicht noch kleiner, sondern lieber 56 Ω).
Dann mach bitte noch mal ein Video und informier mich bitte, welche Werte R3 und R4 haben.


Die Werte sind jetzt die folgenden:

R1 = 330 Ohm
R2 = 57 Ohm
R3 = 2,2 kOhm
R4 = 4,7 kOhm

Was halt schon auffällt ist, dass die Vibrationen immer 2-4 Impulse extra ausmachen. Von Hand funktioniert es mit dem Aufbau schon ganz gut...

Langsam
https://www.dropbox.com/s/vnqauv8mf4y2z68/Test3_Langsam.mov?dl=0

Schnell
https://www.dropbox.com/s/m6waxvm7j0fpit9/Test3_Schnell.mov?dl=0
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was halt schon auffällt ist, dass die Vibrationen immer 2-4 Impulse extra ausmachen. Von Hand funktioniert es mit dem Aufbau schon ganz gut...
Habe ich nicht ganz verstanden ... sind das jetzt weniger StörImpulse, als vorher? Das, was ich als mögliche Folgen der Vibrationen zu sehen glaubte (diese Stufen und Nasen im GPIO-Signal) sehe ich zumindest nicht mehr.
Mach mal bitte den R3 grösser, also 3,3 kΩ
 
Habe ich nicht ganz verstanden ... sind das jetzt weniger StörImpulse, als vorher? Das, was ich als mögliche Folgen der Vibrationen zu sehen glaubte (diese Stufen und Nasen im GPIO-Signal) sehe ich zumindest nicht mehr.
Mach mal bitte den R3 grösser, also 3,3 kΩ

Nein, die Störimpulse haben sich nicht merklich verändert.

Der R3 ist jetzt wieder bei 3,3 kOhm.

Was mir noch aufgefallen ist und was ich mir durchaus als Fehlerquelle für das unruhige Verhalten des Motors vorstellen kann ist folgendes:

Die Steuerspannung ist unbelastet ziemlich stabil laut Oszilloskop. Sobald ich aber den Motor einschalte und Strom verbraucht wird, wird die Steuerspannung unruhig. Das könnte doch die Ursache für die unstetige Drehzahl sein und dadurch eventuell auch für die übermäßigen Vibrationen.

Was ich noch in einem Blogeintrag gelesen habe, ist das:

"Da der Ausgang des DAC MCP4725 strommäßig kaum belastbar ist (1 - 3 mA), habe ich dem DAC-Ausgang einen Operationsverstärker LM358 als Spannungsfolger (Impedanzwandler) nachgeschaltet. Dieser hat als Ausgangsspannung dieselbe Spannung wie der DAC, allerdings kann er strommäßig etwas höher, mit ca. 20 - 35 mA, abhängig von der Höhe der DAC-Spannung belastet werden, ohne das die Ausgangsspannung merkbar einbricht."

Quelle: https://arduino-projekte.webnode.at/meine-libraries/dac-mcp4725/

Gibt es auch noch eine andere Möglichkeit, die Steuerspannung zu stabilisieren, als mit einem Operationsverstärker?

---

Hier mal ein Video der Impulse und der Steuerspannung:
https://www.dropbox.com/s/dt5zds3wbxorb9z/Test4_GPIO-AusgangUndSteuerspannung.mov?dl=0
 
Die Steuerspannung ist unbelastet ziemlich stabil laut Oszilloskop. Sobald ich aber den Motor einschalte und Strom verbraucht wird, wird die Steuerspannung unruhig. Das könnte doch die Ursache für die unstetige Drehzahl sein und dadurch eventuell auch für die übermäßigen Vibrationen.
Gibt es auch noch eine andere Möglichkeit, die Steuerspannung zu stabilisieren, als mit einem Operationsverstärker?
Versuch mal mit einem Kondensator (1 nF?) an Eingang der MotorElektronik gegen Masse alias GND.
Das sollte die Spannung glätten. Stabilisieren ist hier der falsche Begriff.
Wie sieht es denn am Oszi aus, wenn Du nur die Steuerspannung anzeigst, also am Oszi die nicht benötigte(n) Leitung(en) entfernst? Könnte ja sein, dass Du Dir darüber etwas einfängst, was Dein Oszi einfach der SteuerspannungsAnzeige hinzuaddiert (ich gehe mal davon aus, dass Du für die LS-Mimik eigentlich nicht denselben MassePunkt zum Oszillospieren benötigst, wie für die Steuerspannung).
Von wo speist Du die SteuerSpannung? Vom RasPi?
Wie ist die räumliche Anordnung der MotorElektronik? Vermutlich in der Nähe des Motors? Und der RasPi weit weg?
Die diversen Leitungen zwischen Netzteil, MotorElektronik, LS-Mimik, RasPi, ... möglichst nicht fein säuberlich alle zusammenbündeln, nur damit's schön aussieht.
Wenigstens zu Anfang auch räumlich trennen und ggfs erst später wieder "vereinigen" und dabei beobachten, ob die Störungen wieder zunehmen.
Abgeschirmte Leitungen?
Wie schaut's mit einem aktuellen Video "langsam mit GPIO-Signal und Spannung am C vom PNP"?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Versuch mal mit einem Kondensator (1 nF?) an Eingang der MotorElektronik gegen Masse alias GND.
Das sollte die Spannung glätten. Stabilisieren ist hier der falsche Begriff.

Ok, dann glätten. Das mein ich auf jeden Fall mit stabilisieren.
Ich hab leider keinen 1nF Kondensator hier. Der kleinste, den ich hab ist ein 0,1µF, also 100nF

Wie sieht es denn am Oszi aus, wenn Du nur die Steuerspannung anzeigst, also am Oszi die nicht benötigte(n) Leitung(en) entfernst? Könnte ja sein, dass Du Dir darüber etwas einfängst, was Dein Oszi einfach der SteuerspannungsAnzeige hinzuaddiert (ich gehe mal davon aus, dass Du für die LS-Mimik eigentlich nicht denselben MassePunkt zum Oszillospieren benötigst, wie für die Steuerspannung).

Das hab ich schon geprüft. Das selbe, wenn ich nur die Steuerspannung anzeigen lasse.

Von wo speist Du die SteuerSpannung? Vom RasPi?

Ja, die Steuerspannung kommt von einem D/A-Wandler, welcher über i2c vom Pi gesteuert wird.

Wie ist die räumliche Anordnung der MotorElektronik? Vermutlich in der Nähe des Motors? Und der RasPi weit weg?
Die diversen Leitungen zwischen Netzteil, MotorElektronik, LS-Mimik, RasPi, ... möglichst nicht fein säuberlich alle zusammenbündeln, nur damit's schön aussieht.
Wenigstens zu Anfang auch räumlich trennen und ggfs erst später wieder "vereinigen" und dabei beobachten, ob die Störungen wieder zunehmen.

Der Treiber ist zumindest direkt am Motor befestigt. Das wird vom Hersteller direkt so geliefert. Der Pi liegt etwa einen halben Meter vom Motor entfernt. Die Kabel für die Motorspannung, Steuerspannung, Lichtschranke usw. hab ich natürlich nicht alle gebündelt, sondern liegen jeweils einzeln.

Abgeschirmte Leitungen?

Hab ich noch nicht, sind aber bestellt und werden dann spätestens im Produktionsbetrieb auch eingesetzt.

Wie schaut's mit einem aktuellen Video "langsam mit GPIO-Signal und Spannung am C vom PNP"?

https://www.dropbox.com/s/gzwi11nprieu397/Test5_Langsam.mov?dl=0
 
Die Dimensionierung der Widerstände würde ich jetzt so "absegnen". An der steigenden wie an der fallenden Flanke des GPIO-Signals wird der SpannungsBereich 0,8 V ... 1,3 V zügig durchlaufen.
Ist zwar recht knapp, aber wenn wir den Bereich jetzt noch hin- und herschieben, wird's an der einen Flanke besser und an der anderen dafür schlechter.

Falls Du doch noch ca. 1 nF Kondensatoren in die Finger kriegst, kannst Du ja mal probieren, ob mit einem zwischen B und C des PNP sich das Verhalten noch etwas verbessern lässt.

Da Du schon das Thema des recht hochohmigen DAC-Ausgangs angeschnitten hast, würde ich den nicht so gerne mit so viel wie 100 nF belasten. Hast Du ein DatenBlatt des DAC und sagt das etwas über kapazitve Belastung aus?
Die oszilloskopierten SpannungsSpitzen sind ja z.T. gar nicht sooo klein, dass man einfach darüber hinweg gehen möchte. Aber sind sie auch lang genug, um die MotorElektronik zu störenden Vibrationen des Motors zu bewegen? Zuviel Glättung kann auch dazu führen, dass die Spitzen zwar in der Amplitude abgeschwächt werden, aber die zunehmende Länge der Impulse noch ernsthaftere Probleme schafft.
 
Hallo Zusammen,

ist schon wieder viel Zeit vergangen seit dem letzten Beitrag...

Ich hab jetzt alle Bauteile zusammen und auch noch ein Labornetzteil, dass ich mal testen konnte, ob das unruhige Verhalten des Motors eventuell durch den DAC kommt - aber nein, es hat nichts damit zu tun. Ich hab auch mal das Labornetzteil als 24V Versorgung für den Motor selbst genommen, aber auch damit das selbe Ergebnis.

Die 1nF Kondensatoren hab ich jetzt auch da und versucht die Spannung zu glätten - keine Besserung.

Auch hab ich versucht einen 1 nF Kondensator, wie du, Heinileini, gesagt hast, zwischen B und C des PNP zu schalten - leider auch keine Verbesserung festzustellen.

Als nächstes hab ich mich dann mal mit dem ATTiny85 vertraut gemacht und hab es geschafft, mit dem Arduino Uno als Programmer eine LED blinken zu lassen - WOW!

Dann hab ich nach einem möglichst fertigen Code für eine Flanken-Erkennung gesucht und gefunden.

Und es funktioniert tatsächlich sehr gut mit der Erkennung und das ganz ohne die Transistor-Schaltung. Ich hab einfach den Fototransistor als Eingang am ATTiny85 verwendet und eine LED soll dann angehen, sobald 10 Impulse erkannt wurden.

Das funktioniert gut, wenn ich von Hand drehe und auch im langsamen Modus bei 0V Steuerspannung. Scheint die Impulse wirklich zuverlässig zu erkennen!

Da der ATTiny85 für mich absolutes Neuland ist, verstehe ich den Code leider nicht 100 Prozentig und auch nicht, wieso die LED beim Starten des Programms an ist und beim Erreichen der 10 Impulse ausgeht, statt an... aber wenigstens werden die Impulse mal richtig erkannt.

Jetzt hab ich noch ein Code im Internet gefunden, der den ATTiny85 mit Hilfe der Bibliothek "TinyWireS" zum i2c slave macht. Damit hab ich auch etwas experimentiert. Im ersten Schritt hab ich einfach nur mal dem ATTiny85 eine i2c Adresse zugewiesen, um ihn mit dem Raspberry Pi über den Befehl "i2cdetect -y 1" zu erkennen. Leider wird nichts erkannt.

UPDATE!
Gerade eben hab ich was von Leitungslänge bei i2c gelesen und hab es direkt mal mit einer ganz kurzen Verbindung probiert und der ATTiny85 wird erkannt!! Adresse 0x4 genau wie konfiguriert und der DAC wird weiterhin als 0x60 erkannt. 1A. Dann teste ich jetzt mal noch weiter und melde mich wieder...



@Thomas_v2.1

Du scheinst dich ja gut mit dem ATTiny85 auszukennen. Kannst du mir eventuell etwas auf die Sprünge helfen, wie ich die Verbindung zwischen ATTiny85 und dem Raspberry Pi über i2c realisieren kann, dass ich einen Integer-Wert vom RPi an den ATTiny85 senden kann?

Ich bin an der Stelle noch unsicher, ob ich einfach einen Digitalen Ausgang am ATTiny85 setzen soll, sobald die Anzahl Impulse erreicht wurde, oder ob das vielleicht auch über i2c funktioniert.

Gibt es irgendwelche Unterschiede zwischen den i2c-Bibliotheken, sodass eine Verbindung nicht mit beliebigen Bibliotheken möglich ist? So wie ich es verstehe, ist das i2c Protokoll doch ein Standard und die Bibliotheken sind nur "Wrapper", um die Benutzung zu vereinfachen. Also sollte doch die Verbindung funktionieren, oder?


Vielen Dank auf jeden Fall an Euch beide!


Hier mal noch die beiden Programme, welche ich jeweils auf die ATTiny85 ausgespielt hab:

Für die Flankenerkennung:

Code:
// ATMEL ATTINY 25/45/85 / ARDUINO
// Pin 1 is /RESET
//
//                  +-\/-+
// Ain0 (D 5) PB5  1|    |8  Vcc
// Ain3 (D 3) PB3  2|    |7  PB2 (D 2) Ain1
// Ain2 (D 4) PB4  3|    |6  PB1 (D 1) pwm1
//            GND  4|    |5  PB0 (D 0) pwm0
//                  +----+


/*


  Pin 7  <-- switch to Gnd


  Pin 5 (PB0) <---- LED ---> 330 R <-----> Gnd
  
*/




#include <avr/sleep.h>    // Sleep Modes
#include <avr/power.h>    // Power management


const byte LED = 0;          // pin 5 (D0)
const byte SW = 2;           // pin 7 (D2)
const byte LED_DEBUG = 4;


volatile unsigned long count = 0;
 
ISR (INT0_vect)
{
  GIMSK &= ~bit(INT0);     // disable INT0
}


void setup ()
{
  pinMode (LED, OUTPUT);
  pinMode (LED_DEBUG, OUTPUT);
  pinMode (SW, INPUT);
  digitalWrite (SW, HIGH);  // input pull-up
  ADCSRA = 0;            // turn off ADC
  MCUCR &= ~(bit(ISC01) | bit(ISC00));    // INT0 on low level
}  // end of setup


void loop ()
{


  power_timer0_enable ();
  delay (100);  // let timer reach a known point
  digitalWrite (LED, HIGH);
  delay (20);
  digitalWrite (LED, LOW);
  count++;          // Zähler hochzählen, sobald eine Flanke erkannt wurde
  if (count == 10)  // Wenn Zähler == 10 ...
  {
    digitalWrite (LED_DEBUG, HIGH); // ... dann die LED einschalten (In der Realität geht die LED an diesem Punkt aus und ist von Anfang an eingeschaltet)
  }
  power_timer0_disable ();


  while (digitalRead (SW) == LOW)
    { }  // wait for switch to be released


  noInterrupts ();
  GIFR  = bit (INTF0);   // clear interrupt flag
  GIMSK = bit (INT0);    // enable INT0
    
  power_all_disable ();  // power off ADC, Timer 0 and 1, serial interface
  set_sleep_mode (SLEEP_MODE_PWR_DOWN);
  sleep_enable ();       // ready to sleep
  interrupts ();
  sleep_cpu ();          // sleep                
  sleep_disable ();      // precaution


}  // end of loop

Für die i2c Kommunikation:

Code:
// ATMEL ATtiny45/85
//
//                  +-\/-+
//          Reset  1|    |8  Vcc
// Ain3 (D 3) PB3  2|    |7  PB2 (D 2) Ain1 SCL
// Ain2 (D 4) PB4  3|    |6  PB1 (D 1) pwm1
//            GND  4|    |5  PB0 (D 0) pwm0 SDA
//                  +----+
// Code für Attiny85
// Sendet über I2c die Deltawerte des Encoders zwischen jeder Abfrage
// V 0.1


// Get this from https://github.com/rambo/TinyWire
#include <util/atomic.h>
#define CriticalSection  ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
#include <TinyWireS.h>                           // Bezieht I2c Bibliothek ein
#include "avr/interrupt.h";                      // Bezieht AVR Interrupt Bibliothek ein
#define I2C_SLAVE_ADDRESS 0x4                    // I2c Slave Adresse


volatile byte counter = 100;                     // Encoder Zähler


void setup() {
  TinyWireS.onRequest(requestEvent);             // Bei I2c Anfrage springt in requestEvent Funktion
  TinyWireS.begin(I2C_SLAVE_ADDRESS);            // Verbindet mit I2c Bus
}


void loop() {


}


void requestEvent() {
  TinyWireS.send(counter);                       // Sendet I2c Nachricht
}
 
Zuletzt bearbeitet:
Zurück
Oben