- LiFePO4 Speicher Test         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 18 von 18

Thema: Quellcode für Geschwindigkeitsmessung

  1. #11
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    Anzeige

    LiFePo4 Akku selber bauen - Video
    wieso denn oder-verschaltung ? die haben soch nur einen schliesser wenn cih mich nicht irre, dann reicht es wenn ich den internen pullup anmach und dann nach GND schliesse, 2 geschlossene lichtschranken gleichzeitig ist eher unwahrscheinlich bei einem einzigen objekt, daher einfach alle 4 an einen pin und in der ICP ISR dann werte speichern, war ja nur n vorschlag

    EDIT: da das topic etwas länger läuft hab ich mich von deinem post
    ahhhhh, stimmt - Polling ist, wenn man NUR die Zeit braucht, sicher eine gute und einfache Möglichkeit. Andernfalls käme ich bei vier Lichtschranken auch mit den zwei externen Interrupts am m16 nicht aus, zumal der auch keinen PCI hat.
    in die irre führn lassen weil ich den ersten post net nomma gelesen habe

  2. #12
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.693
    Au au, das mit dem m16 war ja ein böser Missgriff von mir, tut mir leid (ich dachte nachts mache ich meine Fehler, aber ich seh schon, ich war unausgeschlafen).

    Ich weiß nicht, was EIN Pin macht, wenn ich vier Quellen anhänge und auf steigende bzw. fallend Flanke einer einzigen Quelle detektieren will. Ok, ich kann die alle auf low ziehen, und wenn dann eine high ist, muss die es halt bringen. Aber ich denke aus Gründen der Testbarkeit sind vier getrennte Anschlüsse einfacher (da weiss man dann eher, wo der Fehler steckt - wenn´s mal nicht funktioniert).
    Ciao sagt der JoeamBerg

  3. #13
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    naja wenns nur schliesser sind und keine logiklevel (die meisten "üblichen" lichtschranken mit denen ich es in der schule zu tun hatte waren schliesser .... z.T. mit relais, problematisch wegen prellen), gibts ja keine definierten pegel! also wenn eine geschlossen ist isses egal ob ich die 3 anderen offen oder geschlossen habe, low ist low bleibt low, der präzision wegen hatte ich halt den timer vorgeschlagen, wenn die lichtschranken logiklevel servieren wäre es ja ein kurzschluss (!!!) zwischen den lichtschranken wenn eine low geht und die anderen high bleiben oder umgekehrt

    okay .... es fielen die worte steigende und fallende flanke ... klingt stark nach logiklevel .... guuuuuuut mein fehler ... erst lesen dann denken dann schreiben

  4. #14
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Was für Anschlüse die Lichtschranken haben, hängt von der speziellen Type ab. Ich habe welche Aufgebaut, die man nicht einfach prallelschalten kann, schon wegen der Kabelkapazitäten. Lichtschranken mit Relaisausgang sind ziehmlich ungewähnlich, schon wegen der Geschwindigkeit und des Prellens.
    Die Controller haben genug Pins,um jeder Lichtschraunke einen Eingang zu spendieren. So hat man die volle Flexibilität. Von der geschwindigkeit sollte Polling eigentlich reichen, das sollte für 1µs Auflösung reichen, wenn man den Timer direkt ausließt. Schnellere Lichtschranken sind schon gar nicht so leicht zu bauen.

  5. #15
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.232
    Von der Polling Sache würde ich Abstand nehmen, da sich die Programmlaufzeit mit jeder Programmänderung wieder verändert und voll in die Messung mit eingeht.

    Deshalb würde die Zeiterfassung komplett in Interrupts laufen lassen.
    Als mögliche Quellen kämen beim ATMEGA16: INT0, INT1, INT2 sowie der ICP1 in Frage.
    Man könnte auch noch den analog Komperator dazu verwenden.
    Als Zeitquelle kommt der Timer1 in Frage.
    Der Ablauf wäre:
    INT0 liest die Zeit aus dem Timer1 ( + Uberlaufvariable ) aus und speichert sie in einer Variable

    INT1 liest die Zeit aus dem Timer1 ( + Uberlaufvariable ) aus und zieht den Wert von INT0 ab, speichert diesen Wert ab und setzt ein Flag.

    INT2 liest die Zeit aus dem Timer1 ( + Uberlaufvariable ) aus und zieht den Wert von INT0 ab, speichert diesen Wert ab und setzt ein Flag.

    ICP1 liest die Zeit aus dem Timer1 ( + Uberlaufvariable ) aus und zieht den Wert von INT0 ab, speichert diesen Wert ab und setzt ein Flag.

    Im Hauptprogramm werden dann die Flags abgefragt und die Messwerte ( Geschwindigkeit ) daraus berechnet.
    Wenn die Messwerte verarbeitet wurden werden im Hauptprogramm die Flags wieder gelöscht.
    Der bezug auf Timer 0 deshalb, wenn eine Lichtschranke nicht reagiert, wäre die komplette Messung der nachfolgenden Lichtschranken nicht mehr auswertbar.

    Man kann auch im Timer1Overflow Interrupt noch eine weitere Variable hochzählen, die die höherwertigen Bytes der Zeitmessung darstellen.

    Einen Schönheitsfehler hat die Messmethode mit dem Überlauf noch- während des Zeitmessinterrupts ( z.B. INT0 ) könnte gleichzeitig noch ein Timer Overflow Interrupt anliegen, der aber nicht verarbeitet werden kann.
    Als "Bastellösung" könnte man kurz vor dem Auslesen der Timer Messwerte die Interrupts mit "SEI" freigeben ( sind normalerweise während eines laufenden Interrupts gesperrt ) und danach mit "CLI" wieder sperren.
    Dadurch verringert sich die Chance auf eine Fehlmessung auf ein paar wenige Prozessortakte.
    Also:
    #asm ("sei");
    #asm ("nop");
    #asm ("cli");
    ui_int0low=TCNT1;
    li_int0high=ui_tcnt1overflow;
    li_int0high=(li_int0high*65536)+ui_int0low;
    ub_int0flag=1; // Bei INT0 wäre es eigentlich nicht nötig

    Der gewünschte Messwert liegt also jetzt in der Variablen li_int0high als 32Bit Integer Wert.
    Das wäre eigentlich schon die Ganze Interruptroutine.
    Der Rest ( Berechnung ) kann bequem in der Hauptroutine erledigt werden.
    Inlineassembler könnte das Problem noch weiter entschärfen.

    Die Prellgeschichte könnte man durch ein MonoFlop lösen.
    Wird ein Signal von der Lichtschranke ausgegeben wird eine MonoFlop getriggert, das für mindestens 10ms den Pegel festhält.
    In dieser Zeit sollten eigentlich alle Prellimpulse abgeklungnen sein.
    Ebenso könnte bei Deaktivieren des Gebers verfahren werden.
    Das Ganze sollte sich mit ein paar Logikgattern lösen lassen.

    Zur Lichtschrankengeschichte.
    So lange man Lichtschranken des gleichen Typs verwendet, sollten auch die Latenzzeiten in etwa gleich sein.
    Das bedeutet, die Messung kommt zwar später an, stimmt aber, da ja alle Lichtschranken verspätet reagieren.

  6. #16
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Eine kurze Schleife beim Polling ist nicht wesenlich schlechter als die Unsicherheit durch die Verzögerung bis der Interrupt aufgerufen wird.
    Das größte Problem ist dabei der eher selten auftretende Timer überlauf. Der würde das Polling oder einen Interrupt etwas verzögern. Man könnte das eventuell vermeiden, indem man Hardwaremäßig (extern) die Timer hintereinanderschaltet. Genauer wird es aber mit der ICP Funktion.
    Die Lösung mit externen interrupts hat aber auch was für sich: Man ist naich darauf angewiesen in welcher Reihenfolge die Flanken auftreten. Es ist ja nicht klar ob das der Körper aus der einen Lichtschranke raus ist bevor er in die Nächste reinkommt.


    Das Problem mit dem Überlauf kurz vor / nach dem Auslesen der Zeit kann man mit Hilfe der Interrupt Flags lösen, so wie im ICP Beispiel:
    Wenn man einen kleinen Wert aus dem Timer einließt und ein Overflow Interrupt noch aussteht, dann muß der Overflow interrupt vorher dran, sonst nicht.

  7. #17
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.693
    Hallo wkrug,

    Zitat Zitat von wkrug
    ... Polling ... Abstand nehmen, ... Programmlaufzeit mit jeder Programmänderung wieder verändert ...
    Vermutlich ja, wenn man innerhalb der Pollroutine ändert. Warum sollte ich denn?
    Zitat Zitat von Tanja1986
    ... soll an jeder Schranke ... bei steigender Flanke starten und bei fallender stoppen. Es soll dann lokal eine Geschwindigkeit gemessen werden, sowie die Zeit gestoppt werden die der Körper zwischen zwei Schranken braucht ...
    Sie will ja die steigende UND die fallende Flanke. Und warum eigentlich nicht?
    Zitat Zitat von Tanja1986
    ... Das soll eine redundante Messung ergeben ...
    Soweit ich es (vorerst) verstehe, weill sie auf dem Board nur die beschriebene Geschwindigkeitsmessung machen. Eine Stoppuhr für insgesamt sieben Werte.
    Zitat Zitat von wkrug
    ... wenn eine Lichtschranke nicht reagiert, wäre die komplette Messung der nachfolgenden Lichtschranken nicht mehr auswertbar ...
    Genau hier liegt eine mögliche Störquelle einer Kaskade. Da denke ich, das Pollen der Zustände an vier Pinnen und das Speichern der sieben Zeiten (blos nix rechnen!) ist so schnell, dass es selbst für über 100 kmh einen Fehler unter 1 % ermöglichen sollte. Aber ich weiß noch nicht, wie gross(lang) die zu messenden Objekte sind. Diese Angabe ist für eine saubere Auslegung notwendig.
    Ciao sagt der JoeamBerg

  8. #18
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Über die Genauigkeit braucht man sich auch nicht so viele Gedanken machen. Selbst wenn die Testkörker sichmit 10 m/s bewegen, gibt das in 1 µs nur 10µm. So genau von der mechanischen Position sind allermeisten Lichtschranken ohnehin nicht. Schon 0,1 mm wäre recht gut für eine Lichtschranke.

    Wenn man den Timer erst mit der ersten flanke startet, könnte man sogar schon mit der 16 Bit Auflösung von Timer 1 Auskommen, und kann sich den ganzen Umstand mit den Überläufen sparen. Das Hängt aber natürlich von konkreten Aufbau ab.

Seite 2 von 2 ErsteErste 12

Berechtigungen

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

Labornetzteil AliExpress