Neu dabei mit TeKaDe FS200

[obrecht]

So, neue Erkenntnisse: nach Aufruf von "./telex.py" kann ich nun tatsächlich aus der Konsole auf dem Fernschreiber schreiben!

Sehr schön. Dann wäre jetzt der "nc" test dran und dann der Versuch, z.B. die 833538 anzurufen
Dann scheint die CH340-Lösung ja zu funktionieren.

Der CH340 funktioniert selbstverständlich problemlos unter Linux. Daran wird es nicht scheitern.

Das hatte ich mir eigentlich auch gedacht.

Ich hatte nur aus dem Wiki von Jochen zitiert, da gabs wohl mal ein Problem. Aber dann kann man den Warnhinweis ja getrost rausnehmen. Wieder was glattgebügelt
Wobei mir noch nicht ganz einleuchtet, warum man bei einem RPi mit seinen schönen GPIO-Möglichkeiten über die USB-Schnittstelle geht.
Aber das entscheidet jeder so wie es jeweils passt...

Was hab ich geändert? Upgrade vom Pi auf einen Pi2. Scheinbar ist der erste Pi doch etwas zu schwach.

Nee. TW39 ist nicht rechenintensiv. Ich habe diverse (siehe Signatur) TW39/V10-Maschinen mit PiZeroW's laufen, da hat's keine Probleme mit der Prozessorlast. Lediglich bei ED1000 sollte es ein Zero2 oder was besseres sein.

Wie ist das nun mit der pitelex.Service? mit der rc.local-Methode funktioniert das mal nicht.

Erstmal gucken ob der Rest auch läuft. Die Automatisierung kann dann immer noch kommen. Ich empfehle die byobu/screen-Methode.

[MCMLXXV]

Sehr schön. Dann wäre jetzt der "nc" test dran und dann der Versuch, z.B. die 833538 anzurufen
Dann scheint die CH340-Lösung ja zu funktionieren.

Hmm - wenn ich das "nc localhost 2342" am Pi eingebe kommt direkt der Prompt wieder - obwohl ich wie vorgeschlagen das Netcat installiert habe.

Wobei mir noch nicht ganz einleuchtet, warum man bei einem RPi mit seinen schönen GPIO-Möglichkeiten über die USB-Schnittstelle geht.
Aber das entscheidet jeder so wie es jeweils passt...

Ein guter Grund dafür wäre z.B. um auf Standard-Teile zurückgreifen zu können, die man nahezu überall bekommt oder schnell besorgen kann. Klar, über GPIO würde mir auch gefallen - wenn ich die Teile dafür da hätte. Fängt doch schon bei den Treiberbausteinen /Platinen/ Federleisten (26pol für den Pi1) an......

Nee. TW39 ist nicht rechenintensiv. Ich habe diverse (siehe Signatur) TW39/V10-Maschinen mit PiZeroW's laufen, da hat's keine Probleme mit der Prozessorlast. Lediglich bei ED1000 sollte es ein Zero2 oder was besseres sein.

Wie ist das nun mit der pitelex.Service? mit der rc.local-Methode funktioniert das mal nicht.

Erstmal gucken ob der Rest auch läuft. Die Automatisierung kann dann immer noch kommen. Ich empfehle die byobu/screen-Methode.

Naja - ich weiß nicht wie weit V10 mit TW39 vergleichbar ist - vielleicht ist das Problem tatsächlich der USB.
Würde sich die byobu/screen-Methode denn rückgängig machen? bei der rc.local-Methode kann ich die Zeile ja wieder löschen....
Auch funktioniert hier die Anleitung so nicht - schon weil Screen installiert werden muss - und dann stimmen wohl ein paar Verzeichnisse nicht.

Ich hab mir bei Reichelt jetzt mal die Bauteile für die V10-Verbindung über die GPIOs bestellt. Nur für den Pi1 die 26polige Federleiste haben die wohl auch nicht.....

Nach Drücken der Lin-Taste und Eingabe der 727272 funktioniert jedenfalls mal nix......

[obrecht]

Hmm - wenn ich das "nc localhost 2342" am Pi eingebe kommt direkt der Prompt wieder - obwohl ich wie vorgeschlagen das Netcat installiert habe.

Du musst dafür natürlich ein zweites Fenster aufmachen und im ersten Fenster pitelex laufen haben
Ansonsten hülfe zum Nachsehen, ob der port überhaupt offen ist, ein

Code: Alles auswählen

nmap localhost -p2000-2500

(aus dem zweiten Fenster ). Das sollte alle offenen ports im Bereich 2000-2500 auflisten. (Ggf nmap wieder nachinstallieren mit)

Code: Alles auswählen

sudo apt install nmap

