Prelldauer bei Encoder (Drehimulsgeber)

[Andreas Hadler]

Gerald Oppen <Gerald.Oppen@web.de> wrote:

Nun lässt es sich nicht unter allen Umständen ausschliessen das
es immer richtig funktiert - bei normaler Bedienung aber schon.

[x] Du entwickelst modernste Technik

Wenn du Probleme hast, auszuschliessen, dass deine Produkte bei
normaler Bedienung immer richtig funktionieren, so wende dich doch
vertrauensvoll an mich.

Schwierig wird es, glaube ich, erst, wenn du sicherstellen musst, dass
sie bei normaler Bedienung nur ausnahmsweise richtig funktionieren

Andreas

--

Prosperity and ruin issue from the power of the tongue.
Therefore, guard yourself against thoughtless speech.

 

[Andreas Baier]

"Falk Brunner" wrote

"Andreas Baier" schrieb

Es geht nicht schief (siehe OT) - es funktioniert. Er hat nicht das
Problem
das es nicht funktioniert, sondern dass er es _garantieren_ will/muss.
Das
ist ein Unterschied.

Man bedenke. Ein Herzschrittmacher, der zu 99,9999 % funktioniert,
funktioniert 52 Minuten im Jahr nicht.
Wenn er es also GARANTIERT haben will, MUSS ein RICHTIGER Decoder ein.
Alles andere ist Augenwischerei und Selbstverarschung. Das Papier nicht
wert, auf dem es gedruckt steht.

Du wirst niemals jemanden finden der dir 100%-ige Funktion garantiert. Und
wenn sich etwas in der Praxis bewährt, dann ist es in der Praxis egal
wieviel theoretisch schiefgehen könnte.

Im übrigen siehts mit der "Hightech" nunmal in der Industrie so aus,
dass
die
Dinge technisch nicht perfekt ausgereift sein müssen - es zählt eben die
Go-to-Market Zeit.

Eine verdammt schlechte Ausrede für offensichlichen Murks.

Das ist keine Ausrede für Murks sondern Fakt. Schau dir dir Zahl an
Rückrufaktionen an! Es zählt schnell und billig! - Für einen
wirtschaftlichen Betrieb ist es natürlich langfristig lohnenswerter
qualitative Produkte zu produzieren (weil sie eben dann nicht hinterher den
SChrott bereinigen müssen...) - aber in der Realität ist das nicht immer so.

 

[Axel Berger]

*Rainer Ziegenbein* wrote on Thu, 05-07-14 22:20:

Huch?! Bei mir kommen da ca. 31 Sekunden heraus...

Ich war von der knappen Stunde auch überrascht, aber sie stimmt schon.

 

[Falk Brunner]

"Andreas Baier" <andreas-baier@web.de> schrieb im Newsbeitrag
news:JaIBe.8599$kr2.4047@news.cpqcorp.net...

Du wirst niemals jemanden finden der dir 100%-ige Funktion garantiert. Und
wenn sich etwas in der Praxis bewährt, dann ist es in der Praxis egal
wieviel theoretisch schiefgehen könnte.

Und wieso soll ich ein bekanntes Problem, für das es eine bekannte Lösung
gibt, nicht lösen?

Eine verdammt schlechte Ausrede für offensichlichen Murks.

Das ist keine Ausrede für Murks sondern Fakt. Schau dir dir Zahl an
Rückrufaktionen an! Es zählt schnell und billig! - Für einen
wirtschaftlichen Betrieb ist es natürlich langfristig lohnenswerter
qualitative Produkte zu produzieren (weil sie eben dann nicht hinterher
den
SChrott bereinigen müssen...) - aber in der Realität ist das nicht immer
so.

Tja, klingt eher so, als ob meine Aussage doch richtig ist.

MFG
Falk

 

[Falk Brunner]

Nachschlag zum Thema,

da ja anscheinend der Drehencoder für einen Bedienknopf verwendet wird, und
diese Bedieneinganben nicht sicherheitskritisch sind, kann man sicher ein
Auge zudrücken und sagen, dass gelegentliche Fehlauswertungen keinen
nennenswertes Problem darstellen.
Ich hab mal aus Neugier mit nem TDS210 gespielt (steht auf meinem
Schreibtisch). Wie es scheint ist dort auch die Billigversion der
Encoderauswertung drin, man kann z.B. die Zeitbasis durch kippeln am
Stellknopf verändern (will sagen, man kann mehrere Schritte vor und zurück
erreichen, ohne dass sich der Stellknopf wirklich weiterdreht). Also eine
verbreitete Lösung . . . hmmm.

MfG
Falk

 

[Rainer Zocholl]

(MaWin) 14.07.05 in /de/sci/electronics:

Ist wie meine miese (amerikanische?) echt-optische Maus, die oefters
von selbst ueber den Bildschirm laeuft, obwohl sie auf dem Mauspad
steht.

Gehäuse abbauen, innen mit Grafitspray aussprühen, zusammen bauen
und gut ist.
Vermutlich weil das Gehäuse sonst zu IR durchlässig war.
Die Maus spann aber nur, wenn die Sonne drauf schien.

Rainer

 

[Rainer Zocholl]

(Gerald Oppen) 13.07.05 in /de/sci/electronics:

Falk Brunner schrieb:

Ohje. ;-)
Und wieso?
Ein RICHTIGER Quadraturdekoer kostet 8 FlipFlops in der absolut
wasserdichten Deluxe Version!
Das wäre z.B. ein Job für nen kleinen CPLD, siehe andere Thread. Die
Dinger gibt auch in kleinen Stückzahlen für knapp 1 $.
Oder nen GAL 10V8, oder ganz hardcore, mit TTL Zeugs.

Ich habe keinen Einfluss (mehr) auf die Hardware und die ist auch
schon in grossen Stückzahlen verbaut.

Dumm gelaufen.
Dann kannst Du einfach nicht garantieren, das es nicht zu Fehlzählungen kommt.

Oder wie willst Du niederfreuentes Rauschen von einer sehr langsamen
Bewegung unterscheiden UND gleichzeitig schnell sein, denn der
Benutzer will nach max. 100ms eine Reaktion sehen.
Der Geber ist ganz offensichtlich nicht für diesen Zweck "nahezu stillstand"
gedacht.
Fehler wurden bisher nur nie bemerkt, wenn man bei der Handbedienung
bei einer Fehlinterpretation halt wieder zurückdreht und die
Schuld in seiner Hand sieht, so man des fehlers überhaupt gewahr wird.

Di Auswertung selbst ist kein Problem und funktioniert sehr
zuverlässig, es geht lediglich um die
Spezifizierung/Funktionsgarantie.


Das ist ein Widerspruch zur Billigversion. Die Billigversion geht
nur mit sauberen (prell- und jitterfreienfreien) Eingangssignalen
wie sie real nicht garantiert werden können.

Lässt sich mit guter Software (fast) alles ausbügeln.

Da fällt mie aus der Liste der "most dangerous things on the world" ein:
1. A softworker with a solder iron
2. A hardware with a software patch.

Nur scheitertet es an der fehlenden Spezifikation das auch in Zahlen
ausdrücken und weitergeben zu können.

Du brauchst einen Richtungsdiskiminator.
Das mit reiner Software machen zu wollen, ist, em, nett gesagt
mutig.
Es ist keinewswegs so trival, da es auch zu Signale kommen
kann, ohne das tatsächlich eine Bewegungs statt fand.
Wenn Du eine ständig drehende Achse hast und ein paar Fehlzählungen
im Stillstand nicht stören mag das gehen.
Darum gibt der Hersteller das ja auch -nur- bei Bewegung an.
Der weiss schon warum er das so definiert...

Du must aber eine langsamste Drehbewegung von dem Stillstand-"Rauschen"
unterschieden, und Dir darf vorallem nicht passieren, das
Stillstand-"Rauschen" nicht als Rauschen, sondern als Drehbewegung
interpretiert wird und Dir dann der Sollwert wegläuft.
Das erfordert schon eine recht ausgebuffte Hardware...
Ist dann lustig zusehen wie der Zähler immer plus 1 und minus 1
machte, obwohl nur wer laut sprach...


Allerdings:
Inkrementalgeber als Bedienelement sind oft mit
einer (impliziten) "freigabe/sperr-Taste" versehen.
Warum wohl?




Rainer

 

[Axel Schwenke]

=?ISO-8859-1?Q?Winfried_Buechsenschuetz?= <winfried.buechsenschuetz@freenet.de> wrote:

Falk Brunner schrieb in der newsgroup de.sci.electronics:

Nicht im Detail, aber
Inkremetalgeber liefern Quadratursignale, die im GRAY-Code laufen.

Nicht ganz richtig. Es gibt Encoder, die Quadratursignale (= 2
phasenversetzte Rechteckpulsfolgen, der Phasenwinkel - entweder + oder
-90 grd - gibt die Drehrichtung an), ODER solche mit Gray-Code.

Nope. Ein Gray-Code ist ein sequentieller Code mit der Eigenschaft,
daß benachbarte Codeworte sich in genau einem Bit unterscheiden.
Die üblichen Quadratur-Encoder liefern also einen 2-Bit-Graycode.


XL

 

[Winfried Buechsenschuetz]

Falk Brunner schrieb in der newsgroup de.sci.electronics:

Nicht im Detail, aber
Inkremetalgeber liefern Quadratursignale, die im GRAY-Code laufen.

