Datenzusammenführungskasten kaufen?

[Sven Schulz]

Hallo,



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). Nach dem Zusammenführen (synchronisieren)
lese ich den Datenstrom via USB bequem in den PC ein, als TXT-File. Dann
werte ich das Ganze mit einer beliebigen Software aus.

Gibt es Firmen die solche "Datenzusammenführungskästen" anbieten?



Sven

[Jens Fittig]

Sven Schulz schrieb:

Sicher - im Maschinenbau gibt es auch solche Aufgabenstellungen. Aber
diese Leute wissen was sie wollen.

Du hast aber wohl keinen Schimmer was du eigentlich willst. Man kann
nicht einfach Rechteckpulse eines Inkrementgeber mit irgendwelchen
Meßdaten "verknüpfen".

Zuerst brauchst du einen zeitlichen Zusammenhang. D.h. konkrete
einzelne Werte mit Zeitstempel. Dazu müssen also erst mal
Vorauswertungen der beiden Signale erfolgen. Und dann müssen die
gewünschten Kriterien zusammen weiterverarbeitet werden. Je nach
Aufgabe in Anhängigkeit der Zeit oder eines der beiden Signale. Sonst
nützt dir die ganze Auswerterei nichts.

Die ganze Lösung schreit nach einem Mikroprozessor mit genau passender
Software. Die du dir aber garantiert selber schreiben musst.

Wenn du etwas mehr Input lieferst hat vielleicht jemand eine
weiterführende Idee.

[Stefan]

Am 11.03.2012 11:25, schrieb Jens Fittig:
>
> Sven Schulz schrieb:
>
>> Hallo,
>>
>>
>>
>> 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). Nach dem Zusammenführen (synchronisieren)
>> lese ich den Datenstrom via USB bequem in den PC ein, als TXT-File. Dann
>> werte ich das Ganze mit einer beliebigen Software aus.
>>
>> Gibt es Firmen die solche "Datenzusammenführungskästen" anbieten?
>
> Sicher - im Maschinenbau gibt es auch solche Aufgabenstellungen. Aber
> diese Leute wissen was sie wollen.
>

Das scheint der OP auch zu wissen...

> Wenn du etwas mehr Input lieferst hat vielleicht jemand eine
> weiterführende Idee.

Der Input reicht schon aus. Aber es reicht wohl nicht für W. Gerber.

Wenn es unbedingt eine gekaufte Hardware von der Stange sein soll, käme
eine S7-226 in Frage. Das ist eine SPS mit 2 seriellen Schnittstellen
und schnellem Zähler, wo man den Drehwinkelgeber (auch solche mit
Zweiphasentakt) anschließen könnte. Dazu müsste man aber aus den
TTL-Signalen erstmal 24V Signale machen, oder einen entsprechenden
Sensor nehmen. Wir verwenden für sowas Hengstler Drehwinkelgeber direkt
an einer S7-224. Außerdem müsste man noch Umsetzer von RS232 (Sensor?)
auf RS485 (S7) sowie Umsetzer von USB auf RS485 haben. Und dann muss das
natürlich jemand programmieren. Wenn mich ein Kunde nach sowas fragen
würde, würde ich dafür ca. 2000,- € ansetzen.

Mein Vorschlag wäre aber ein Mikroprozessorsystem mit 2 seriellen
Schnittstellen, z.B. auf Basis ATmega128 oder ATmega64 in Verbindung mit
einem seriell zu USB Umsetzer. Passende Hardware gibts vermutlich bei
Olimex. Programmieraufwand ist in etwa vergleichbar, aber in C etwas
eleganter als bei der S7-226.

Gruß

Stefan

[Heiko Nocon]

Stefan wrote:

>Wenn es unbedingt eine gekaufte Hardware von der Stange sein soll, käme
>eine S7-226 in Frage.

Das geht wohl nicht ganz in die Richtung, die der OP wünscht. Das
Problem dürfte sein, daß hier (wie in jeder anderen sinnvollen, d.h.
µC-basierten Lösung) ein Programm geschrieben werden muß, damit
irgendwas sinnvolles passiert.

Das genau scheint aber die Fähigkeiten des OP zu überfliegen, sonst
hätte er nicht gefragt, sondern einfach eine entsprechende µC-Lösung
implementiert. Fertige kaufbare µC-Boards mit den nötigen
Anschlußoptionen gibt's ja wie Sand am Meer.

