Noch'n kleines Projekt - WinTelex

damarco · #161

Der Anwender müsste also selbst umschalten anhand der Ausgabe des Druckers ?

#162

Fernschreiber hat geschrieben: ↑Do 10. Jul 2025, 19:04 Ich habe heute noch 10 andere Maschinen ausprobiert (keine mit Automatik), Bei Keiner verstellt sich die Tastatur durch Empfang von Bu oder Zi.
Du hast noch nicht erläutert wie das beim Empfänger gehen soll wenn Tastetur und Drucker völlig unabhängig sind. Mit welchen FS hast Du das ausprobiert?

Ich verstehe gerade nicht, was du meinst.

Ich habe hier einen T100 und einen T37 nebeneinander stehen. Wenn ich über i-Telex eine Verbindung herstelle und auf einem der beiden FS abwechselnd Bu und Zi drücke, dann schalten beide Fernschreiber die Ebene um. Das ist das Verhalten, das ich beschrieben hatte. Wie sollte das anderes sein?

Und die Tastatur empfängt doch nichts. Habe ich das irgendwo geschrieben? Das wäre dann ein Vertipper gewesen.

Aaaah! Ich glaube, jetzt dämmert mir, was du meinst. Du meinst, dass eine Tastatur nicht auf empfangene Bu oder Zi reagiert und dementsprechend auch keine Tasten blockiert. Nein, das funktioniert natürlich nicht, denn dann müsste es in den Tastaturen Relais geben, die die Schienen verstellen. Falls ich das irgendwo geschrieben habe, dann habe ich mich falsch ausgdrückt. Glaub mir, ich weiß, dass in den Tastaturen keine Relais drin sind.

#163

Hallo,
ja, die Physik will es so. Praktisch ist es ja kein großes Thema, wenn man merkt das die entsprechenden Tasten gesperrt sind, dann eben Zi oder Bu drücken, macht man während des Schreibens ja auch zwischendurch. Die Wahrscheinlichkeit liegt ja auch nur bei jeweils bei 50%. Der Zeichenspeicher bei automatik FS wird auch nicht von Empfangsdaten beeinflusst. Auch das Aussenden des KG ändert an der Tastaturebene garnichts, der macht zusätzlich sein eigenes autarkes Ding nebenher. Vor Text gehört am Begin ein Bu, vor Zeichen ein Zi. ich hab's gerade nochmal getestet zwischen LO15c und T100, Tastaturen bleiben bei beiden in der Ebene der letzten Aussendung, egal was empfangen wurde.

An Detlef:

Natürlich schalten die Drucker die Ebene um , aber nicht die Tastatur der Gegenstelle, die bleibt so wie vorher, das war doch das Thema.
Wenn Du vom T37 Ziffern sendest, steht die Tastatur bei diesem Gerät auf Zi, Da kannst Du vom T100 soviel Bu senden wie Du willst, am Ende
kannst Du vom T37 wieder nur Ziffern senden bis das Du da auch Bu drückst. Damit existieren am T37 gleichzeitig beide Ebenen. Darum ging es doch.
Selbst das Abfragen des KG des T37 ändert nichts, denn der läuft vollkommen nebenher.
Gruß
Willi

#164

Fernschreiber hat geschrieben: ↑Do 10. Jul 2025, 21:42 Damit existieren am T37 gleichzeitig beide Ebenen. Darum ging es doch.
Selbst das Abfragen des KG des T37 ändert nichts, denn der läuft vollkommen nebenher.

Nie im Leben wäre ich auf die Idee gekommen, die Tastatursperre als eigeständige Ebene anzusehen. Das spielt sich alles lokal innerhalb der Tastatur ab.
In WinTlx bleibt es daher bei einer Ebene. WinTlx verhält sich einfach wie ein FS ohne Tastatursperre. Denn der hat auch keine eigenständige Tastatur-Ebene.

damarco · #165

Bei dir detlef ist der Drucker das Problem jene bleibt in der letzten gesetzten Ebene hängen. Wenn weiterer Code der schon empfangen wurde gedruckt wird stellst die Ebene nicht wieder um.

An den Drucker wird Codiert das weiter gegeben was im Sender oder Empfänger anliegt. Wurde zuletzt ein ZI empfangen und man drückt lokal einen Buchstaben druckt dieser auch einen Buchstaben, Oder??? WinTlx druckt leider eine Zahl

.

Zwischen zwei WinTlx Verbindungen fällt das nicht auf weil du dann ein BU vor rann stellst.

Aus meiner Sicht muss die Ebene an den Drucker jene sein die im entsprechenden Teil vorliegt. Weil sonst die schon empfangenen bzw. gesendeten Daten nicht mehr decodiert werden können. Gegensenden gibt es ja auf Softwareebene nicht, die Daten landen im Buffer und man muss dann schauen wie man das löst. Wenn man die Daten trotzdem ausgibt kommt auf der Stromschleife der gleiche Käse heraus.

#166

Die Diskussion ist mühsig und dreht sich im Kreis. Das Verhalten von WinTlx ist an der Stelle korrekt und funktioniert ohne Gegenschreiben einwandfrei, da es keine getrennten Ebenen für Senden und Empfangen gibt.

Ich habe das jetzt mehrfach erläutert und von daher ist das Thema für mich durch.

damarco · #167

Habe gerade nochmals Editiert sorry, hat sich überschnitten. Gegenschreiben gibt es bei Softwarelösungen nicht, die Daten sind immer lesbar. Da wir eine Volldublex Verbindung über TCP/IP haben.

Die Daten dann zu drucken ist er dann eine Frage der Buffer, man die Ausgabe vom senden kurz stoppen den Emfangsbuffer ausgeben weiter schreiben. spätestens beim Zeilenende gibt auch hier ein Problem.

Wenn kein ACK mehr kommt lassen sich auch bei winTlx keine Zeichen mehr senden und es zeigt das die Gegenseite nichts empfängt da sie ja sendet und der Spuk hört auf.

#168

Ich glaube, du hast noch ein generelles Verständnisproblem, wofür WinTlx gedacht. Damit werden reale Fernschreiber angerufen, die über Zweidraht-Halbduplex angebunden sind. Daher ist es am Ende immer eine Halbduplex-Verbindung.

Reiner Fullduplex-Betrieb wird von WinTlx schlicht und einfach nicht unterstützt.

Ich habe nicht geplant WinTlx für theoretische andere Einsatzzwecke zu optimieren und Dinge einzubauen, die es im normalen Fernschreibbetrieb nicht gibt. Für Verbindungen von Rechner zu Rechner kann man übrigens auch einfach Telnet nehmen.