Nicht ganz richtig. Es gibt Encoder, die Quadratursignale (= 2
phasenversetzte Rechteckpulsfolgen, der Phasenwinkel - entweder + oder
-90 grd - gibt die Drehrichtung an), ODER solche mit Gray-Code. Letztere
sind aber eigentlich keine Inkrementalgeber, sondern Absolut-Winkelgeber
- es läßt sich jederzeit (statisch) die Winkelposition bestimmen,
während bei I. mit Q.ausgang einmal bei Drehgeschwindigkeit 0 kein
gültiges Signal rauskommt und zweitens zur Absolutpositionsanzeige noch
ein Referenzsignal (meist Index-Signal) benötigt wird.

Winfried Büchsenschütz
--
Immer auf dem aktuellen Stand mit den Newsgroups von freenet.de:
http://newsgroups.freenet.de

 

[Falk Brunner]

"Winfried Buechsenschuetz" <winfried.buechsenschuetz@freenet.de> schrieb im
Newsbeitrag news:42d7eb7c$0$23467$9b622d9e@news.freenet.de...

Nicht im Detail, aber
Inkremetalgeber liefern Quadratursignale, die im GRAY-Code laufen.

Nicht ganz richtig. Es gibt Encoder, die Quadratursignale (= 2
phasenversetzte Rechteckpulsfolgen, der Phasenwinkel - entweder + oder
-90 grd - gibt die Drehrichtung an), ODER solche mit Gray-Code. Letztere

Bitte nochmal lesen und darüber nachdenken. Die Quadratursignale (um 90 GRad
versetzte Rechtecksignale) SIND GRAY-Code. Nur eben 2 Bit breit. Und damit
bei der Auswertung immun gegen Glitches, Prellen, etc. (sofen man die
RICHTIGE Dekoderschaltung verwendet).


MfG
Falk

 

[Michael Eggert]

Axel Schwenke <axel.schwenke@gmx.de> wrote:

Hi!

Nope. Ein Gray-Code ist ein sequentieller Code mit der Eigenschaft,
daß benachbarte Codeworte sich in genau einem Bit unterscheiden.
Die üblichen Quadratur-Encoder liefern also einen 2-Bit-Graycode.

Deshalb liefern sie ja auch ein _eindeutiges_ Signal, aus dem man
_eindeutige_ Informationen bekommen kann, so man denn will.

Wenn man alle Fälle auswertet, also:
1) A neg Flanke, B low -> links
2) A neg Flanke, B high -> rechts
3) A pos Flanke, B low -> rechts
4) A pos Flanke, B high -> links
dann kann auch nix passieren. Beschränkt man sich aus Bequemlichkeit
auf die ersten oder letzten beiden, hat man halt Pech gehabt.

Gruß,
Michael.

 

[MaWin]

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:e2dgd1p8ks6d4lko60j1gt5tc48taegsam@4ax.com...

Wenn man alle Fälle auswertet, dann kann auch nix passieren.

Doch, die Impulse koenne schneller kommen als die Auswerteschaltung
ihr folgen kann, und sei es wegen enistreuuung von Stoerungen.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Michael Eggert]

"MaWin" <me@private.net> wrote:

Hi!

Wenn man alle Fälle auswertet, dann kann auch nix passieren.

Doch, die Impulse koenne schneller kommen als die Auswerteschaltung
ihr folgen kann, und sei es wegen enistreuuung von Stoerungen.

Es ging um das Prinzip der Codierung und Decodierung, nicht um den
Aufbau.

Gruß,
Michael.

 

[MaWin]

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:dlphd1d1shfgj4pcdiagvmaqduu2ndc8vc@4ax.com...

Es ging um das Prinzip der Codierung und Decodierung, nicht um den
Aufbau.

Also andere Beschreibug fuer
'theoretisch funktioniert das, praktisch nicht'.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Michael Eggert]

"MaWin" <me@private.net> wrote:

Hi!

Also andere Beschreibug fuer
'theoretisch funktioniert das, praktisch nicht'.

Wenn das Deine Interpretation von "auch ein 2-bit Graycode ist
eindeutig" ist - bitte.

Gruß,
Michael.

 

[MaWin]

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:c3rhd15tdl49c8ht9hgrcoor7ot0n33b3e@4ax.com...

Wenn das Deine Interpretation von "auch ein 2-bit Graycode ist
eindeutig" ist - bitte.

Bei Gray-Codes werden ZUSTAENDE und nicht FLANKENWECHSEL ausgewertet,
und Gray wusste, warum er das tat, egal ob mit 2 oder 10 bit.
Deine Beschreibung redet von FLANKENWECHSELN (A neg Flanke etc.),
und die sind parktisch nicht zuverlaessig auswertbar.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Hartmut Schaefer]

