Projekt piTelex - Vorstellung

[obrecht]

Hallo zusammen,

angeregt durch den Beitrag von Horst und die Erklärungen von Björn, und weil ich versuche, solche Zusammenhänge mit in die Doku zu nehmen, habe ich mal bei mir mit den Parametern

continue_with_no_printer, wru_id, wru_replace_always

gespielt. Die Default-Config sollte ja nach Björns Erklärung sein (für t100a mit HW KG und FSG NL):

Code: Alles auswählen

wru_id : "" 
wru_replace_always: false
continue_with_no_printer : false

Bei meiner "klassischen" piTelex-Installation mit RPiTTY/TW39 ergab sich erstaunlicherweise folgendes Bild:

Für ankommende Verbindungen funktioniert das prima, aber bei ausgehenden Verbindungen (getestet mit lokalen Gegenstellen und auch z.B. mit dem Wetterserver 727272) baut die Maschine die Verbindung auf, druckt den DateTime-Banner der Gegenstelle und beendet dann die Verbindung, weil der PrinterTimer abgelaufen ist ohne dass die Maschine als eingeschaltet gilt (obwohl sie läuft, sie druckt ja den Banner...).
Setze ich continue_with_no_printer auf true, ist alles gut, die Maschine läuft weiter; das logfile meldet dann die software emulation als eingeschaltet, aber da wru_id leer ist, passiert nichts weiter, und meine t100 spuckt bei Bedarf brav ihren HW-KG aus.

Trotzdem ist da doch in der Logik irgendwas faul. Eigentlich müsste auch bei abgehenden Verbindungen bei einer Maschine mit KG continue_with_no_printer auf false bleiben können (Proof of concept: Wenn der Parameter immer eingeschaltet werden muss, ist er obsolet )
Das Ganze habe ich noch bei der zweiten piTelex-Installation für meine t68d getestet mit demselben Ergebnis:
Ohne "continue_with_no_printer : true" Abbruch von ausgehenden Verbindungen nach Verbindungsbeginn und abgelaufenem PrinterTimer.
Das Ganze kann ich auch von Screen aus produzieren (eigentlich logisch...) und ein entsprechendes Logfile habe ich beigefügt (angewählte Maschine hat die 833538).

Ahja: Ich nutze den Branch ExperimentalFeatures-2022-01.

logfile.txt

telex.json.txt

Fragen:
@all: Beobachtet ihr Ähnliches?
@björn: Hast du eine Idee? Ist ggf. im txDevITelexClient oder Common was "übersehen" worden bei den ausgehenden Verbindungen, was im Serverteil für hereinkommende Verbindungen richtig funktioniert?

Fragen über Fragen, und das bei den Temperaturen....

[WolfHenk]

Jo, hier dito....

[Z80User]

Hallo Rolf,
das kann ich auch bestätigen, Telex läuft nur mit:

Code: Alles auswählen

continue_with_no_printer : true

Die Erkennung des Laufenden Motors müsste ja theoretisch über den fließenden Schleifenstrom stattfinden. Ist z.B. Paper Empty, polt PiTelex zwar um, der Schleifenstrom geht dann auf 0 -> Fehler. Ist die Schleife geschlossen, fließen die 40mA weiter -> Motor sollte ein sein

Gruß,
Horst

[obrecht]

Also.....
Die Frage ist doch, wie bei ankommenden FS erkannt wird, dass der PrinterTimer angehalten werden soll, und warum das bei abgehenden Verbindungen offensichtlich nicht passiert.

Ganz von vorne angefangen:

Bei TW39 fließen im Ruhezustand ein paar mA, was den Optokoppler in der Stromschleife kalt lässt, er schaltet nicht durch.