[Sven Schulz]

Heiko Nocon wrote:
>
> Das genau scheint aber die Fähigkeiten des OP zu überfliegen, sonst
> hätte er nicht gefragt, sondern einfach eine entsprechende µC-Lösung
> implementiert. Fertige kaufbare µC-Boards mit den nötigen
> Anschlußoptionen gibt's ja wie Sand am Meer.

Fähigkeiten sind schon vorhanden. Allerdings ist die Zeit, eine individuelle
Lösung zu entwickeln, sehr begrenzt. Und ein echzeitfähiges "Einsammel- und
Sendesystem" zu bauen ist nicht innerhalb weniger Tage gelöst, ganz egal mit
welchem uC.
Es gibt HIL-Systeme mit denen man soetwas im Grunde lösen kann. Die sind
jedoch mit ~30K Euro etwas am Budget vorbei.

Sven

[Edzard Egberts]

> 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). Nach dem
> Zusammenführen (synchronisieren) lese ich den Datenstrom via USB bequem
> in den PC ein, als TXT-File.

Erscheint mir unnötig kompliziert, niemand benutzt Hardware für
Aufgaben, die sich per Software lösen lassen. Den Sensor direkt an den
PC anschließen, entweder per RS232 oder mit einem RS232<->USB-Wandler.
Den Drehzahlgeber ebenfalls an einen Port, z.B. Drucker. Oder einen
Drehzahlgeber<->PC-Kasten besorgen, so etwas dürfte es einzeln eher geben.

Auf dem PC läuft dann die Datenzusammenführung - ein Programm öffnet die
Ports und schreibt/synchronisiert die Werte.

[Joerg]

Sven Schulz wrote:
> Hallo,
>
>
>
> 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). Nach dem
> Zusammenf�hren (synchronisieren) lese ich den Datenstrom via USB bequem

> in den PC ein, als TXT-File. Dann werte ich das Ganze mit einer
> beliebigen Software aus.
>

> Gibt es Firmen die solche "Datenzusammenf�hrungsk�sten" anbieten?
>

Ja, kommt aber drauf an wie praezise die Synchronitaet sein muss. Sieh
Dir mal an ob dieser reicht, damit haben wir das in umgekehrter Richtung
vom PC in Anlagen schon gemacht:

http://labjack.com/u3

Die liefern eine Menge Software mit, aber wir haben einen SW-Consultant
geheuert der das in C schrieb und in die dicke Software fuer die Anlagen
einband.

Und wie sie beim Rundfunk in Deutschland sagten, wenn es mal nicht
synchronisiert hilft immer noch Maria Synchron :-)

Fuer Massenprodukte wo es auf jeden Euro ankommt gibt es noch die USB to
Multipurpose Chips von FTDI mit denen wir das auch schonmal machen, aber
das erfordert HW und SW Leute die mit der Materie sehr vertraut sind.
Wenn Du eher die "Knack & Back" Fertigvariante suchst ist sowas wie
Labjack besser. Da gibt es auch noch andere Fabrikate.

BTW, Du kannst m.W. auch ohne bzw. vor dem Kauf in den Labjack Foren
Details erfragen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

[Stefan]

Am 11.03.2012 15:04, schrieb Sven Schulz:

> Fähigkeiten sind schon vorhanden. Allerdings ist die Zeit, eine
> individuelle Lösung zu entwickeln, sehr begrenzt. Und ein echzeitfähiges
> "Einsammel- und Sendesystem" zu bauen ist nicht innerhalb weniger Tage
> gelöst, ganz egal mit welchem uC.
> Es gibt HIL-Systeme mit denen man soetwas im Grunde lösen kann. Die sind
> jedoch mit ~30K Euro etwas am Budget vorbei.

Wie viele Daten musst du denn übertragen?

Wenn ich das richtig verstanden habe, geht es zum einen um die
Kommunikation mit einem intelligenten Sensor mit serieller
Schnittstelle. Muss der irgendwelche Kommandos bekommen, oder sendet der
selber?
Ich nehm mal an, die Daten des intelligenten Sensors müssen mit den
Daten des Drehwinkelgebers synchronisiert werden. Mit welcher Auflösung
muss das passieren? Wer gibt den Takt vor, der Drehwinkelgeber, oder der
intelligente Sensor? Hast du abgeklärt, ob der intelligente Sensor die
Daten schnell genug liefert, d.h. sind die Laufzeiten irrelevant, oder
gibt es dort möglicherweise ein Problem?