Hallo Leute,

Bitte nochmal lesen und darüber nachdenken. Die Quadratursignale (um 90 GRad
versetzte Rechtecksignale) SIND GRAY-Code. Nur eben 2 Bit breit. Und damit
bei der Auswertung immun gegen Glitches, Prellen, etc. (sofen man die
RICHTIGE Dekoderschaltung verwendet).

es gibt allerdings auch mechanische Drehgeber (z.B. ALPS STEC16), die
zwar prinzipiell versuchen, Gray-Code zu erzeugen, meistens (abhaengig
von der Drehzahl) kommen dann aber sich nicht ueberlappende Low-Impulse
'raus (mit Rastung, von Rastung zu Rastung sollte es pro Kanal je einen
Low-Impuls geben (mit gegenseitiger Ueberlappung), die ein
Quadraturdecoder dann mit je +4 bzw. -4 pro Rastung zaehlen sollte). Da
kann die Gray-Code-Auswertung noch so funktionssicher sein, und zaehlt
bei den billigen Dingern dann trotzdem falsch. Da hilft dann nur
entweder zusaetzliche Hardware oder ziemlich fummelige Software.

Gruesse
Hartmut

 

[Gerald Oppen]

MaWin schrieb:

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:dlphd1d1shfgj4pcdiagvmaqduu2ndc8vc@4ax.com...

Es ging um das Prinzip der Codierung und Decodierung, nicht um den
Aufbau.



Also andere Beschreibug fuer
'theoretisch funktioniert das, praktisch nicht'.

Wennn Du das so argumentierst:
Die haushaltsüblichen Lichtschalter können (zumindest teilweise)auch in
eine Zwischenstellung gebracht werden in der ein "Dauerprellen" ensteht
- Glühlampen machen das nicht lange mit, der Schalter auch nicht und
unter umständen wird das ganze so heiss daas es zu einem Brand kommen
kann. In der Praxis ist diese Gefahr aber sehr gering.
Mein Inkrementengeber ist da erheblich weniger Sicherheitskritisch und
funktioniert bei üblicher Benutzung genauso gut wie ein Lichschalter.

Gerald

 

[Gerald Oppen]

Hartmut Schaefer schrieb:

Hallo Leute,


Bitte nochmal lesen und darüber nachdenken. Die Quadratursignale (um 90 GRad
versetzte Rechtecksignale) SIND GRAY-Code. Nur eben 2 Bit breit. Und damit
bei der Auswertung immun gegen Glitches, Prellen, etc. (sofen man die
RICHTIGE Dekoderschaltung verwendet).


es gibt allerdings auch mechanische Drehgeber (z.B. ALPS STEC16), die
zwar prinzipiell versuchen, Gray-Code zu erzeugen, meistens (abhaengig
von der Drehzahl) kommen dann aber sich nicht ueberlappende Low-Impulse
'raus (mit Rastung, von Rastung zu Rastung sollte es pro Kanal je einen
Low-Impuls geben (mit gegenseitiger Ueberlappung), die ein
Quadraturdecoder dann mit je +4 bzw. -4 pro Rastung zaehlen sollte). Da
kann die Gray-Code-Auswertung noch so funktionssicher sein, und zaehlt
bei den billigen Dingern dann trotzdem falsch. Da hilft dann nur
entweder zusaetzliche Hardware oder ziemlich fummelige Software.

Der Trick bei der Sache ist dass man (unter Berücksichtigung der
Prelldauer) immer dann auf den 2. Kanal schauen muss wenn der erste
einen Flankenwechsel macht. Umgekehrt geht das nicht! Ausserhalb des
Pegelwechsel (+kleines Zeitfenster) des ersten Kanals ist der 2. nicht
defniert und kann/darf beliebigen Pegel haben. Innerhalb bestimmter
Drehzahlgrenzen (auf den Handbetrieb abgestimmt) erhält man dann auch
einen sauberen Gray-Code...

Gerald

 

[Gerald Oppen]

MaWin schrieb:

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:c3rhd15tdl49c8ht9hgrcoor7ot0n33b3e@4ax.com...

Wenn das Deine Interpretation von "auch ein 2-bit Graycode ist
eindeutig" ist - bitte.



Bei Gray-Codes werden ZUSTAENDE und nicht FLANKENWECHSEL ausgewertet,
und Gray wusste, warum er das tat, egal ob mit 2 oder 10 bit.
Deine Beschreibung redet von FLANKENWECHSELN (A neg Flanke etc.),
und die sind parktisch nicht zuverlaessig auswertbar.

Bringt effektiv aber auch keinen Vorteil- Wenn man gerade im Schaltpunkt
stehen bleibt hat man auch hier das Problem eines Prellens.

Gerald