Naja - ich weiß nicht wie weit V10 mit TW39 vergleichbar ist - vielleicht ist das Problem tatsächlich der USB.

Sieht aber so aus, als ob es läuft, sonst könntest du nicht von screen aus auf dem FS200 drucken. Gehts denn auch umgekehrt?
Am FS200 LIN drücken, tippen, und es erscheint am Bildschirm? Dann solte die Kommunikation in beiden Richtungen grundsätzlich laufen.

Würde sich die byobu/screen-Methode denn rückgängig machen? bei der rc.local-Methode kann ich die Zeile ja wieder löschen....

Aus dem Wiki:

Code: Alles auswählen

Configure pitelex to be started on boot: sudo systemctl enable pitelex.service

Das legt nahe, dass man den Autostart wieder abklemmen kann mit

Code: Alles auswählen

sudo systemctl stop pitelex.service
sudo systemctl disable pitelex.service

Das stoppt die laufende Instanz und verhindert den Autostart nach dem nächsten boot.

Auch funktioniert hier die Anleitung so nicht - schon weil Screen installiert werden muss

Wiki:

Code: Alles auswählen

Make sure byobu and screen are installed: sudo apt install screen byobu

- und dann stimmen wohl ein paar Verzeichnisse nicht.

Welche?

Ich hab mir bei Reichelt jetzt mal die Bauteile für die V10-Verbindung über die GPIOs bestellt. Nur für den Pi1 die 26polige Federleiste haben die wohl auch nicht.....

