Kronos - Raspi Motorsteuerung
#1
Ich hatte im Bilderthread ja unter anderem mein 'Spaceship' mit Souther Lineartonarm vorgestellt.
Ich habe dazu nun den Motor und die Steuerung noch einmal überarbeitet.
Straylight frugte mich da nach Details zur Steuerung.

Es wird ein bischen technisch, theoretisch, (philosophisch).
Ich versuche meine Gedanken dabei verständlich wiederzugeben. 

Vorab, das 'Spaceship' hat mit meinem Denon DP6000 den besten Gleichlauf aller meiner 8 Plattenspieler.

   

Hammer! 
   

Wir reden hier von einem Riemengetriebenen Laufwerk mit Teller/Lager, die  aus einem über 60 Jahre alten Rek-o-kut stammen. Das Motorpulley ist in Harz gegossen und mittels einem Dc Motor mit 12000rpm rund gedreht. 
Die Größe des Pulleys ist so ausgelegt, dass die Sinusfrequenz bei 33.33 Umdrehungen bei ca 50hz liegt. 

Der Motor ist ein Mitsumi 7.5° stepper Motor MSP42...  (Gebraucht für 5€ gekauft, liegt aber neu auch nur um die 30€)
Der Stepper Motor läuft mit einem schönen Sinussignal absolut rund, ähnlich den gerne bei Riemenlaufwerken genutzten Synchronmotoren. Die Geschwindigkeit bleibt auch ohne Regelung ziemlich stabil. 

Ich bin von Beruf Programmierer, lag also nahe, dass ich da was selbs entwickel.
Allerdings programmiere ich Warenwirtschaftssysteme. ibm iseries und SAP abap.
Mit Raspberry/Python hatte ich bislang noch keine Erfahrung. 

Deshalb hat die erste Version zwar funktioniert, war aber recht hemdsärmlig realisiert.

Anfangs wusste ich nicht, wie ich den phasenverschobenen Sinus in Python generieren kann. Also habe ich aus meiner programmierten Gui heraus einen passenden Sox Befehl abgesetzt. Funktionierte einwandfrei. Aber Geschwindigkeitseinstellungen bzw. Korrekturen kann man so schlecht durchführen. Es muss erst der alte Sox befehl beendet werden um dann einen neuen korrigierten abzusetzen.
Daher resultiert auch der Kalibrierbutton in der Gui. Erkannte Abweichungen kann man damit gezielt korrigieren.
Allerdings hört man das bei laufender Platte deutlich. Die neue Sinusfrequenz habe ich dabei als neuen default abgespeichert. Ist also eher für nach einem Riemenwechsel oder nach versetzen des Motors gedacht. 

Das sollte besser werden.
Mittlerweile weiss ich wie ich im Python das Sinussignal generieren und in Echtzeit ändern kann.

Für die automatsche Geschwindigkeitsanpassung ist es natürlich wichtig die exakte Geschwindigkeit zu kennen.
Dazu sind im Tellerrand 8 Reflektoren eingebaut, die von einem IR Reflektionssensor abgetastet werden.
Alle Messungen und korrekturen werden also 8mal pro Umdrehung (alle 0.275 sec bei 33rpm) durchgeführt. 

Die Geschwindigkeitsmessung ist dabei gar nicht so einfach. 
Wenn man die Geschwindigkeit von einem bis zum nächsten Reflektor misst, müssen diese exakt, (also wirklich exakt! Bruchteile von einem mm) den gleichen Abstand zueinander haben. Sonst werden einem Schwankungen angezeigt, die gar nicht vorhanden sind.

Das bekommt man zu Hause definitiv nicht hin.

Deshalb messe ich immer die Geschwindigkeit einer vollen Umdrehung. Also von einem Messpunkt bis zu ihm selbst. Der Messabstand ist dann immer gleich, also eine volle Umdrehung.
Die Messungen laufen dann 8 mal parallel. Bei jeder 1/8 Umdrehung habe ich die Geschwindigkeit der letzten vollen Umdrehung. Ist zwar etwas träger, aber esgibt keine künstlichen Schwankungen. 

Das Sinussignal wird übrigens über den Line Out an einen kleinen Digitalverstärker ausgegeben und über die Lautsprecher Anschlüsse an den Motor geschickt.

Geschwindigkeitskorrektur.
Wenn an einem Messpunkt eine Abweichung festgestellt wird kann man leicht ausrechnen wie die Zielfrequenz aussehen muss um die Sollgeschwindigkeit zu erreichen. 
Aber....
Passt man dann die Sinusfrequenz entsprechend an ist bei der nächsten Messung (1/8 Umdrehung später) die Geschwindigkeit auf Grund der Trägheit noch nicht erreicht. Man erkennt also immer noch, mehr oder weniger die gleiche Abweichung und korrigiert dann also noch einmal. Das führt dazu, dass über das Ziel hinaus geschossen wird. Es führt zu einem Pumpen rund um die Sollgeschwindigkeit. 