Warum nimmst du nicht einen PC mit zwei Schnittstellen?

Gruß

Stefan

[Stefan]

Fragt sich nur, ob der PC das kann. Ein Mikrocontroller kann sowas
prinzipiell im Mikrosekundenbereich synchronisieren. Beim PC wirds bei <
100ms schon problematisch.

Gruß

Stefan

[Jens Fittig]

Stefan schrieb:

> > Sicher - im Maschinenbau gibt es auch solche Aufgabenstellungen. Aber
> > diese Leute wissen was sie wollen.

> Das scheint der OP auch zu wissen...

Offensichtlich nicht

> > Wenn du etwas mehr Input lieferst hat vielleicht jemand eine
> > weiterführende Idee.

> Der Input reicht schon aus. Aber es reicht wohl nicht für W. Gerber.

Alberner Dummschwätzer! Wird es nicht langsam langweilig mit solchen
Äusserungen den Gruppenclown zu machen?

[Joerg]

100msec kriegt man noch hin. Unter 1msec bei USB aber dann nicht mehr so
einfach wenn es ueber verschieden Ports reinkommt. Natuerlich alles
unter der Voraussetzung dass man nicht ein "modernes"
Pluesch-Betriebssystem benutzt sondern was vernuenftiges.

Mit QNX haben wir zig Mikrosekunden hingekriegt, gusseisern robust und
deterministisch.

[Gernot Fink]

In article <jjie6u$me7$1...@news2.open-news-network.org>,

Edzard Egberts <ed...@tantec.de> writes:

> Aufgaben, die sich per Software lösen lassen. Den Sensor direkt an den
> PC anschließen, entweder per RS232 oder mit einem RS232<->USB-Wandler.
> Den Drehzahlgeber ebenfalls an einen Port, z.B. Drucker. Oder einen
> Drehzahlgeber<->PC-Kasten besorgen, so etwas dürfte es einzeln eher geben.

sehe ich genauso mit einem FT2232 oder 2 fertigen FTDI-USB-seriell Wandlern
könnte man sicher etwas machen.

Der serielle Datenstrom ist ja kein Problem. Dafür sind sie ja gemacht.

Beim anderen könnte man auf synchrone Datenübertragung umstellen und so
Impulse erfassen falls die nicht zu schnell werden.

Die am besten funktionierende Lösung wird aber der Microcontroller bleiben.

--
MFG Gernot

[Frank Buss]

Könnte je nach Geschwindigkeit durchaus schwierig werden, denn bei 3600
Inkrementen pro Umdrehung und z.B. schnell drehenden Motoren kommt man
da leicht in den MHz Bereich. Und wenn der Microcontroller keinen
eingebauten Quadratur-Decoder hat, dann kann das schon knapp werden.

Ich habe sowas ähnliches voriges Jahr mal in VHDL implementiert:

http://www.mikrocontroller.net/topic/202869#2007538

Zusammen mit einem Microcontroller für USB, wie ich bei diesem Board
hier eingesetzt habe:

http://www.ohwr.org/projects/c64cartridge/wiki

sollte sowas aber einfach realisierbar sein. Der Microcontroller hat
auch einen RS232 TTL Ein-/Ausgang. Habe leider keine Zeit dazu im
Moment, aber habe hier noch ein paar von den ersten Prototyp-Boards
rumliegen (da immer 10 Stück Bestellmenge bei IteadStudio). Also wer
davon eins haben möchte, bitte melden. Den CPLD und den Microcontroller
kann ich auflöten. Man braucht aber noch ein Xilinx Platform Cable, um
den CPLD zu programmieren, den Microcontroller kann man direkt per USB
per Software programmieren.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

[Stefan]

Am 11.03.2012 17:53, schrieb Frank Buss:

> Gernot Fink wrote:

>> Die am besten funktionierende Lösung wird aber der Microcontroller bleiben.
>
> Könnte je nach Geschwindigkeit durchaus schwierig werden, denn bei 3600
> Inkrementen pro Umdrehung und z.B. schnell drehenden Motoren kommt man
> da leicht in den MHz Bereich. Und wenn der Microcontroller keinen
> eingebauten Quadratur-Decoder hat, dann kann das schon knapp werden.

