>> Spontan würde ich mich an Deiner Stelle an National-Instruments
>> wenden. Die haben dafür geeignete Hardware und auch Software, die das
>> gut unterstützt. Im Zweifelsfall vermitteln die Dir sogar ein
>> Ingenieurbüro, das das für Dich zusammenstellt...
> Und eine Bank, die den dazu notwendigen Kredit gibt. > Im Ernst: Immer wenn ich damit zu tun hatte, zeichneten sich > Nat-Inst-Lösungen durch eine Null mehr am Preisschild aus.
Ich habe von NI noch nie etwas $500 gesehen. Als ein Kunde eine solche
Chose erwog und schonmal satt vierstellig budgetierte habe ich denen das
zusammen mit einem SW-Profi mit drei Labjacks plus einem USB Hub
erledigt. Das Schreiben der SW war vom Zeitaufwand kein nennenswerter
Unterschied. Wer das unbedingt in eine NI Umgebung integriert haben
moechte, auch kein Problem, gibt es LabView Treiber fuer.
Im Forschungsbereich habe ich das aber nie gesehen, die nahmen immer die
$$$$ Loesung, per Default sozusagen. Da scheint das Geld lockerer zu
sitzen :-)
> Im Forschungsbereich habe ich das aber nie gesehen, die nahmen immer die
> $$$$ Loesung, per Default sozusagen. Da scheint das Geld lockerer zu
> sitzen :-)
In Forschungseinrichtungen geht es, der Name sagt es schon, halt darum,
neue Forschungsergebnisse zu generieren. Reines Engineering -- im Sinne
von: ich baue mir meine eigene DAQ-Box, weil die von NI so teuer ist --
wird deutlich weniger honoriert.
Christian
-- Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/ PGP/GnuPG-Key-ID: 0x6DA025CA
>> Im Forschungsbereich habe ich das aber nie gesehen, die nahmen immer die
>> $$$$ Loesung, per Default sozusagen. Da scheint das Geld lockerer zu
>> sitzen :-)
> In Forschungseinrichtungen geht es, der Name sagt es schon, halt darum,
> neue Forschungsergebnisse zu generieren. Reines Engineering -- im Sinne
> von: ich baue mir meine eigene DAQ-Box, weil die von NI so teuer ist --
> wird deutlich weniger honoriert.
... und dann klagen sie ueber mangelnde Budgets und man muesse jetzt
unbedingt wieder die Steuern erhoehen und so :-)
Ich hatte da mal eine Diskussion wo ein Job in einer Forschungsarbeit
eindeutig von einem $600 Scanner mit PC Anschluss haette uebernommen
werden koennen (Logging der Verschiebung einer Spektrallinie). Sogar die
$500 Variante ohne Konsole haette gereicht. Wie bei der DAQ-Box ohne
jeglichen zeitlichen Mehraufwand. Die Antwort war im Prinzip dass das
nicht edel genug sei, man eh nicht einfach so bei Amateurfunkgeschaeften
kaufen duerfe, von wegen Zentrale Beschaffung, Antrag und blah-blub. Wo
kaeme man hin? Das Endergebnis war die Anschaffung eines hoch
fuenfstellig kostenden Analyzers einer namhaften Messgeraeteschmiede.
Und nein, mein anderer Vorschlag, ein taiwanesischer Billig-Analyzer
fuer $2k, war auch nicht edel genug und die Firma stand nicht auf der
"Approved Vendor List" oder so.
> Die Antwort war im Prinzip dass das
> nicht edel genug sei, man eh nicht einfach so bei Amateurfunkgeschaeften
> kaufen duerfe, von wegen Zentrale Beschaffung, Antrag und blah-blub. Wo
> kaeme man hin? Das Endergebnis war die Anschaffung eines hoch
> fuenfstellig kostenden Analyzers einer namhaften Messgeraeteschmiede.
Na, wir dürfen schon bei jedem kaufen, der in der Lage ist, ein
anständiges Angebot und eine vernünftige Rechnung auszustellen. Ein
Kollege von mir hat z.B. SHF-Leistungsverstärker aus dem
Funkamateurumfeld bezogen, einfach weil sie dort günstiger sind.
Nur, wenn er sich -- sagen wir -- einen Monat hingesetzt hätte und das
Ding selber gebaut hätte (nicht schwingend, anständig gekühlt etc.),
wäre das halt ein Monat gewesen, in dem er nicht sein eigentliches
Forschungsthema weitergebracht hätte.
Christian
-- Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/ PGP/GnuPG-Key-ID: 0x6DA025CA
>> Die Antwort war im Prinzip dass das
>> nicht edel genug sei, man eh nicht einfach so bei Amateurfunkgeschaeften
>> kaufen duerfe, von wegen Zentrale Beschaffung, Antrag und blah-blub. Wo
>> kaeme man hin? Das Endergebnis war die Anschaffung eines hoch
>> fuenfstellig kostenden Analyzers einer namhaften Messgeraeteschmiede.
> Na, wir dürfen schon bei jedem kaufen, der in der Lage ist, ein
> anständiges Angebot und eine vernünftige Rechnung auszustellen. Ein
> Kollege von mir hat z.B. SHF-Leistungsverstärker aus dem
> Funkamateurumfeld bezogen, einfach weil sie dort günstiger sind.
Aber Auktionskaeufe haettet Ihr vermutlich nicht gedurft :-)
Ich habe den Loewenanteil meines Labors ueber Auktionen und dergleichen
zusammengestellt, das hat einen Riesenbatzen Geld gespart. Pennies on
the Dollar, wie wir hier sagen. Dabei muss man einer Firma oder einem
Konkursverwalter ein Angebot machen, nicht umgekehrt.
> Nur, wenn er sich -- sagen wir -- einen Monat hingesetzt hätte und das
> Ding selber gebaut hätte (nicht schwingend, anständig gekühlt etc.),
> wäre das halt ein Monat gewesen, in dem er nicht sein eigentliches
> Forschungsthema weitergebracht hätte.
Stimme voll zu. Allerdings passiert genau das oft an Unis. Z.B.
schreiben dauernd Leute ihr eigenes FFT-Programm neu was meist
Zeitverschwendung ist. Ganz selten kommt wie letztens (am MIT?) mal was
sinnvolles raus wie Sparse Data FFT.
Anders sieht es aus wenn ein Lerneffekt dabei rauskommen soll, es kann
etwa bei Diplomarbeiten auch mal sinnvoll sein das Rad neu zu erfinden.
> Deswegen zählst du die Impulse *und* capturest die Flanke mit einem
> Timer, der mit dem µC-Takt läuft. Bei den Eingangsimpulsen *kannst*
> du dich gar nicht verzählen. Und µC-Takte liegst du schlimmstenfalls
> 2 daneben. Statistisch nur einen. Wenn du also 1 Mio µC-Takte zählst
> (10MHz, 100ms), bist du bei maximal 2ppm Fehler = 0.1 Hz @ 50kHz
Hängt davon ab, wie genau deine 100 ms Zeitscheiben sind, aber könnte
gehen, wenn es z.B. per hoch priorisierten Interrupt abläuft. Man müsste
sich aber schon noch was überlegen für die verschiedenen Fälle, also 100
ms Zeitscheibenende gerade im Low-Bereich des Signals, oder mitten im
High-Bereich usw.
Für eine Einzelanfertigung hängt es auch immer davon ab, mit was man am
besten vertraut ist. Bevor ich mich in die AVR-Register und Timer
eingelesen hätte und einen Algorithmus dazu entwickelt hätte, der dazu
passt, hätte ich das schon längst per CPLD realisiert. Counter für die
Anzahl Impulse und die letzte gemessene Zeit für vollständig gemessene
Wellen innerhalb von 100 ms. Den VHDL Code könnte ich fast so
hinschreiben :-)
Sven Schulz wrote:
>Der Drehgeber. Immer wenn ein Rechteck erkannt wurde und ein neuer Wert des >Sensors vorliegt, soll die zu sendene Datenreihe mit der aktuellen Position >des Inkrementalgebers aktualisiert werden, in 1/10 Grad-Darstellung.
>Wird an der Welle der Inkrementalgeber >angeschlossen und die Welle läuft mit 300rpm, dann ist eine Umrundung in >0.2s fertig. Eine Inkrementwechsel bei einer Auflösung von 1/10 Grad dauert >ein Wechsel 0.2/360/10=55 mikrosekunden (wenn das korrekt berechnet habe).
55µs Periode sind bei 20MHz Systemtakt mehr als 1000 Takte, in denen ein
lütter AVR auch fast 1000 Operationen ausführen kann.
Wenn der AVR nebenbei noch ein Videospiel ruckelfrei laufen lassen
müßte, ja dann wäre sicher etwas Gehirnschmalz und erhöhter Aufwand
nötig, da käme man dann wohl tatsächlich in den Bereich von Wochen
Entwicklungsaufwand. Aber sooo...
>> Der Drehgeber. Immer wenn ein Rechteck erkannt wurde und ein neuer Wert des
>> Sensors vorliegt, soll die zu sendene Datenreihe mit der aktuellen Position
>> des Inkrementalgebers aktualisiert werden, in 1/10 Grad-Darstellung.
>> Der Sensor liefert Werte alle 1ms.
> 55µs Periode sind bei 20MHz Systemtakt mehr als 1000 Takte, in denen ein
> lütter AVR auch fast 1000 Operationen ausführen kann.
Ist schon richtig, aber das Problem ist die Zuordnung der Sensorsignale zu den Drehgeberdaten, d.h. der Sensor liefert nur auf jeden 20. Drehgebertakt ein Signal.
Die Frage ist jetzt, ob man ein Wertepaar alle 55us benötigt, oder jeweils ein Wertepaar passend zum langsameren Geber, also wenn der Drehgeber schneller ist als 1ms, dann mit jedem Sensorsignal ein Wertepaar (Sensor, Position) senden und wenn der Drehgeber langsamer ist, mit jedem Drehgebertakt ein Wertepaar.
Das Drehgebersignal könnte man mit 2 Bytes codieren. Das ließe sich eventuell noch reduzieren, z.B. indem man nur die Differenz überträgt.
Wenn der Sensor dann z.B. 3 Bytes liefert, müsste man jede ms ca. 5 Bytes übertragen.
Mit 9k6 kommt man auf ca. 1 Byte/ms. Man müsste also entsprechend schneller senden, oder man verwendet eine richtige USB-Hardware mit ausreichender Geschwindigkeit, z.B. AT90USB162 (?). Mit nem seriell/USB-Wandler könnte es knapp werden.
Wenn man die Daten zwischenspeichern könnte, um sie dann anschließend langsamer zu senden, sähe das etwas anders aus. Kommt dann drauf an, wieviele Daten der OP benötigt.
> Für eine Einzelanfertigung hängt es auch immer davon ab, mit was man am
> besten vertraut ist. Bevor ich mich in die AVR-Register und Timer
> eingelesen hätte und einen Algorithmus dazu entwickelt hätte, der dazu
> passt, hätte ich das schon längst per CPLD realisiert. Counter für die
> Anzahl Impulse und die letzte gemessene Zeit für vollständig gemessene
> Wellen innerhalb von 100 ms. Den VHDL Code könnte ich fast so
> hinschreiben :-)
Ich hab es heute mit nem ATmega128 weitgehend fertig bekommen, obwohl ich zwischendurch ständig gestört wurde und auch noch Termine außer Haus hatte. Läuft ganz gut und sind nur wenige Zeilen Code. Probleme hatte ich nur mit den Besonderheiten von C, siehe mein anderer Thread von heute ;-)
> ich möchte einen Rohdaten eines Drehzahlgebers (mit
> Rechtecksignalausgang, TTL, nur eine Drehrichtung, 3600 Inkremente pro
> 360 Grad) und einen zeitgleich laufenden Datenstrom eines intelligenten
> Sensors (Seriell, RS232) in einem von der Stange kaufbaren
> "Datenzusammenführungskasten" zusammenführen (synchronisieren).
WEnn es jetzt ein Drehgeber plus digitale I/Os gewesen wäre, hätte ich Dir eine der USB DAQ Lösungen von Meilhaus empfohlen. So läuft das entweder auf Labview mit Hardware von NI oder auf z.B. Beckhoff PLC-Komponenten hinaus. Wenn der PC ohnehin vorhanden ist, reicht ein Buskoppler plus 2 I/O-Module.
Das Problem ist, dass man definieren muss, wann der "intelligente" Sensor seine Daten gesampelt hat. Die Übertragung via RS232 dauert ja ein ganzes Stück länger...
Frank Buss <f...@frank-buss.de> wrote:
> Axel Schwenke wrote:
>> Deswegen zählst du die Impulse *und* capturest die Flanke mit einem
>> Timer, der mit dem µC-Takt läuft. Bei den Eingangsimpulsen *kannst*
>> du dich gar nicht verzählen. Und µC-Takte liegst du schlimmstenfalls
>> 2 daneben. Statistisch nur einen. Wenn du also 1 Mio µC-Takte zählst
>> (10MHz, 100ms), bist du bei maximal 2ppm Fehler = 0.1 Hz @ 50kHz
> Hängt davon ab, wie genau deine 100 ms Zeitscheiben sind, aber könnte
> gehen, wenn es z.B. per hoch priorisierten Interrupt abläuft.
Keine Zeitscheiben. Reziprokzähler.
Vielleicht findest du es ja einfacher, das als Messung der Dauer
von N aufeinanderfolgenden Perioden zu betrachten. Du fängst bei
einer x-beliebigen Flanke des Signals an, Impulse deiner Referenz
zu zählen und sobald du genug solche Impulse hast, hörst du mit
der nächsten (gleichartigen) Flanke des Signals wieder damit auf.
Wenn du dann K Impulse von f_ref gezählt hast, hat das Signal eine
(mittlere) Frequenz von f_ref*N/K. Der Fehler ist im statistischen
Mittel 1/K, maximal 2/K.
Die klassische Darstellung hat zwei Zähler - je einen für f_x und
für f_ref, mit einem gemeinsamen Tor. Das Tor öffnet und schließt
dabei synchron zu f_x. Implementieren kann man das auf jedem µC
der einen extern taktbaren Zähler und eine Capture-Einheit hat.
Zumindest solange die Frequenz niedrig genug ist, daß man nach dem
Auslösen der ersten Flanke Zeit genug hat, den f_x-Zähler zu löschen
und den Capture-Timestamp zu lesen, bevor der nächste Impuls kommt.
> Für eine Einzelanfertigung hängt es auch immer davon ab, mit was man am
> besten vertraut ist. Bevor ich mich in die AVR-Register und Timer
> eingelesen hätte und einen Algorithmus dazu entwickelt hätte
Bei mikrocontroller.net gibts gefühlt 100 Implementierungen des
Prinzips. Eine davon von mir. Allerdings - weil sie nahtlos bis
40MHz gehen soll - mit externem Gate-Flipflop und 8-Bit Zählstufe.
>Reines Engineering -- im Sinne von: ich baue mir meine eigene DAQ-Box,
>weil die von NI so teuer ist -- wird deutlich weniger honoriert.
Meine eigene Anschauung legt mir nahe, daß die Generation meiner Eltern, die kurz nach dem Krieg die Meßausrüstung für ihre Dissertationen weitgehend selber bauen mußten von dem, was sie da eigentlich taten, erheblich mehr wirklich verstanden, als meine Generation, wo für viele die Inhalte der Black-Boxen tatsächlich vollkommen dunkel bleiben. Wissenschaft ist mehr als das stumpfe Ablesen vielstelliger Displays.
>Die Antwort war im Prinzip dass das nicht edel genug sei,
Ein Frequenz-Spannungs-Wandler, das, was in den Siebzigern überall für wenige Mark als Drehzahlmesser im Regal lag, nur noch viel primitiver nämlich ohne das edle 270-Grad Drehspulinstrument und nur mit Ausgangsklemmen, für 500 Mark. Aufgemacht und alle Widerstände, auch und gerade die die Genauigkeit bestimmenden billigste Kohlenschicht und alle Kondensatoren ebenfalls Billigversionen.
Aber "professionelles" graues, häßliches, billiges Plastikgehäuse.
>> Aber Auktionskaeufe haettet Ihr vermutlich nicht gedurft :-)
> Bei uns geht sowas mittlerweile, wenn auch immer die Buchhaltung die
> Augen verdreht :)
Ich habe einige Kunden dazu ermuntert. War in etwa das gleiche, die
Buchhaltung war nicht so begeistert aber der VP Engineering welcher das
Budget zu verantworten hat juchzte. Inzwischen sind aber die Preise in
den USA aufgrund der besser werdenden Konjunktur angezogen. Man zahlt
nicht mehr 5% vom Neuwert sondern 10% :-)
> Inzwischen sind aber die Preise in den USA aufgrund der besser
> werdenden Konjunktur angezogen. Man zahlt nicht mehr 5% vom Neuwert
> sondern 10% :-)
Kommt exakt hin, der Krempel den ich vor 2-3 Jahren in der USA
geschossen habe kostet aktuell mindestens das Doppelte.
Stefan
<stefan@hier_steht_absichtlich_keine_EMail_Adresse_1234567890.de>
wrote:
Moin!
>Es geht schon so ähnlich, wie Gernot geschrieben hat, d.h. mit der >Capture-Unit, aber es wird nicht die Impulszahl in der vorgegebenen >Messzeit, sondern die Zeit für eine bestimmte Anzahl von Impulsen gemessen.
Genau sowas machen wir gerade mit nem kleinen Xmega: Eingangssignal
(Quadratursignal vom Drehgeber) läuft auf einen 16-Bit-Zähler,
gleichzeitig triggern die Flanken einen 32-Bit-Timer-Capture. Zu
beliebigen Zeitpunkten wird beides abgefragt und mit den alten Werten
verglichen. Der Quotient aus Eingangsperioden und Timer-Takten ergibt
die Frequenz mit einer Auflösung, die dem Verhältnis aus
Abfragefrequenz zu Timerfrequenz entspricht, bei mir etwa 10^-6
(dieses Verfahren bietet eine _relative_ Auflösung!).
>Mit jeder steigenden Flanke des Taktes wird der Counter gecaptured und >ein INT ausgelöst. In der INT-Routine wird auf Überlauf des 16 Bit >Zählers getestet und gegebenenfalls ein weiteres Byte oder Word >incrementiert.
Das schöne beim Xmega (im Vergleich zum Mega) ist, daß Quadratur-
decoder, Zähler und Timer-Capture alle in Hardware gekoppelt werden
können. Dadurch muss man dann nicht mehr jede Flanke einzeln per
Handschlag (INT) begrüßen und die ganzen Sonderfälle abfangen (kam der
Überlauf jetzt vor oder nach der Flanke?), sondern fragt gemütlich nur
noch beide Zähler ab, wenn sie einen interessieren.