Es ist also alles gar nicht so einfach.

Ich habe das Problem folgendermaßen gelöst.
Ich korrigiere nur dann, wenn die Geschwindigkeit stabil ist. Also kein Beschleunigungs- oder Abbremsvorgang aktiv ist. Ich prüfe die Abweichungen der letzten vier Messungen zueinander. Dann leite ich die Korrektur ein indem die Differenz zur Zielfrequenz in 20 Schritten im Abstand von 0.1 Sekunden auf die aktuelle Frequenz aufgeschlagen wird. Die Korrektur dauert also 2 Sekunden. Erst wenn dann die Geschwindigkeit wieder gesettelt ist wird dann gegebenenfalls wieder eine Korrektur durchgeführt.
Ich habe das jetzt nicht begrentzt, das heißt die Sinusfrequenz wird auf zig stellen hinter dem Komma eingestellt. 
Die Geschwindigkeit bleibt so von Beginn bis Ende der Platte absolut stabil. 

Und so sieht das ganze auf dem Pi aus

   
Linke Seite Buttons für Bildschirm aus für ungestörtes hören,
Buttons für Bildschirmhelligkeit + / -

Rechte Seite Color. Es kann zwischen 3 Farbschemata geswitcht werden.
Bildschirmschoner aktivieren.
Geschwindigkeit anzeigen.
Lock Geschwindigkeit, aktiviert die Autokorrektur.
Calibrate,  zur definition der Grundfrequenz.

   
Mit aktivierter analogen Geschwindigkeitsanzeige.
0 = Sollgeschwindigkeit.
Jeder Skalenstrich sind 0,1% Abweichung

   
Anzeige Digital

   
Anderes Farbschema

   
Screensaver mit Restzeit Anzeige. Voller Balken startet bei 28min (33rpm) 
17min (45rpm) Wenn die Zeit abgelaufen ist stoppt der Teller.
Links neben der Skala sieht man am kleinen Pfeil, dass die Geschwindigkeitskorrektur abbremst. 

Hoffe das war alles soweit verständlich...
[-] Die folgenden 11 users Gefällt Spassgeneral's post:
  • Christophe77855, rowo, straylight, S. Custom, grossesj, Balkes60, Darkstar, HighEndVerweigerer, RO55, Jan, Hifijc
Zitieren Return to top
#2
(29.03.26, 20:47)Spassgeneral schrieb: Hoffe das war alles soweit verständlich...

Ich konnte deinen Gedankengängen größtenteils folgen... th_up

Nur Umsetzen hätte ich sie nie gekonnt...
Beste Grüße
Ralf

America last!  Tongue
Zitieren Return to top
#3
Ich sage es mal so: Respekt! Über so etwas musste ich mir noch niemals Gedanken machen.
LG
Ingolf
Zitieren Return to top
#4
Das hatte ich zu beginn auch nicht gedacht, dass da so viele Probleme im Detail stecken. 
Das programmiertechnische Probleme auftreten werden war mir klar, aber dass die Steuerung so tricky ist habe ich auch erst beim Doing gecheckt. 
Ja und dann sucht man halt nach Lösungen.
[-] Die folgenden 2 users Gefällt Spassgeneral's post:
  • Darkstar, RO55
Zitieren Return to top
#5
Wenn ich das richtig ausgerechnet habe, bekommst du 4,444 Messwerte pro Sekunde. Das ist nicht übertrieben viel.
Wäre es nicht besser, ein komplettes Stroboskop zu verwenden und nicht nur 8 Markierungen? Sind die Markierungen unter dem Teller?
Gruß

Jan

Si vis pacem, para bellum

Angeschlossene Dreher:
Denon DP-37F, JVC QL-Y55F, Technics SL-1300 , Revox B795 

Darf gehen:
Technics SL-Q 33, Sony PS 5550, Luxman PD-284

ToDos:
Sharp Optonica RP-5100, SABA PSP 910, Dual 1019, Dual 1219