Na ja, bei 3600 x 3000 U/min kommt man auf ca. 200 kHz. Das geht mit nem
ATmega oder nem PIC problemlos, zumindest mit dem Einphasentakt des OP.

Ich beschäftige mich gerade mit einem ähnlichen Problem. Dabei geht es
darum, Frequenzen im Bereich 50kHz in ca. 100ms mit einer Auflösung von
besser 1 Hz zu messen. Das werd ich wohl über eine Periodendauermessung
über einige tausend Perioden machen.


Gruß

Stefan

[Gernot Fink]

In article <jjil9g$u4e$1...@newsreader4.netcologne.de>,
Frank Buss <f...@frank-buss.de> writes:

> Gernot Fink wrote:
> Könnte je nach Geschwindigkeit durchaus schwierig werden, denn bei 3600
> Inkrementen pro Umdrehung und z.B. schnell drehenden Motoren kommt man
> da leicht in den MHz Bereich. Und wenn der Microcontroller keinen
> eingebauten Quadratur-Decoder hat, dann kann das schon knapp werden.

Ich hab das " nur eine Drehrichtung, 3600 Inkremente pro 360 Grad" mit
Standardkomonenten als einfachen Zähleingang gesehen.

Ein AVR mit Quadraturzähler währ natürlich was. Das scheint es sogar bei
größeren versionen zu geben. Ich hab das auch schon im CPLD gemacht um der
Positionserfassung eines SMC3 servocontrollers etwas Dampf zu machen.
Die Datenübergabe läuft über ein 16 bit Schieberegister im CPLD.

OP liest sich aber so als kommt sowas nicht in Frage.

--
MFG Gernot

[Frank Buss]

Stefan wrote:
>
> Na ja, bei 3600 x 3000 U/min kommt man auf ca. 200 kHz. Das geht mit nem
> ATmega oder nem PIC problemlos, zumindest mit dem Einphasentakt des OP.

Stimmt, nur eine Drehrichtung ist einfach, man kann damit bei vielen
Microcontrollern direkt einen Zähler takten. Mit Implementierung der
USB-Seite auf dem PC usw. würde ein guter Programmiere sowas in 1-2
Tagen mit dem Code von meinem C64 Cartridge als Basis hinbekommen, wenn
der Sensor nicht zu intelligent ist, also kein spezielles Protokoll braucht.

[Gernot Fink]

In article <4f5cdd14$0$30112$8e6e...@newsreader.ewetel.de>,

Stefan <stefan@hier_steht_absichtlich_keine_EMail_Adresse_1234567890.de> writes:
> darum, Frequenzen im Bereich 50kHz in ca. 100ms mit einer Auflösung von
> besser 1 Hz zu messen. Das werd ich wohl über eine Periodendauermessung
> über einige tausend Perioden machen.

Dafür würde ich die captureeinheit mit dem Eingangsimpuls triggern.
Nach der Messzeit teilst du die Impulszahl durch die Zeit.
Falls du den capturetimmer per interrupt erweiterst musst du halt beim
abspeichern überprüfen ob ein ansteherner capturetimerÜberlauf zu
addieren ist oder nicht.

--
MFG Gernot

[Frank Buss]

Das ist viel zu ungenau für den Anwendungsfall. 50 kHz in 100 ms messen
bedeutet, daß man 5.000 Impulse pro 100 ms hat, also in diesem Fall 50
kHz, aber bei 5.001 Impulsen würde man schon 50.010 Hz ausrechnen, also
weit schlechter als 1 Hz Auflösung.

Man müsste schon wirklich die Länge der Perioden messen. Manche
Microcontroller können mit Quarztakt einen Zähler per externem Eingang
gaten, damit sollte das gehen, zusammen mit etwas zustätzlichem Aufwand,
wie die Vermeidung des Messens von Teilperioden. Nicht einfach nur mit
einem einfachen Microcontroller, ich würde da ja einen CPLD für nehmen :-)

[Stefan]

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.

Der Prozessor hat eine Capture-Unit, die mit einem 16 Bit Counter
verbunden ist. Der 16 Bit Counter wird mit dem Prozessortakt getaktet,
also mit ca. 10MHz entsprechend 100ns.

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. Gespeichert wird der Zählerstand am Anfang und nach 5000
steigenden Flanken, entsprechend ca. 100ms.