Da sehe ich gerade einen Lesefehler meinerseits. Du hast einen pi1, ich rede die ganze Zeit vom piZero.... mit pi1 kenne ich mich nicht aus (die GPIO sieht anders aus (40pol statt 26pol). Ob der pi1 funktioniert, weiß ich nicht. Da kann aber sicher jemand anders was zu sagen.

Nach Drücken der Lin-Taste und Eingabe der 727272 funktioniert jedenfalls mal nix......

Wird die 727272 denn wenigstens am Bildschirm mitprotokolliert (s.o.)?

Bin gespannt auf deine weiteren Recherchen.

[MCMLXXV]

Hmm - wenn ich das "nc localhost 2342" am Pi eingebe kommt direkt der Prompt wieder - obwohl ich wie vorgeschlagen das Netcat installiert habe.

Du musst dafür natürlich ein zweites Fenster aufmachen und im ersten Fenster pitelex laufen haben

OK - dann kommt nach der Angabe ein "occ".

Ansonsten hülfe zum Nachsehen, ob der port überhaupt offen ist, ein

Code: Alles auswählen

nmap localhost -p2000-2500

(aus dem zweiten Fenster ). Das sollte alle offenen ports im Bereich 2000-2500 auflisten. (Ggf nmap wieder nachinstallieren mit)

Code: Alles auswählen

sudo apt install nmap

Ja, da wird der Port "2342/tcp" als "open" für "manage-exec" angezeigt.

Naja - ich weiß nicht wie weit V10 mit TW39 vergleichbar ist - vielleicht ist das Problem tatsächlich der USB.

Sieht aber so aus, als ob es läuft, sonst könntest du nicht von screen aus auf dem FS200 drucken. Gehts denn auch umgekehrt?
Am FS200 LIN drücken, tippen, und es erscheint am Bildschirm? Dann solte die Kommunikation in beiden Richtungen grundsätzlich laufen.

seltsam - das lief die ganze Zeit nicht - nun lief es.

Würde sich die byobu/screen-Methode denn rückgängig machen? bei der rc.local-Methode kann ich die Zeile ja wieder löschen....

Aus dem Wiki:

Code: Alles auswählen

Configure pitelex to be started on boot: sudo systemctl enable pitelex.service

Das legt nahe, dass man den Autostart wieder abklemmen kann mit

Code: Alles auswählen

sudo systemctl stop pitelex.service
sudo systemctl disable pitelex.service

Das stoppt die laufende Instanz und verhindert den Autostart nach dem nächsten boot.

Auch funktioniert hier die Anleitung so nicht - schon weil Screen installiert werden muss

Wiki:

Code: Alles auswählen

Make sure byobu and screen are installed: sudo apt install screen byobu

- und dann stimmen wohl ein paar Verzeichnisse nicht.

Welche?

Ohje - dazu müsste ich das nochmal durchgehen. Auswendig weiß ich das grad nicht.....

Ich hab mir bei Reichelt jetzt mal die Bauteile für die V10-Verbindung über die GPIOs bestellt. Nur für den Pi1 die 26polige Federleiste haben die wohl auch nicht.....

Da sehe ich gerade einen Lesefehler meinerseits. Du hast einen pi1, ich rede die ganze Zeit vom piZero.... mit pi1 kenne ich mich nicht aus (die GPIO sieht anders aus (40pol statt 26pol). Ob der pi1 funktioniert, weiß ich nicht. Da kann aber sicher jemand anders was zu sagen.

Ja, hat nur nen 26pol GPIO-Anschluss. Und ist scheinbar sehr schwach. Braucht schon zum Booten bis im WLAN aktiv erheblich länger.

Nach Drücken der Lin-Taste und Eingabe der 727272 funktioniert jedenfalls mal nix......

Wird die 727272 denn wenigstens am Bildschirm mitprotokolliert (s.o.)?

nein, normal nicht. Außer "mitlesen" ist aktiv. Aber außer der 727272 erscheint dann da auch nix.

Bin gespannt auf deine weiteren Recherchen.

[obrecht]

OK - dann kommt nach der Angabe ein "occ".

Das sieht doch gut aus. Denn du sprichst den ITelexServer an, der dir auch antwortet, nämlich, dass der FS200 "besetzt" ist. Vermutlich war der zu der Zeit im "LIN=ein"-Modus. Versuch das doch mal wenn der FS200 im Ruhezustand ist...

Ja, da wird der Port "2342/tcp" als "open" für "manage-exec" angezeigt.

Passt.

Am FS200 LIN drücken, tippen, und es erscheint am Bildschirm? Dann solte die Kommunikation in beiden Richtungen grundsätzlich laufen.

seltsam - das lief die ganze Zeit nicht - nun lief es.

Egal, es läuft :-)

Wird die 727272 denn wenigstens am Bildschirm mitprotokolliert (s.o.)?

nein, normal nicht. Außer "mitlesen" ist aktiv. Aber außer der 727272 erscheint dann da auch nix.

Weiter oben hast du gesagt, es wird am Bildschirm protokolliert

[MCMLXXV]

Wird die 727272 denn wenigstens am Bildschirm mitprotokolliert (s.o.)?

nein, normal nicht. Außer "mitlesen" ist aktiv. Aber außer der 727272 erscheint dann da auch nix.

Weiter oben hast du gesagt, es wird am Bildschirm protokolliert

Oh - dann müssen wir irgendwo aneinander vorbeigeschrieben haben. Also wenn ich line drücke und die 727272 eintippe - passiert gar nix. wenn ich allerdings die Konsole offen habe nach Aufruf von telex.py seh ich die 727272 natürlich auf dem Display.

[obrecht]

[Oh - dann müssen wir irgendwo aneinander vorbeigeschrieben haben. Also wenn ich line drücke und die 727272 eintippe - passiert gar nix. wenn ich allerdings die Konsole offen habe nach Aufruf von telex.py seh ich die 727272 natürlich auf dem Display.

Das ist doch gut, dann geht die Kommunikation in beiden Richtungen zwischen pitelex und FS200.
Probier bitte mal folgendes:

telex.py starten, dann (wenn pitelex im "eingeschwungenen Zustand" ist)
am FS200 "LIN" drücken: Am Bildschirm sollte in inverser Schrift "<MCP:WB>" erscheinen (ptelex geht in Wählbereitschaft). Anschließend
am FS200 "LOK" drücken: Am Bildschirm sollte in inverser Schrift "<MCP:Z>" erscheinen (pitelex geht offline).

Wenn das so funktioniert, tut's auch die Statuserkennung (RTS/CTS), die pitelex auswertet. Wenn sich da aber nix regt, könnte das auf das CTS-Problem hindeuten. Ggf hilft der CTS-Hack aus dem Wiki:
https://github.com/fablab-wue/piTelex/w ... k-for-tw39

[MCMLXXV]

Hmm. Eigentlich steht beides in inverser Schrift drin.

[MCMLXXV]

Also an der Stelle lege ich den Kram mal beiseite und warte bis Reichelt die bestellten Sachen liefert. Auf einem "Entwicklerboard" werde ich dann erstmal den GPIO-Adapter nach https://github.com/fablab-wue/piTelex/wiki/HW_V10 zusammenstecken und ausprobieren. Natürlich muss ich dann die telex.json erstmal ändern, ist mir klar. Hab gesehen, da gibt es sogar ein Kapitel für den FS200 - den dann wohl auf true setzen?

Und dann wohl mal auf Suche gehen wo ich die Federleiste für den 26pol. GPIO des Pi 1 herbekomme. Falls es mit dem funktioniert.

Ansonsten wünsche ich allen ein schönes Wochenende!
Ab morgen darf ich auch wieder raus.... :-)

[tasto]

Falls du eine Lösung für den 26-poligen GPIO findest, gib gern Bescheid. Ich suche da auch noch.