Bei ankommender Verbindung erhält piTelex über das Internet die Verbindungsanfrage und aktiviert das Relais, welches die Stromrichtung in der Teilnehmerschleife zum FSG umpolt. Das wiederum veranlasst das Fernschaltgerät, den angeschlossenen FS zu aktivieren, d.h. 230V einschalten und den Empfangsmagneten direkt in die Schleife zu schalten, wodurch der Schleifenstrom auf 40mA steigt. Der Optokoppler in der piTelex Hardware bekommt von dem Polaritätswechsel nichts mit, weil er hinter dem Umpol-Relais liegt, aber das Hochschalten auf 40mA führt zum Durchschalten des Optokopplers. Das kann als Rückmeldung "Maschine läuft" verwertet werden und zum Anhalten des Timers genutzt werden.

Bei ausgehender Verbindung wird vom FSG aus bereits mit Drücken der AT Taste der Schleifenstrom auf 40mA angehoben. Das kann aber nicht als "Maschine läuft" interpretiert werden ( bei TWM schon eher, weil der Drucker schon fürs Wählen aktiv sein muss). Bei TW39 schaltet sich die Maschine erst ein, wenn die Verbindung zustande gekommen ist und piTelex deshalb das Relais aktiviert zwecks Polaritätswechsel, den aber der Optokoppler wieder nicht mitbekommt.

Also müsste bei angehender TW39- Verbindung entweder eine rein softwarebasierte Zustandssimulation passieren oder einfach das Umschalten des Relais ausgewertet werden?

Ich kann irgendwie die Kriterien für den PrinterTimer bei TW39 nicht so recht nachvollziehen. Vielleicht kann mir jemand von euch meinen Denkhaken aufzeigen....

[obrecht]

Also müsste bei angehender TW39- Verbindung entweder eine rein softwarebasierte Zustandssimulation passieren oder einfach das Umschalten des Relais ausgewertet werden?

Muss natürlich heißen "bei ausgehender TW39- Verbindung"...
Sorry.

[JoeyD]

Bjoern,
Who is the technical person for the Pi-Telex TW39?
Here is what is happening.

I have 3 working pi-telex tw-39's that I built to the schematic in the wiki located at... https://github.com/fablab-wue/piTelex/wiki/HW_ILoop I used that schematic to build my breadboards/prototype boards. They are UGLY but work perfect.
I would like to have my prototype boards free to use again for another project so.....

I had 6 of the tw-39 boards made from the Files located at.....
https://github.com/fablab-wue/piTelex.s ... master/PCB
I built one of these and it does not function correctly.
It will not dial, (I can dial using the computer keyboard ESC AT then Number) I notice there is no connection from pin 31 to 13 on the cards I had made.

The schematic that is listed in the directory DOES not match the Schematic of the Card I had made.

I had another member on the list copy the schematic from the Card file used to make the TW39 that schematic
Matches the card (so someone needs to up date that file in the PCB directory.) I do not have Eagle.

The next problem is the card will connect and send and receive but lets say I type something like
ABCD the machine will print ABCD then will print some garbage "????" but exactly the same amount of garbage as the input.
This occurs from the local machine or the remote machine. If I call the machine and send ABCD I will get ABCD and "????" garbage. If I type it from that machines keyboard I will get ABCD and "????" garbage.
I tried changing the opto coupler and receive the same result.

The only difference I can see between my breadboard cards and the ones made from the pi-Telex directory are the
Transistors I used but that should not affect this. The TW39 Pitelex I used the recommended TIP41C
and on my Breadboard I used TIP47 like that schematic suggested also 1 capacitor is different it is 68pf and the TW39 that same capacitor is 100nf so again this should not be any sort of issue either.

All the other components are the same. So not sure what would be causing this echo condition on the card I had made.
I am using the same Pi Telex and the Same Teleprinter and DCU (You call it FSG in German) the only thing I have changed is
the "Hat Card for the Breadboard card. If I change it back to my UGLY Breadboard it works perfect.

JD

[BjoernS]

Guten Morgen zusammen,

das ist ne Menge Holz, ich fang mal an ... danke schonmal, Rolf, für die detaillierten Logs, das macht das Nachvollziehen einfach. Da ist aber wenig zu rätseln, das Problem ist wohl aktuell, wie es so schön heißt, "by design".