Die Differenz ergibt 5000 x Periodendauer. Diese wird dann mit 100ns
aufgelöst.


Gruß

Stefan

[Stefan]

Wenn es nicht zu schnell wird kein Problem. Zwei INT-Eingänge mit den
entsprechenden Routinen. Mit jedem Int wird die Flankenerkennung des
betreffenden Eingangs umgeschaltet. In der INT-Routine muss je nach
Zustandes des anderen Eingangs der Zähler incrementiert oder
decrementiert werden. Ich hab sowas mal mit WinAVR für ca. 25 kHz
gemacht. Das war dann aber auch so ziemlich die Grenze. Prozessortakt
war 16 MHz.

Gruß

Stefan

[Axel Schwenke]

Frank Buss <f...@frank-buss.de> wrote:
> Gernot Fink wrote:
>> Stefan <stefan@hier_steht_absichtlich_keine_EMail_Adresse_1234567890.de> writes:

>>> ... Frequenzen im Bereich 50kHz in ca. 100ms mit einer Auflösung von

>>> besser 1 Hz zu messen. Das werd ich wohl über eine Periodendauermessung
>>> über einige tausend Perioden machen.

Auch bekannt als Reziprokzähler.

>> Dafür würde ich die captureeinheit mit dem Eingangsimpuls triggern.
>> Nach der Messzeit teilst du die Impulszahl durch die Zeit.
>> Falls du den capturetimmer per interrupt erweiterst musst du halt beim
>> abspeichern überprüfen ob ein ansteherner capturetimerÜberlauf zu
>> addieren ist oder nicht.

Implementierung des Reziprokzählers, bei der die Capture-Einheit den
Referenzzähler ersetzt.

> Das ist viel zu ungenau für den Anwendungsfall. 50 kHz in 100 ms messen
> bedeutet, daß man 5.000 Impulse pro 100 ms hat, also in diesem Fall 50
> kHz, aber bei 5.001 Impulsen würde man schon 50.010 Hz ausrechnen, also
> weit schlechter als 1 Hz Auflösung.

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

Bis ~170kHz geht das mit z.B. einem AVR 8-Bitter komplett in Software.


XL

[Marte Schwarz]

Hallo Sven,

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...

Marte

[Sven Schulz]

Stefan wrote:
>
> Wie viele Daten musst du denn übertragen?

Siehe unten.

> Wenn ich das richtig verstanden habe, geht es zum einen um die
> Kommunikation mit einem intelligenten Sensor mit serieller
> Schnittstelle. Muss der irgendwelche Kommandos bekommen, oder sendet
> der selber?

Der sendet im Defaultzustand munter drauf los. Ich den Sensor aber mit
seiner 'eigenen' Software parametrieren.

> Ich nehm mal an, die Daten des intelligenten Sensors müssen mit den
> Daten des Drehwinkelgebers synchronisiert werden. Mit welcher
> Auflösung muss das passieren? Wer gibt den Takt vor, der
> Drehwinkelgeber, oder der intelligente Sensor?

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.

Beispiel:
Inc Sensor
400 63
401 63
402 63
403 63
404 25
405 25
406 25
407 72
408 72

> Hast du abgeklärt, ob
> der intelligente Sensor die Daten schnell genug liefert, d.h. sind
> die Laufzeiten irrelevant, oder gibt es dort möglicherweise ein
> Problem?

Der Sensor liefert Werte alle 1ms. 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).

>
> Warum nimmst du nicht einen PC mit zwei Schnittstellen?

Schlechte Erfahrungen mit Betriebssystemen die nicht ausdrücklich für den
Echtzeitbetrieb entwickelt worden sind ( z.B. M-$). Wenn ich mit einem
Realtime-OS anfange, kann ich das auch mit einer engebetteten Lösung
anfangen.

Sven

[Joerg]

Sven Schulz wrote:
> Stefan wrote:
>>
>> Wie viele Daten musst du denn übertragen?
>
> Siehe unten.
>
>> Wenn ich das richtig verstanden habe, geht es zum einen um die
>> Kommunikation mit einem intelligenten Sensor mit serieller
>> Schnittstelle. Muss der irgendwelche Kommandos bekommen, oder sendet
>> der selber?
>
> Der sendet im Defaultzustand munter drauf los. Ich den Sensor aber mit
> seiner 'eigenen' Software parametrieren.
>

