Prelldauer bei Encoder (Drehimulsgeber)

[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.
 Click to see the full signature
Reply to
Andreas Hadler
Loading thread data ...

"Falk Brunner" wrote

Das

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.

dass

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.

Reply to
Andreas Baier
*Rainer Ziegenbein* wrote on Thu, 05-07-14 22:20:

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

Reply to
Axel Berger

"Andreas Baier" schrieb im Newsbeitrag news:JaIBe.8599$ snipped-for-privacy@news.cpqcorp.net...

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

den

so.

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

MFG Falk

Reply to
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

Reply to
Falk Brunner

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

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

Reply to
Rainer Zocholl

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

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.

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.

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

Reply to
Rainer Zocholl

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

Reply to
Axel Schwenke

"Winfried Buechsenschuetz" schrieb im Newsbeitrag news:42d7eb7c$0$23467$ snipped-for-privacy@news.freenet.de...

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

Reply to
Falk Brunner

Hi!

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.

Reply to
Michael Eggert

"Michael Eggert" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

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/
 Click to see the full signature
Reply to
MaWin

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

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
Reply to
Winfried Buechsenschuetz

Hi!

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

Gruß, Michael.

Reply to
Michael Eggert

"Michael Eggert" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

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/
 Click to see the full signature
Reply to
MaWin

Hi!

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

Gruß, Michael.

Reply to
Michael Eggert

"Michael Eggert" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

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/
 Click to see the full signature
Reply to
MaWin

Hallo Leute,

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

Reply to
Hartmut Schaefer

MaWin schrieb:

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

Reply to
Gerald Oppen

Hartmut Schaefer schrieb:

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

Reply to
Gerald Oppen

MaWin schrieb:

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

Gerald

Reply to
Gerald Oppen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.