Das Rad muss ja nicht jeden Tag neu erfunden werden, aber in diesem Falle ja .....
Vorgeschichte:
Vor gut 1,5 - 2 Jahren gab es das Missgeschick, das bei einer Tandberg 9100 das Logik-Board zerbrochen wurde. Also wurde hier kurzum eine Laufwerks-Steuerlogik für einen µComputer geschrieben und die "Hardware-seitigen" Schnittstellen µComputer zu Steuerelektronik geschaffen. Bedingt durch eine extrem kostengünstige Ersatzmaschine des gleichen Types konnte dann die 9100 erfolgreich gerettet werden. Mal wieder umsonst das "Rad erfunden" .....
Vor kurzem ging dann an einer Tandberg 10X der Capstanmotor in die ewigen Jagdgründe ein. Da hier ein Ersatzmotor mangels Verfügbarkeit nicht aufzutreiben war / ist, kurzerhand den defekten Capstanmotor durch einen DC-Motor mit anschließender µComputer-Regelung erfolgreich ersetzt. Dazu wurde noch eine Art "Fernbedienung" für diese µComputer-Regelung getüftelt, die ebenfalls zur Ablaufsteuerung einen µComputer nutzt ....
Und im Ersatzteilager liegt noch ein "leicht misshandeltes" Laufwerks-Chassis (da war mal ein anderer nicht originaler Capstanmotor verbaut) einer 10XD OHNE Capstanmotor ............
Und dann der blitzartige Gedanke bei einer Tasse Kaffee:
*** Aktives Up-Cycling !! ***
In das "capstanlose" Laufwerk geht ein DC-Motor mit schon neuer Capstan-Regelung und Fernbedienung. Die "alte / neue" Laufwerkssteuerung auf Basis µComputer für die 9100 wird nochmal überarbeitet und angepasst. Der Aufwand ist überschaubar, zumal kaum Unterschiede zwischen der Laufwerkselektronik 9100 / 10X vorhanden sind. Die erforderlichen Schnittstellen liegen ja auch noch rum ..... Das gibt wieder Luft in der Ersatzteilkiste ......
Weiter drauf rumgedacht und dann zunächst auf dem gesamten "Steuerungs- und Regelkram" eine halbwegs beherrschbare Struktur gezimmert:
- Einsatz von drei µComputer die untereinander "kommunizieren" - wobei diese "Kommunikation" auf "Draht-Ebene" erfolgen soll - also OSI Schicht Minus 1 ... , ganz einfach gehalten ...
- Trennung des "Steuerungs- und Regelkram" in die drei Bereiche Capstan, Steuerung Peripherie und Laufwerkssteuerung
hierbei sind:
- Capstan-Regelung zu 100% fertig
- Steuerlogik zu 99,99998% fertig - quasi fertig ...
- Laufwerkssteuerung zu ca. 80% fertig - im kreativen Prozess .....
Wie der Thread-Titel schon sagt: Winterprojekt .... Insofern gibt es hier nur was Neues, wenn sich "Meilensteine" ergeben bzw. laufen.
Der erste Meilenstein ist, wenn Laufwerkschassis und alle Regelungen im Zusammenspiel laufen ......
Sozusagen Etappenziel, bevor es an die Elektronik geht ....
da bin ich aber mal gespannt wie du das mit den Ardurino umsetzt.
Wieso 2x 2560 ? Der 2560 hat 16x Analog Input Pins und 54 Digitale Pins. davon können 14 PWM. Ist das nicht ein bisschen groß oder benötigt die Tandberg für die Steuerung viele Analoge I/O
Die Trennung von Steuer- und Laufwerkslogik finde ich absolut logisch und in der Umsetzung überschaubarer. Was macht in deiner Planung ein ESP32 so besonders für die Capstansteuerung?
(29.09.2026, 08:34)micha-uhl schrieb: Muß man aus einem Tonbandgerät ein Rechenzentrum machen?
Micha
Ja, wenn man die originalen ICs für die Logik nicht mehr bekommt. Früher oder später werden sie vermutlich bei noch mehr Geräten ausfallen und so sind solche Projekte, vor allem wenn sie hier dokumentiert werden und auf preiswert verfügbaren Plattenformen wie dem Arduino laufen, eine tolle Möglichkeit, Geräte wieder funktionsfähig zu bekommen.
(29.09.2026, 08:34)micha-uhl schrieb: Muß man aus einem Tonbandgerät ein Rechenzentrum machen?
Leider ein vollkommen unnötiger Kommentar , wenn man nicht verstanden hat, daß es hier um den modernen Ersatz von nicht mehr verfügbaren Komponenten geht.
Jeder Tandberg Besitzer wird froh sein, daß es die Lösungen von Christian gibt, wenn er denn mal in die Bredouille kam einem verreckten Logic Board (oder bezugnehmen auf den 10X Beitrag) oder einen abgekachelten Motor gegenüber zu stehen.
ICH weiß das, weil das Thema Logic Board an einer 9141 hab ich ebenfalls durch und dank Christian hätte es Ersatz gegeben ... aber ich konnte noch Ersatz ICs bekommen.
29.09.2026, 14:29 (Dieser Beitrag wurde zuletzt bearbeitet: 29.09.2026, 15:48 von wamamebo.
Bearbeitungsgrund: Korrektur
)
Erstmal danke für das Echo. Dieses "Winterprojekt" lebt auch ein bischen mit von der Diskussion ....
Grundsätzlich zu den Tandberg's:
Geht das Logikboard - egal ob Series 9xxx oder 10X/XD - in die ewigen Jagdgründe ein oder es müssen diese schwer zubeschaffenden fast nicht mehr verfügbaren Teledyne-Logik-Bausteine ersetzt werden kann so eine Tandberg ganz schnell zum Alptraum werden .... Platinen lassen sich ggfs. flicken - außer bei der 9000, die ist doppelseitig - oder neu anfertigen.
Geht der Capstanmotor einer 10X/XD in die ewigen Jagdgründe ein - ist die Maschine ein Fall für das Ersatzteillager. Dieser dort verwendete Siemens-Motor 1AD41xxxxxx ist - so der heutige Stand - nicht mehr verfügbar. Und die Siemens-Motoren 1AD31xxxxxx (z.B. aus einer ASC etc.) laufen nicht - nach hier durchgeführter Erprobung - an der originalen Capstanregelung der 10X/XD. Also müsste - wenn dann die originale Capstanregelung der 10X/XD auf die Eigenschaften des Motors 1AD31xxxxxx angepasst werden - mit dem "unschönen" Nachteil, das wieder bei einem Exoten-Capstanmotor "gelandet" wird und dem Zweifel ob das auf Dauer funktioniert .....
Als "Ersatz" für diese beiden Dinge lassen sich HEUTE "relativ einfache" Lösungen "stricken" .... die - dann im querschnittlichen Aspekt betrachtet - auch auf andere Maschinen anwendbar sind. Deshalb auch der Satz am Anfang dieses Thread's mit der Erfindung des Rades ....
Doch zurück zum Winterprojekt TD30:
Zitat:Geschrieben von Olivinyl - Gestern, 20:19
Hallo Christian,
da bin ich aber mal gespannt wie du das mit den Ardurino umsetzt.
Wieso 2x 2560 ? Der 2560 hat 16x Analog Input Pins und 54 Digitale Pins. davon können 14 PWM. Ist das nicht ein bisschen groß oder benötigt die Tandberg für die Steuerung viele Analoge I/O
Die Trennung von Steuer- und Laufwerkslogik finde ich absolut logisch und in der Umsetzung überschaubarer. Was macht in deiner Planung ein ESP32 so besonders für die Capstansteuerung?
Auswahl der µComputer:
ESP32 für die Capstanregelung
benötigte PIN / Anschlüsse:
4 x Schalter Geschwindigkeitsumschalter (4,75 / 9,5 / 19 / 38)
1 x Schalter Pitch Ein/Aus
1 x Analog IN für Poti Pitch
1 x IN (Interruptfähig) für Lichtschranke sprich Tachosensor
1 x PWM-Out
1 x Life-Line OUT (optional) - signalisiert den nachfolgenden Regelungen "Capstanregelung ist da - oder auch nicht ...."
1 x Speed-Change OUT (optional) - signalisiert den nachfolgenden Regelungen "Achtung Speed-Change"
----
10 x PIN erforderlich
ESP32 für die Capstanregelung deshalb, weil dieser Chip ein gänzlich anderes PWM-Interface hat als der Arduino, welches WESENTLICH komfortabler ist hinsichtlich Code-Handling, PWM-Signal Eigenschaften etc. . Die jetzige ESP32-Regelung verwendet eine PWM-Frequenz von 22 Khz bei einer Auflösung von 0 - 2047. .... DAS mit dem Arduino ..... Viel Spaß ....
Die genauen technischen Details sind im Thread "Tandberg 10X/XD Capstanmotor Umbau von Original zu Fälschung" beschrieben.
Arduino Mega 2560 für die Speedregelung:
benötigte PIN / Anschlüsse:
1 x Life-Line Capstan IN
1 x Life-Line Capstan OUT
1 x Speed-Change Capstan IN
1 x Speed-Change Capstan OUT
4 x Taster Speed
4 x Taster Beleuchtung
4 x Steuer-Line zur Capstanregelung
4 x Schalter für Tape/Source- , Capstan An/Aus -, Record/Play- und NAB/IEC-Umschaltung
1 x Steuer-Line Record/Play zur Laufwerksregelung
1 x Steuer-Line Tape/Source
1 x Steuer-Line Capstan An/Aus
1 x Steuer-Line NAB/IEC Umschaltung
1 x Steuer-Line 38 cm brücken Vorwiderstand Windmotor (10X/XD spezifisch)
plus zusätzlich optional (Softwareanpassung erforderlich)
5 x Steuer-Line ( ggfs. für VU-Umschaltung, Steuerung Elektronik etc.)
----
max. 30 PIN benötigt plus ggfs. für die "Deluxe-Version" mit LCD-Display 32 PIN .....
Damit fällt der Arduino NANO / UNO aus. Die entsprechende "Steuerlogik" hierfür ist geschrieben ......
Arduino Mega 2560 für Driveregelung:
benötigte PIN / Anschlüsse (Bezug: Laufwerk 10X/XD):
1 x Life-Line Capstan IN
1 x Speed-Change Capstan IN
1 x Steuer-Line Record/Play von Speedregelung
1 x Steuer-Line Record-Indicate ( es kann ggfs. aufgenommen werden, sprich Taste Record geht .....)
5 x Taster für Stop, Play, Record, Wind, Rewind
5 x Lampenleitung
2 x Pinch-Solenoid
2 x Brake-Solenoid
1 x Wind-Relais
1 x Rewind-Relais
1 x Steuer-Line Löschoszillator (die MUSS aus dieser Regelung kommen !!!!)
plus zusätzlich optional (Softwareanpassung erforderlich)
1 x Schalter "Erase by Wind/Rewind" (während Umspulen Band löschen)
1 x Lampe dazu
2 x "Deluxe Version" mit LCD-Display
----
max. 25 PIN benötigt inkl. "Deluxe-Version" ....
Zur Sicherheit Arduino Mega 2560, falls noch was dazu kommt ( dann ist der NANO / UNO zu klein ......). Die Steuersoftware liegt in den "letzten Zügen" - nur noch ein paar Kleinigkeiten wie Tastenverriegelung etc.
Rechnet man jetzt beide 2560 zusammen so brauchts 57 PIN - 2 PIN Abzug für Display - macht 55 PIN ... Käme somit mit einem Mega 2560 hin ...... Plus der Umstand, das dann beide Regelungen (Speed und Drive) auf EINEM Arduino laufen sollen ....... Hinsichtlich Timing-Verhalten aller beteiligten und unbeteilgten Komponenten etc. ist das der "Gordische Knoten " .....
Daher dieser Ansatz das so und mit den o.a. µComputer zu machen, alles andere ist nicht zielführend ..... Zielplattform für die Softwareentwicklung ist dann immer die 10X/XD mit dem Ansatz das querschnittlich auszulegen und auch so zu codieren .... Und bei der eigentlichen Codierung wird sich nach Möglichkeit an die Maßgabe "Clean Code C++" gehalten, damit das nachvollziehbar wird und ist. Selbiges gilt für die elktrischen Schnittstellen etc. : So einfach wie nötig und möglich !!
Wesentlich anders geht es bei diesem "Winterprojekt" eh nicht .....
Wir sollten Dankbar sein dass es Leute wie Christian gibt welche sich die Mühe machen lieb gewordene Geräte weiter betreiben zu können.
Ich finde das Projekt sehr gut.
Gruß Mani
Besonders gerne repariere ich meine Philips, Braun, Akai und TEAC Geräte
Keine Hilfe bei fehlender Rückmeldung
das der ESP32 eine PMW bis 22kHz kann, war mir nicht bekannt. Hab mich gerade schlau gemacht und war überrascht das der Uno gerade mal 490/980 Hz schafft und für meine Anwendungen war das bis jetzt ausreichend.
Die beiden neuen "Arduino-Logikboards" sind ja tatsächlich fast komplett belegt. Ich hatte nicht gedacht das bei der Tandberg sooooo viele einzelne Steuerimpulse eingehen und wieder weiter verarbeitet.
Auf jeden Fall ein tolles Projekt und äußerst interessant. Ich werde dir auf jeden Fall neugierig folgen.
Spannendes Projekt
Das Thema Laufwerksteuerung muss ich für mein TG 4 Projekt (Tonbandgetät im Braun Atelier Gehäuse) auch angehen. Aber erst muss mal die Hardware stehen.
Warum fasst du nicht manche Signale zusammen? Die 4 Geschwindigkeiten kannst du auch mit 2 Leitungen realisieren
4,75: 00
9,5 : 01
19 : 10
38 : 11
sicherlich ginge das auch mit 2 Leitungen (unabhängig der daran anschließenden Auswertelogik, die dann immer mit dem geschalteten Zustand der anderen Leitung zukämpfen hat, da dann die Leitung egal ob 0 oder 1 immer ein Steuersignal gibt - es sei denn man macht das über UART, I2C oder ähnlich) , ABER:
Die Capstanregelung arbeitet autark, da sie als Ersatz für eine originale 10X/XD Tandberg-Capstanregelung konzipiert wurde und auch so in diesem Hard- und Softwarezustand bleiben soll. Die Geschwindigkeitsumschaltung bei der 10X/XD arbeitet ja mit dem Speed-Schalter, der u.a. auch die Entzerrung der Playback- / Recordamplifier gleichzeitig zur Capstanrgelung mit schaltet. Und diese "neue" Capstanregelung sollte "Minimal-Invasiv" in die 10X/XD passen, d.h. bestehende und existierende Verkabelung wurde mitgenutzt - insbesondere die vom Speed-Schalter zur Capstanregelung gehende .....
Dummerweise ist dieser Speed-Schalter der 10X/XD kurzschließend beim Umschalten zwischen den Schaltkontakten, was gelegentlich zu nicht definierten Schaltzuständen der Capstanregelung führen KANN - NICHT ZWINGEND MUSS. Das ist zwar vernächlässigbar aber unschön ..... Abhilfe wäre hier ein Austausch des Speed-Schalters oder Umsetzen der Steuersignale auf nicht kurzschließend über eine kleine separate Relaissteuerung o.ä. Deshalb wurde hier eine Speed-Control-Logik mittels TASTER (und nicht mehr SCHALTER) entworfen, die diese "Unschönheit" beseitigt. In diese Speed-Control-Logik sind dann auch die Schalter für Record Select, Tape-Monitor, Umschaltung NAB/IEC, Schalter Capstanregelung AN/AUS gewandert, weil dieses Projekt "TD30" einen ganz anderen elektrischen Unterbau hinsichtlich Playback- / Recordzweige bekommt. Und hier nur "vorgearbeitet" wurde .... Man war ja einmal dabei .....
Die eigentliche Laufwerks-Logik (Drive-Control) arbeitet komplett autark von der Capstan- und Speed-Umschalt-Regelung, da die Bandzugregelung des elektromechanischen Laufwerks der 10X/XD über den Windmotor erfolgt. Hier wird lediglich bei 19 und 38 ein Vorwiderstand zum Windmotor gebrückt .... An Einfachheit kaum zu überbieten ...... Capstan regelt Bandtransport, Vorwiderstand den Bandzug.
In diesem Fall (TD30) benötigt diese Drive-Control-Logik zwingend 2 Steuerleitungen bzw. Signale: Einmal Record-Select ist AN, d.h. es kann Aufnahme gestartet werden UND welche Geschwindigkeit hat sie gerade 9,5 oder 38 ?? Das ist elementar zur Steuerung des Bandzuges .... Und um das ganze rund zumachen, sind hier noch zwei zusätzliche Steuerleitungen reingekommen: 1 x Steuerleitung für Capstan AN/AUS; ist Capstan AUS geht Play/Record nicht und 1 x Steuerleitung Geschwindigkeitswechsel; findet eine Umschaltung der Geschwindigkeit statt so wird zunächst die Andruckrolle weg von der Capstanwelle geholt, Geschwindigkeit wird geändert, Andruckrolle wird wieder zur Capstanwelle bewegt.
Hintergrund hierzu: Die originale Capstanregelung arbeitet mit "Frequenz zu Volt Regelkreis" für den Capstanmotor. Diese Regelung ist elektrisch träge, insbesondere bis sie sich wieder "eingeschwungen" hat dauert das ca. 3 - 4 Sekunden. Die neue Regelung arbeitet mit PWM, d.h. der Capstanmotor wird schlagartig auf einen neuen PWM-Wert gesetzt und als Folge hiervon springt der Riemen ab, da die mechanische Trägheit zuschlägt. Also wird bei der neuen Capstanregelung ein "Fading" des PWM-Signals vorgenommen hin zu neuer Geschwindigkeit und somit der Riemen nicht springt. Und während dieser Fadingzeiten ist die Andruckrolle nicht an der Welle, so das der Geschwindigkeitswechsel in Ruhe und vollständig ausgeführt wird.
Als Basis für die Drive-Control-Logik gab es ja den "Prototypen" aus dem 9100er-Disaster. Mittlerweile ist dieser umgearbeitet und kann an die Maschine. Während dieser "Umarbeitung" wurde dann auch eine dreiteilige "Software-Struktur" bestehend aus Interaktion - Reaktion - Aktion geschaffen, damit der C++Code übersichtlich bleibt .....
Als Interaktion wird hierbei die Benutzeraktion gesehen, also welche Taste Stop, Play, Record, Wind, Rewind wird gedrückt. Die Auswertung erfolgt dann in der Loop(), die dann die Reaktion (was soll die Maschine machen: Stop, Play, Record, Wind, Rewind ?) in einer jeweils zugehörigen Funktion die eigentliche Laufwerks-Aktion aufruft. Unter Berücksichtigung des alten Maschinenzustandes. D.h. die "Lesart" der Reaktionen ist dann immer "Maschine kommt VON und soll ZU". Und die dann zu erfolgenden Aktionen werden aus der Reaktion gesteuert.
Die für einen Schritt erforderlichen Einzelaktionen sind dann auch wieder in maschinenbezogenen Funktionen (z.B. Wind-Relais AN/AUS) hinterlegt. Somit bleibt der Quellcode schön strukturiert und jede neue "Betriebsart" kann unter Berücksichtigung des alten Betreibsstandes gezielt und gesondert codiert werden.
In der Praxis sieht das dann so aus (hier Auszug Loop() ):
Code:
// Ergebnis Control-Line und Taster auswerten
// in Copy_Maschinen_Status_New steht der Zielzustand der Maschine
// also ob jetzt Stop, Play, Record, Wind, Rewind als NÄCHSTES kommt
if (Maschinen_Status_Change) {
switch (Copy_Maschinen_Status_New) {
case 0: // STOP
Reaction_Stop_Enable (Copy_Maschinen_Status_Old);
break;
case 1: // PLAY
Reaction_Play_Enable(Copy_Maschinen_Status_Old);
break;
case 2: // RECORD als Spezialfall - Funktion NUR wenn Enable_Record_Modus = true
if (Enable_Record_Modus) { Reaction_Record_Enable(Copy_Maschinen_Status_Old);}
else {Copy_Maschinen_Status_New = Copy_Maschinen_Status_Old; Maschinen_Status_New = Maschinen_Status_Old ;}
break;
case 3: // WIND
Reaction_Wind_Enable(Copy_Maschinen_Status_Old);
break;
case 4: // REWIND
Reaction_Rewind_Enable(Copy_Maschinen_Status_Old);
break;
case 10: // Capstanregelung weg
case 11: // PLAY UND RECORD SOFORT STOPPEN
Reaction_Stop_Enable (1);
Copy_Maschinen_Status_New = 0; // Lokale Kopie auf STOP setzen
Maschinen_Status_New = 0; // WICHTIG: Auch die globale Variable nullen!
break;
}
// Nach dem erfolgreichen Wechsel den alten Status aktualisieren
if (Copy_Maschinen_Status_New <= 4) {
Maschinen_Status_Old = Copy_Maschinen_Status_New;
}
Maschinen_Status_Change = false;
Button_Locked = false; // Tastenverriegelung INAKTIV setzen !!!
} // Ende zu Maschinen_Status_Change
dann die entprechende Reaktion z.B. Play:
Code:
// Zielzustand PLAY
void Reaction_Play_Enable(int Zustand_Old){
// Zuerst den Löschoszillator (BIAS) sicherheitshalber ausschalten
Action_Bias_ON_OFF(OFF, 0);
// Pinch_Roller_Hold noch aktiv = dann ist RECORD an
bool Pinch_Active = false;
Pinch_Active = Action_Status_Pinch_Hold();
switch (Zustand_Old) {
case 0: // Maschine kommt von Stop
break;
case 2: // Maschine kommt von Record
if(!Pinch_Active) {Action_Pinch_Lamps_Only(ON, OFF);} // Nur Lampen schalten
break;
case 3: // Maschine kommt von Wind
Action_Wind_ON_OFF ( OFF, OFF, 0);
break;
case 4: // Maschine kommt von Rewind
Action_Rewind_ON_OFF ( OFF, OFF, 0);
break;
}
if(!Pinch_Active) {
Action_Brake_ON_OFF( ON, OFF, 100);
Action_Pinch_ON_OFF( ON, ON, OFF, 100);
Action_Brake_ON_OFF( OFF, OFF, 0);
}
}
mit den zugehörigen Aktionen (Auszug):
Code:
// Pinch-Roller (Andruckrolle ....)
void Action_Pinch_ON_OFF( int zustand, int play_lamp, int record_lamp, int zeitspanne) {
digitalWrite(Pinch_Roller_Activate, zustand);
digitalWrite(Pinch_Roller_Hold, zustand);
digitalWrite(Lamp_Button_Play, play_lamp);
digitalWrite(Lamp_Button_Record, record_lamp);
if (zustand == 1) { delay(zeitspanne); digitalWrite(Pinch_Roller_Activate, 0);}
}
// Wind-Relais
void Action_Wind_ON_OFF ( int zustand, int wind_lamp, int zeitspanne) {
digitalWrite(Wind_Relais, zustand);
digitalWrite(Lamp_Button_Wind, wind_lamp);
delay(zeitspanne);
}
// Rewind-Relais
void Action_Rewind_ON_OFF( int zustand, int rewind_lamp, int zeitspanne) {
digitalWrite(Rewind_Relais, zustand);
digitalWrite(Lamp_Button_Rewind, rewind_lamp);
delay(zeitspanne);
}
// Schaltet NUR die Lampen für Play und Record, lässt die Magneten unberührt
void Action_Pinch_Lamps_Only(int play_lamp, int record_lamp) {
digitalWrite(Lamp_Button_Play, play_lamp);
digitalWrite(Lamp_Button_Record, record_lamp);
}
Das Ganze wird dann nur noch über ZWEI Konstanten ON ( = 1 ) und OFF ( = 0 ) beim Aufruf gesteuert und ggfs. ein Delay mit dazugegeben ....
Damit sollte das Timing-Verhalten der Elektromechanik wohl in den Griff zubekommen sein ..........
Zitat:Spannendes Projekt
Das Thema Laufwerksteuerung muss ich für mein TG 4 Projekt (Tonbandgetät im Braun Atelier Gehäuse) auch angehen. Aber erst muss mal die Hardware stehen.
Warum fasst du nicht manche Signale zusammen? Die 4 Geschwindigkeiten kannst du auch mit 2 Leitungen realisieren
4,75: 00
9,5 : 01
19 : 10
38 : 11
Hmmm, mal drauf rumgedacht:
Annahme:
µComputer A stellt diese 2 Leitungen bereit und µComputer B nimmt sie entgegen:
Compi A: Compi B:
Ltg1 = 0 In Ltg1 = 0 ==> 00
Ltg1 = 1 In Ltg1 = 1 ==> 01
Ltg2 = 0 In Ltg2 = 0 ==> 10
Ltg2 = 1 In Ltg2 = 1 ==> 11
Auswertung Compi B dazu:
wenn Ltg1 = 0 dann 00 ok - funktioniert ==> z.B. Auswahl = 4,75
wenn Ltg1 = 1 dann 01 ok - funktioniert ==> z.B. Auswahl = 9,5
wenn Ltg2 = 0 dann 10 ok - funktioniert ==> z.B. Auswahl = 19
wenn Ltg2 = 1 dann 11 ok - funktioniert ==> z.B. Auswahl = 38
Hmmmmm, Compi B MUSS grundsätzlich BEIDE Leitungen abfragen - ABER: Ist Ltg1 nicht 1, so liegt diese Leitung bei Compi B grundsätzlich auf 0, also ist bei Zustandsspeicherung in EINER Schaltvariablen dann 00 immer aktiv .... und bei Ltg2 ist dann analog dazu 10 immer aktiv. Also was nun ?? 00 oder 10 ??? Weil - selbst wenn Ltg1 physikalisch in Form von Draht weg entfernt wird, bleibt der Anschlußpin auf LOW also O, weil das der Default ist wenn an dem PIN nix anliegt und somit 00 wieder aktiv ist.
Da das ganze wie ein Binär-Addierer zulesen ist, wäre dann eine dritte Leitung erforderlich, die den Übertrag steuert:
wenn Ltg3 = 0 dann kein Übertrag ok - funktioniert ==> dann wird Auswahl bei Ltg1 entweder 00 oder 01
wenn Ltg3 = 1 dann Übertrag ok - funktioniert ==> dann wird Auswahl bei Ltg2 entweder 10 oder 11
Oder vertue ich mich hier ???
Weil, der Zustand der Leitungen 1 und 2 kann nur mit ODER abgefragt werden: also wenn ltg1 entweder 1 oder ltg1 gleich 0, dann frage ltg2 ab ==> damit wird ltg2 dauernd abgefragt ..
So, nochmal kurz zur 2 Leitungsgeschichte (weil vorhin im "falschen" Auswertemodus gedacht) :
Das kann man so machen:
Ltg2 = 0 und Ltg1 = 0 ==> 00, also 0 als Integer oder wie auch immer dann weiter
Ltg2 = 0 und Ltg1 = 1 ==> 01, also 1 als Integer oder wie auch immer dann weiter
Ltg2 = 1 und Ltg1 = 0 ==> 10, also 10 als Integer oder wie auch immer dann weiter
Ltg2 = 1 und Ltg1 = 1 ==> 11, also 11 als Integer oder wie auch immer dann weiter
Das wird funktionieren - kein Thema, ABER:
Tritt jetzt irgendwo im Zusammenspiel der µCompi ein Fehler auf, der auf "Fehlverhalten" der Steuerleitungen schließen lässt, so sind bei Nutzung von 2 Leitungen 2 Schaltzustände in Kombination zubetrachten und ggfs. nachzumessen, was zu "Verwirrung" führen kann - nicht zwingend muss. Bei Nutzung von 4 Steuerleitungen z.b. beim Speed / Capstan sind die Zustände der Leitungen eindeutig und nicht mehrdeutig. Das auf den querschnittlichen Aspekt umgesetzt bedeutet das bei Nutzung von 4 Steuerleitungen der Quell-Code NICHT geändert werden muss, wenn dort dann zu Testzwecken etc. mal ein Schalter/Taster rangeht. Bei Nutzung von 2 Leitungen ist dann eine vorherige Kodierung der Schalter/Taster erforderlich und ggfs. muss sogar der Quell-Code angefaßt werden. Es ist ein Abwägen ....
Im Endeffekt ist es egal, ob nun 2 oder 4 Leitungen - wobei die persönliche Präferenz zu 4 Leitungen geht und bleibt, weil es eindeutiger ist. Und sich Wege hinsichtlich Nutzung einer evtl. zusätzlichen Schaltstufe etc. an den Steuerleitungen offen gehalten werden. Irgendwas ist ja immer .....
ist das bei Einzelstati der Leitungen wirklich eindeutig? Es könnte ja immerhin sein, dass auch dann z. B. zwei Leitungen oder mehr gleichzeitig auf H gehen. Um dem zu begegnen, müsste man eine extra Prüfung vornehmen.
Man könnte auch pro Leitung drei Zustände verarbeiten, also L, H und Tristate. Dann hätte man bei zwei Leitungen 9 mögliche Zustände. Dazu ist halt auch eine spezielle Prozedur vonnöten. Auch könnte man für die Geschwidigkeiten eine Analogleitung verwenden, das hängt natürlich von der Steuerelektronik ab. Nur mal so als Tipp.
Zu den "Kommunikationswegen" zwischen zwei µCompi mal ganz allgemein (nach derzeitiger Kenntnis):
Meines Wissens nach gibt es drei Möglichkeiten so eine "Kommunikation" herzustellen:
- Direkte PIN-to-PIN Kommunikation über die digitalen PIN:
hierbei wird am empfangenden PIN (Input) ein Pulldown-/Pullup-Widerstand geschaltet. Entweder intern über die Anweisung pinmode(PIN, INPUT_PULLDOWN / UP) oder über einen externen 10 K Widerstand der direkt am Input-PIN nach Masse oder +Ub verschaltet ist. Damit hat diese Art IMMER einen elektrisch definierten Zustand von 0 oder 1. Der Sender steuert das über digitalwrite(PIN, HIGH bzw. LOW). Vorteil: extrem robust, einmal gesetzter Leitungszustand (Signal) bleibt erhalten. Abfrage beim Empfänger ist dann einfach der Leitungszustand ob HIGH / 1 oder LOW / 0 mittels digitalread(). Vorteil: Abfrage kann jederzeit gemacht werden, kein Polling etc. notwendig, extrem schnell, robust. Hinsichtlich Funktionsprüfung/Verifikation der Logik in der Software einfach prüfbar, weil dann nur Schalter/Taster an die Eingänge des Empfängers müssen .... Also reiner Funktionstest OHNE weitere Hardware wie Schaltstufen etc. möglich. Bei gebündelten Leitungen dann aber Einsatz von kodierten Schaltern/Tastern notwendig.
Hierbei ist dann auch egal, ob getrennte Leitungen genutzt werden oder "gebündelte" Leitungen mit einer Art "Multiplex-Verahren".
- Direkte PIN-to-PIN Kommunikation über die analogen PIN:
Hier gilt im Prinzip das Gleiche wie für die digitalen PIN, nur das hier dann auch "spannungsgesteuerte" Werte für unterschiedliche Schaltzustände übertragen werden können. Hierzu wird einfach das PWM-Interface genutzt und der sendende PIN erzeugt ein PWM-Signal, das dann in der Folge über einen Tiefpass an den Empfänger geht. Beispiel: Sender setzt analogwrite(PIN, 125) so ist die Spannung dann grob 2,5 Volt. Empfänger liest das ein über analogread() UND schiebt das in eine Auswertematrix dergestalt das hier die Bereiche abgefragt werden. In diesem Fall ist das gelesene Signal <512 dann ist z.b. Grübelkiste = 2, ist es < 256 dann ist Grübelkiste = 1, ist es gleich NULL dann ist Grübelkiste = 0. Damit lassen sich über eine Leitung mehrere Signale darstellen. Nachteil ist, das hierfür die Auswertematrix geschrieben werden muss und ein Austesten / Nachmessen zur Funktionsüberprüfung / Verifikation der Software nicht ohne weiteren Aufwand möglich ist.
- Kommunikation über I2C also die PIN SDA/SCL:
Damit wird ein BUS-System etabliert welches von allen daran angeschlossen µCompi benutzt wird. ABER: Es wird ein BUS-Master benötigt, der die entspechenden Kommunikationsanweisungen schreibt und die daran angeschlossenen Slave lesen nur. Mit "Tricks" können die Slave auch auf den BUS zurückschreiben. Problem ist, das die Signale nur einmalig geschrieben werden, somit nicht permanent sind. Somit ergibt sich ein "Polling" bei den Slave dahingehend, dass sie den BUS permanent auf Änderungen abfragen müssen ...
Wenn die Slave auch auf den BUS schreiben müssen, so können sich BUS-Kollisonen oder gar Zusammenbrechen des BUS ergeben ...... Vom Verständnis her hat I2C zwar den Vorteil, beliebig viele Anweisungen zuerzeugen, aber in der Folge wird die Umsetzung beim Empfänger komplexer.
Diese drei bekannten Möglichkeiten jetzt mal auf das "Winterprojekt" bezogen:
Es gibt DREI autarke Regelungen. Hierbei MUSS ggfs. eine Regelung wissen, was an der anderen gerade passiert um entsprechend reagieren zu können:
Beispiel:
An der Speed-Regelung wird der Schalter RECORD-SELECT aktiviert. Die Regelung registriert das und schaltet während des eingeschalteten Zustandes von RECORD-SELECT die entsprechende Ausgangs-Steuerleitung auf HIGH. Jetzt ist das zunächst vollkommen egal was an dieser Steuerleitung hängt (z.b. Transistorstufe, Glühlampe, LED oder ein anderer PIN eines µCompi). Sie liefert auf jeden Fall +5 Volt, das ist sicher und mittels DVM nachvollziehbar .....
Jetzt geht diese Ausgangsleitung an einen anderen µCompi als Eingang. Eingang liegt mit 10K Pulldown nach Masse, +5V kommen an und schalten den Eingang auf elektrisch stabil HIGH.
Der empfangende µCompi holt sich den Leitungsstatus und sagt nach Abfrage des Leitungsstatus : "Alles klar, da liegt jetzt HIGH ... ich mach mal ne Lampe an und schalte mir die RECORD-TASTE auf aktiv ". Jetzt ist es absolut egal ob die RECORD-TASTE gedrückt wird oder nicht - sie KANN benutzt werden. Liegt die Leitung beim Empfänger auf LOW (RECORD-SELECT wieder aus), dann ergibt sich nach Abfrage des Leitungszustandes: "Alles klar, da liegt jetzt LOW, ich mach die Lampe aus und schalte mir die RECORD-TASTE auf inaktiv". Diese Mimik gleich zu Anfang in die Loop() gepackt und fertig ist die Klamotte mit der Record-Taste. Ganz simpel, nachvollziehbar und robust. Und - wenn an diesen Eingang jetzt ein Schalter geht, der lediglich +5 Volt an den Eingang schaltet ist diese Mimik ohne Maschine testbar. Kein Polling, direkte Reaktion, nix mit Auswertematrix schreiben oder BUS-Befehle umsetzen ....
Und fast genauso funktioniert die originale Steuerlogik der 10X/XD - keine "Schnörkel" drin. Zielsetzung war und ist ja das Drive-Control autark an einem Laufwerk der 10X/XD betrieben werden kann und soll. Und somit als Ersatz für das Logik-Board dient. Und unter dieser Vorgabe sind genau die Steuerleitungen für Record-Select und den Vorwiderstand Windmotor erforderlich. Lediglich die VU-Meter Umschaltung müsste da noch rein, sowie das Anschalten der Schnittstellen zur Peripherie erfolgen. Und fertig.
beste Grüße
Christian
PS.:
Als Attachment ist mal der aktuelle Stand von Drive-Control beigefügt. Bitte beachten, das die drei Dateien ZUSAMMEN in EIN Verzeichnis müssen .... Diese Dreiteilung erfolgte aus Übersichtsgründen ...... Die Datei TD30_funktionen.pdf enthält die eigenlichen Steuerbefehle zur Hardware, Datei TD30_reaktionen.pdf beinhaltet die Auswertelogik bzw. setzen des Soll-Zustandes, TD30_Setup_Loop.pdf das Setup und Loop() - also die bereits erwähnte Dreiteilung zwischen Interaktion-Reaktion-Aktion auf "Datei-Ebene" ....
, wenn man nicht verstanden hat, daß es hier um den modernen Ersatz von nicht mehr verfügbaren Komponenten geht.