Auch zwischenspeichern lassen mit Time Stamp und so?

>> Ich nehm mal an, die Daten des intelligenten Sensors müssen mit den
>> Daten des Drehwinkelgebers synchronisiert werden. Mit welcher
>> Auflösung muss das passieren? Wer gibt den Takt vor, der
>> Drehwinkelgeber, oder der intelligente Sensor?
>
> 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.
>
> Beispiel:
> Inc Sensor
> 400 63
> 401 63
> 402 63
> 403 63
> 404 25
> 405 25
> 406 25
> 407 72
> 408 72
>
>

Da sehe ich nicht so ein Problem, solange man das danach zu
regelmaessigen 1msec USB-Paketchen schnueren kann und nicht alles in
Echtzeit in den PC rueber muss.

>
>> Hast du abgeklärt, ob
>> der intelligente Sensor die Daten schnell genug liefert, d.h. sind
>> die Laufzeiten irrelevant, oder gibt es dort möglicherweise ein
>> Problem?
>
> Der Sensor liefert Werte alle 1ms. 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).
>

55usec in Echtzeit ohne Zwischenablage in USB Packets geht m.W. nicht
per USB. Das wuerde maechtig rumschlottern.

>>
>> Warum nimmst du nicht einen PC mit zwei Schnittstellen?
>
> Schlechte Erfahrungen mit Betriebssystemen die nicht ausdrücklich für
> den Echtzeitbetrieb entwickelt worden sind ( z.B. M-$). Wenn ich mit
> einem Realtime-OS anfange, kann ich das auch mit einer engebetteten
> Lösung anfangen.
>

Die Einteilung in 1msec (bzw. 125usec) Pakete hat allerdings wenig mit
dem OS zu tun sondern mit dem USB Standard. Der ist fuer Faelle wo
sofortige Reaktion des PCs in weniger als 1msec notwendig ist
(Regelschleifen et cetera) nicht geeignet.

[k...@familieknaak.de]

Marte Schwarz wrote:

> 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.

---<)kaimartin(>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53

[Joerg]

k...@familieknaak.de wrote:
> Marte Schwarz wrote:
>
>> 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 :-)

[Christian Zietz]

Joerg schrieb:

> 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

[Joerg]

Christian Zietz wrote:
> Joerg schrieb:
>
>> 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.

[Christian Zietz]

Joerg schrieb:

> 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.

[Joerg]

Christian Zietz wrote:
> Joerg schrieb:
>
>> 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.

[Frank Buss]

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. 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 :-)

[Heiko Nocon]

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.
>
>Beispiel:
> Inc Sensor
>400 63
>401 63
>402 63
>403 63
>404 25
>405 25
>406 25
>407 72
>408 72

[...]

>Der Sensor liefert Werte alle 1ms.

1kHz. Das ist nun wirklich absoluter Kinderkram.

>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...

[Stefan]

Am 12.03.2012 19:05, schrieb Heiko Nocon:
> 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.

>> 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.

Gruß

Stefan

[Stefan]

Am 12.03.2012 18:58, schrieb Frank Buss:

> 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 ;-)

Gruß

Stefan

[Thorsten Ostermann]

Hallo Sven!

> 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...

Gruß
Thorsten
--
PGP welcome!
Thorsten online: http://www.ostermann-net.de/electronic
Rund um Schrittmotor, Fräs-Bohr-Plotter & Mikrocontroller

[Axel Schwenke]

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.


XL

[Axel Berger]

Christian Zietz wrote on Mon, 12-03-12 16:55:

>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.

[Ralph A. Schmid, dk5ras]

Joerg <inv...@invalid.invalid> wrote:

>Aber Auktionskaeufe haettet Ihr vermutlich nicht gedurft :-)

Bei uns geht sowas mittlerweile, wenn auch immer die Buchhaltung die
Augen verdreht :)


-ras

--

Ralph A. Schmid

http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/

[Axel Berger]

Joerg wrote on Mon, 12-03-12 17:51:

>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.

[Joerg]

Ralph A. Schmid, dk5ras wrote:
> Joerg <inv...@invalid.invalid> wrote:
>
>> 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% :-)

[Klaus Butzmann]

Am 13.03.2012 15:30, schrieb Joerg:
> 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.



Butzo

[Michael Eggert]

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.

Gruß,
Michael.