Vorab schonmal zur Struktur: Die Module funktionieren autark und haben alle einen eigenen Status (zu verfolgen über die _set_state-Zeilen). Sie können Kommandos senden und empfangen. Alles was ein Modul sendet, wird von der Hauptschleife an alle anderen verteilt. Das sind die Logzeilen von piTelex.__main__. (Ausnahme: MCP fängt das ein oder andere ab, von dem die anderen nichts mitbekommen sollen).

So auch hier das ESC-A ('\x1bA'), das Kommando zum Einschalten des FS, das hier vom i-Telex-Modul kommt, sobald die Verbindung steht. txDevMCP macht es sich einfach: Sobald ESC-A kommt, startet es einen Timer. Bis zum Ablauf des Timers muss das Hardwaremodul (hier txDevRPiTTY) die Bestätigung des Druckerstarts gesendet haben (ESC-AA). Bleibt die aus, wird die Verbindung durch MCP getrennt.

txDevRPiTTY sendet diese Bestätigung nur dann, wenn der mit pin_line_observer konfigurierte GPIO high wird (oder low bei gesetztem inv). Der Line Observer (LO) ist ein Objekt, das mit der GPIO-API den Zustand des GPIO im Hintergrund verfolgt. Im Log kann man das gut sehen -- es gibt dazu drei "geschwätzige" Kommandos, die sonst keinen Effekt haben, als den Zustand im Log und auf der Konsole erkennbar zu machen:

• ESC-...: FS ist im Anlauf (wurde eingeschaltet, aber noch keine Reaktion des LO)
• ESC-___/¯¯¯: LO hat Einschalten erkannt, FS läuft
• ESC-¯¯¯\___: LO hat Abschalten erkannt, FS ist aus

Im Log stellt es sich so dar, dass erst mit Ablauf des Starttimers und Abschalten des FS dann plötzlich der Wechsel kommt, und folgerichtig dann auch das ESC-AA. Sieht nach einer Hardwaresache aus, dazu bin ich aber nicht firm genug in der Schaltung. Werde das mit dir, Rolf, nochmal genauer verhackstücken. Wenn das Problem noch auftritt, trotzdem der für observe_line konfigurierte GPIO rechtzeitig wechselt, dann muss ich den Softwarefehler suchen und beheben ... Wenn sich das mit der üblichen Schaltung nicht immer regeln lässt, finden wir einen anderen Ausweg, z.B. Sonderbehandlung: gehen wir direkt online (eingehend) oder über Wahlbereitschaft (ausgehend).

@björn: Hast du eine Idee? Ist ggf. im txDevITelexClient oder Common was "übersehen" worden bei den ausgehenden Verbindungen, was im Serverteil für hereinkommende Verbindungen richtig funktioniert?

Wie erwähnt, der i-Telex-Client bekommt davon nichts mit. Die Sache mit der Anlaufüberwachung läuft nur zwischen MCP und dem vorhandenen Hardwaremodul.

Ich muss mal endlich meinen T68d anbinden, damit ich sowas auch selbst ausprobieren kann ... aber die Zeit ...

Grüße


Björn

[obrecht]

Ich zitiere mal aus Fred's i-telex-wiki:

Verbindungsaufbau zwischen zwei Fernschreibern nach TW 39:

• Der rufende Teilnehmer betätigt die Anruftaste am Fernschaltgerät. Der Fernschreiber wird an die Leitung
  angeschlossen und der Strom, man spricht hier vom Schleifenstrom, wird von vorher 5 mA auf 40 mA erhöht.
  Durch diese Stromerhöhung wird der Vermittlungsstelle der Wunsch nach einem Verbindungsaufbau mitgeteilt.
• Die Vermittlungsstelle quittiert die Wählbereitschaft durch eine kurze Unterbrechung der Leitung von 25 ms Dauer.
• Es erfolgt die Wahl der Zielrufnummer mit Hilfe der Wählscheibe. Der Stromfluß der Leitung wird im Takt der gewählten Ziffern unterbrochen. Diese Wahl wird als Impulswahl (IWV) bezeichnet.
• Die Vermittlungsstelle polt nun die Leitung um (Polarität der a/b Ader wird vertauscht) und der Motor im Fernschreiber läuft an. Das gilt auch für die eingehende (gerufener Teilnehmer) Verbindung.
• Die Verbindung ist hergestellt und der Teilnehmer kann mit der Gegenstelle kommunizieren.
• Um die Verbindung zu beenden, drückt ein Teilnehmer die Schlusstaste am Fernschaltgerät. Dadurch wird der Schleifenstrom vollständig unterbrochen. Die Vermittlungsstelle trennt die Verbindung, die Adern werden wieder umgepolt und die Fernschreiber von der Leitung getrennt. Es fließt nun wieder der Ruhestrom von 5 mA.

Das heißt, dass bei ausgehender Verbindung bereits mit dem Drücken der AT-Taste der Schleifenstrom des Fernschreibers mit 40mA auf der Leitung liegt, folglich die Maschine online ist. Bereits mit Erkennen von ESC-AT müsste txDevRPiTTY also die "Drucker bereit" Meldung an txDevMCP absetzen (was bisher nicht passiert, warum, ist mir softwarelogisch nicht klar, denn auch hier gibt es eine Stromerhöhung auf 40mA. Vielleicht liegt die aber zeitlich zu weit vor der Abfrage des Observers im Laufe des Verbindungsaufbaus, so dass keine steigende Flanke des Strombetrags mehr erkannt werden kann. Bei,"Durchschalten" der Verbindung zum Empfänger ändert sich beim Anrufer ja nicht mehr der Strombetrag, nur die Stromrichtung, was für das Einschalten des Motors detektiert wird, ebenso beim Empfänger, s.o.).

Bei ankommender Verbindung kann eigentlich alles so bleiben, wie es ist, denn der Observer erkennt ja den Anstieg des Stroms nach dem Umpolen auch jetzt schon richtig.

Und das Verbindungsende mit der fallenden Flanke des Schleifenstrombetrags wird ja auch vom Observer erkannt.

[FredSonnenrein]

...da ist übrigens auch ein kleines Designproblem des "TW39-Protokolls" versteckt:
Auf der Seite des rufenden Fernschreibers kann nicht detektiert werden, wann der Fernschreiber nach Umpolen der Schleife (infolge der fertig hergestellten Verbindung) tatsächlich betriebsbereit ist.

Das war andererseits aber auch (beim Original TW39) technisch nicht erforderlich, da der Anrufer nach dem Anlaufen des Fernschreibers selbst die ersten Aktionen (WerDa drücken) vornimmt, und somit der Mensch beurteilt, ob es jetzt losgehen kann.

Dies habe ich selbst konterkariert durch das automatische Drucken der Uhrzeit (sofern aktiviert). Das passt eigentlich nur zum ED1000, wo Tastaturwahl "pflicht" war und somit das beschriebene Problem gar nicht besteht, da der Fernschreiber bereits beim Wählen vollständig betriebsbereit ist.

Das i-Telex löst das Problem mit einer einfachen "Wartezeit" zwischen Umpolen der Schleife und Ausgabe des Datums.

Viele Grüße,

Fred

[obrecht]

Hallo Fred,
ja, danke für die Ergänzung. piTelex erwartet aber offensichtlich NACH dem Verbindungsaufbau (= Umpolen) eine (erneute) Betriebsbereitschaftsmeldung der lokalen Maschine. Beim Empfänger ist das problemlos, da der ja dann lokal von 5mA auf 40 mA schaltet; beim Sender tut sich aber nichts am Schleifenstrombetrag, weshalb NACH dem Zustandekommen der Verbindung auf der Anruferseite keine weitere Betriebsbereitschafts-Signalisierung mehr möglich ist. Auf Grund der fehlenden Rückmeldung geht piTelex von einem nicht bereiten FS aus und trennt die Verbindung. Das ist aber unlogisch, da die Maschine ja schon VOR Verbindungsbeginn betriebsbereit ist (zumindest der Schleifenstrom da sein muss, sonst funktioniert die AT-Taste ja nicht). Den Knoten müssen wir jetzt lösen (wobei "wir" sehr vornehm meint "Björn oder Jochen", weil ich dazu zu dämlich bin )