[Bild: https://plattenspieler-forum.de/gallery/..._44_29.png]
Zitieren Return to top
#6
Hallo Großer Unbekannter Nr.1,

sehr schönes Projekt. Für Raspberry hatten wir das allerdings noch nicht. th_up

Wenn ich fragen darf...warum Regelung? Der Synchron- oder Steppermotor folgt doch dem Sinus, eine Regelung würde doch nur dem Riemenschlupf hinterherlaufen und für Unruhe sorgen.

LG
Martin

P.S. Womit (mal wieder) der Beweis angetreten wurde das Riementrieblersteuerungen bei sauberem Engeneering DD-Laufwerken durchaus ebenbürtig sind.
Alles nur eine Frage des Aufwands.
Roksan Xerxes / Artemiz / Ortofon Virtus und jede Menge anderes Geraffel
[-] Die folgenden 4 users Gefällt Erzkanzler's post:
  • rowo, RO55, Darkstar, Jan
Zitieren Return to top
#7
Ich kann hier bestenfalls staunend mitlesen und meinen Respekt ausdrücken.
Viele Grüße Christian
[-] Die folgenden 2 users Gefällt Darkstar's post:
  • rowo, RO55
Zitieren Return to top
#8
(30.03.26, 11:11)Erzkanzler schrieb: P.S. Womit (mal wieder) der Beweis angetreten wurde das Riementrieblersteuerungen bei sauberem Engeneering DD-Laufwerken durchaus ebenbürtig sind.
Alles nur eine Frage des Aufwands.

Meine Micro BLs (51 und 71) aus Anfang der 80er schaffen auch ohne viel Elektronik nach Datenblatt 0,025%. Und da gibt es noch einige andere Riemendreher, wie Michael/Spitzenwitz schon gezeigt hat. Die Mär von leiernden Riemendrehern glaube ich schon lange nicht mehr.
Beste Grüße
Ralf

America last!  Tongue
Zitieren Return to top
#9
Hui!
Gleich so viele Anmerkungen.

- warum mit dem Raspberry? Ich hatte noch 2 Stück mit Bildschirm rumliegen. Waren mal squeezebox clients.

- stroboskopring wäre sicher genauer. Aber der alte Teller hat natürlich keinen Stroboskopring.
  Ich habe da die 8 reflektoren selbst unter den Teller geklebt. Die vier impulse pro Sekunde reichen aber aus um
  den 3Kg trägen Teller zu kontrollieren. Bei einem masselosen 1kg direktgetriebenen Teller ist das was anderes. 

- ja, eigentlich läuft der Stepper mit der definierten Frequenz stabil. Aber der kleine Motor hat nicht sehr viel Durchzug. Natürlich regel ich da nur hinterher. Aber die Messungen mit der WOW App zeigen durchaus dass es dem Gleichlauf gut tut. Mit ausgeschalteter Autokorrektur sind die Werte nur halb so gut. (Wobei Werte von 0.04 immer noch top sind) 

- die Micro Seiki Bl xxx, ja laut Datenblatt hatten damals alle Plattenspieler Spitzenwerte. leg da mal die WOW App drauf. Da möchte ich die 0.025 gerne einmal sehen. 

Ob die App wirklich zu 100% die Tatsachen wiederspiegelt ist natürlich ungewiss. Auf meinem DP6000  sind die Messungen absolut plausibel. Und somit ist sie hier mein Maßstab. 

Wer mit senem Laufwerk bessere Werte mit der WOW App hat möge die hier gerne posten.
Ich bin gespannt.
[-] Die folgenden 1 user Gefällt Spassgeneral's post:
  • straylight
Zitieren Return to top
#10
Das größte Problem dürfte hier das Messmittel sein. Ich habe das schon mit unterschiedlichen Handys getestet und die Werte waren wie gewürfelt.
Mein Handy lieferte in den Achsen, die gar nicht verwendet wurden Werte von etwa 0,8 U/min. Dabei ist es offensichtlich, dass dies nicht stimmen kann, wenn es flach auf dem Teller liegt.
Rechnerisch kommt das Handy auf Schwankungen von 0,17%. Das halte ich bei dem JVC für sehr unwahrscheinlich.
Das größte Problem dürfte sein, dass wir das Handy bzw. den Sensor nicht so platzieren können, dass der Drehpunkt exakt an der rrichtigen Stelle sitzt. Dadurch ist das Gerät am Ende nicht in der Lage, im gefragten Bereich zu messen, da es selber ein höheres Messrauschen produziert
Gruß

Jan

Si vis pacem, para bellum

Angeschlossene Dreher:
Denon DP-37F, JVC QL-Y55F, Technics SL-1300 , Revox B795 

Darf gehen:
Technics SL-Q 33, Sony PS 5550, Luxman PD-284

ToDos:
Sharp Optonica RP-5100, SABA PSP 910, Dual 1019, Dual 1219

[Bild: https://plattenspieler-forum.de/gallery/..._44_29.png]
Zitieren Return to top


Gehe zu: