Neu dabei mit TeKaDe FS200

[obrecht]

Hmm. Eigentlich steht beides in inverser Schrift drin.

Bevor du den Kram beiseite legst...
Die Verbindung zwischen piTelex und FS200 scheint doch bidirektional zu funktionieren, inklusive RTS/CTS.

Starte doch Mal Telex.py und Versuche aus Screen heraus zu wählen:
<ESC>AT<ENTER> eingeben, dann müsste die Meldung MCP:WB kommen, dann 727272 eingeben.
Dann müsste der Wetterserver sich melden.
Verbindung beenden:
"Stoptaste drücken" durch Eingabe von <ESC>ST<ENTER>
oder im Zweifel Ctrl -c ...

[MCMLXXV]

Cool - dann passiert ja was:

pi@PiTelex:~/piTelex $ ./telex.py

-=TELEX=-

<MCP:TP1><MCP:Z><MCP:WB><chT:AA>ªescºatªenterº
º7º27272 |
{at}<MCP:WB>727272<iTc:A> |
.c..eigenen·kennungsgeber·mit·(neue·zeile)·bestaetigen |
727272·wetter·d#ª |
12345·dummy·d<MCP:AA> |
.· |
i·=·inhalt···x·=·trennen |
buchstabien·eingeben·und·dann·zeilenvorschub |
iuteet·f·gewaehlbt |
falsche·auswahl |
a·d<iTc:Z><MCP:TP0><MCP:ZZ> |


Jetzt hab ich auch mal raus wie ich den Test aus Putty kopieren kann.....

Aber: Ich kann nun irgendwie nicht mehr aus der Konsole auf den Fernschreiber schreiben. Das Ding "tickert" zwar - bringt aber nix mehr aufs Papier.....

[obrecht]

Naja, also die Verbindung "raus" funktioniert doch einwandfrei.
Was passiert wenn du telex.py startest,dann am FS "LIN" drückst --> MCP:WB- Meldung --> und dann 727272 am FS tippst?

[MCMLXXV]

So - direkt nach Start telex.py:

-=TELEX=-

<MCP:TP1><MCP:Z><MCP:WB><chT:AA>

Nach Drücken von "Lin" ändert sich da scheinbar nix (Ich muss immer hin und her laufen. Sollte sich kurzfristig was tun wirds schwierig.)

Nach Drücken *Lin" und der 727272;

-=TELEX=-

<MCP:TP1><MCP:Z><MCP:WB><chT:AA>º7º27272

Nach Zeit heißt es dann:

-=TELEX=-

<MCP:TP1><MCP:Z><MCP:WB><chT:AA>º7º27272
<MCP:Z><MCP:TP0><MCP:ZZ> |

|
Irgendwie glaub ich fast dass der FS200 nen Schaden hat. Mangels Tauschmasse halt schlecht zu prüfen.

[obrecht]

Naja... piTelex geht in WB, die Ziffern kommen vom FS bei piTelex an, führen aber nicht zum Verbindungsaufbau (warum auch immer), weshalb nach dem in piTelex eingestellten TIMEOUT die Verbindung als beendet erklärt wird (MCP:Z) und der Drucker abgeschaltet wird (MCP:TP0). Nach weiterem TIMEOUT geht piTelex dann schlafen (MCP:ZZ).

Frage ist, was passiert mit den Wählziffern in piTelex. Dazu wäre der errorlog zu einem solchen Verbindungsaufbau interessant.

[MCMLXXV]

OK - zu dieser Ausgabe am Terminal:

-=TELEX=-

<MCP:TP1><MCP:Z><MCP:WB><chT:AA>º727272<MCP:Z><MCP:TP0><MCP:ZZ>pi@PiTelex:~/piTelex $ ^C

Gehört das aus der data.log:

2022-10-15 11:41:14 , , ===== piTelex rev 542b087 Update txDevMCP.md ========$
2022-10-15 11:41:14 ,chT, {~2}{ST}
2022-10-15 11:41:14 ,piT, {___/¯¯¯}
2022-10-15 11:41:14 ,MCP, {TP1}
2022-10-15 11:41:14 ,piT, {AT}
2022-10-15 11:41:14 ,MCP, {Z}{WB}
2022-10-15 11:42:37 , , ===== piTelex rev 542b087 Update txDevMCP.md ========$
2022-10-15 11:42:37 ,chT, {ST}
2022-10-15 11:42:37 ,piT, {___/¯¯¯}
2022-10-15 11:42:37 ,MCP, {TP1}
2022-10-15 11:42:37 ,piT, {AT}
2022-10-15 11:42:37 ,MCP, {Z}{WB}
2022-10-15 11:42:37 ,chT, {AA}>727272

Hilft das weiter?

Ich bin jedenfalls überrascht, dass die Uhr noch halbwegs stimmt. Hab da noch nix eingestellt.

[obrecht]

Das passt nicht.... Im log (das ist der Transcript log, nicht der Errorlog) sind **zwei* Starts von pitelex, im Terminal-output nur einer, und der errlog bricht nach "727272" ab.
Aber was mich stört, ist, dass der piTelexClient AT meldet, MCP aber Z und unmittelbar danach WB (in beiden Fällen des pitelex starts, d.h. also unabhängig von deiner Eingabe am FS? Jedenfalls sieht das für mich widersprüchlich aus. Bei meinem FS220 (über GPIO angebunden) sieht das so aus:

<MCP:WB>833540<iTc:A><piT:AA>ªªªª ###LIN drücken, wählen, Verbindungsaufbau: iTc=i-Telex-Client, piT=RPiTTY
º15.10.2022··12:05 ### Gegenstelle meldet sich
<MCP:Z><iTc:Z> ### Verbindungsabbau: MCP sagt Ende, iTc führt aus und quittiert

Und mein Transcript log sieht so aus:

2022-10-15 12:05:37 ,piT, {___/¯¯¯}{AT}
2022-10-15 12:05:37 ,MCP, {WB}
2022-10-15 12:05:42 ,piT, >8
2022-10-15 12:05:42 ,MCP, {#!8}
2022-10-15 12:05:42 ,piT, 3
2022-10-15 12:05:42 ,MCP, {#!83}
2022-10-15 12:05:43 ,piT, 3
2022-10-15 12:05:43 ,MCP, {#!833}
2022-10-15 12:05:43 ,piT, 5
2022-10-15 12:05:43 ,MCP, {#!8335}
2022-10-15 12:05:43 ,piT, 4
2022-10-15 12:05:43 ,MCP, {#!83354}
2022-10-15 12:05:44 ,piT, 0
2022-10-15 12:05:44 ,MCP, {#!833540}
2022-10-15 12:05:44 ,iTc, {A}
2022-10-15 12:05:44 ,piT, {AA}
2022-10-15 12:05:44 ,iTc, {^24}
2022-10-15 12:05:44 ,piT, {~0}
2022-10-15 12:05:44 ,iTc, {^24}<<<<\_
2022-10-15 12:05:44 ,iTc, >15.10.2022 12:05\_
2022-10-15 12:05:45 ,iTc, {^24}
2022-10-15 12:05:45 ,piT, {~22}
2022-10-15 12:05:45 ,iTc, {^23}
2022-10-15 12:05:45 ,piT, {~17}
2022-10-15 12:05:45 ,iTc, {^23}
2022-10-15 12:05:46 ,piT, {~10}
2022-10-15 12:05:46 ,iTc, {^19}
2022-10-15 12:05:46 ,piT, {~0}
2022-10-15 12:05:46 ,iTc, {^19}{^19}{^17}{^17}{^15}{^13}{^0}{^0}
2022-10-15 12:05:50 ,piT, {¯¯¯\___}{ST}
2022-10-15 12:05:50 ,MCP, {Z}

Vielleicht musst du das RTS oder/und DTR-Signal invertieren? Siehe dazu die Parameter für CH340-Modul in https://github.com/fablab-wue/piTelex/w ... -parameter

also die Zeilen

Code: Alles auswählen

"inverse_dtr" : true,
"inverse_rts" : true,

in telex.json im Abschnit für CH340TTY ergänzen und mit true/false spielen... (default ist jeweils false). Bei zwei Variablen ergibt das max 4 Möglichkeiten, der Aufwand ist also überschaubar :-)

Und die Uhrzeit sollte der pi sich über's Netz holen :-)

[MCMLXXV]

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

Pollin hätte da was: https://www.pollin.de/p/buchsenleiste-v ... lig-451355

[MCMLXXV]

Das passt nicht.... Im log (das ist der Transcript log, nicht der Errorlog) sind **zwei* Starts von pitelex, im Terminal-output nur einer, und der errlog bricht nach "727272" ab.

Ich hatte die Data.log vorher gelöscht und hatte dann nen neuen Versuch gestartet. Daher hab ich gehofft das würde zusammen passen. Wo finde ich denn den Errorlog?

Vielleicht musst du das RTS oder/und DTR-Signal invertieren? Siehe dazu die Parameter für CH340-Modul in https://github.com/fablab-wue/piTelex/w ... -parameter

also die Zeilen

Code: Alles auswählen

"inverse_dtr" : true,
"inverse_rts" : true,

in telex.json im Abschnit für CH340TTY ergänzen und mit true/false spielen... (default ist jeweils false). Bei zwei Variablen ergibt das max 4 Möglichkeiten, der Aufwand ist also überschaubar :-)

Das werde ich später mal ausprobieren. Klingt sogar plausibel! Für mich zumindest. :-)
Sind ja eigentlich sogar nur noch drei (01,10 und 11) versuche - da der erste (00)ja schon seit Tagen läuft.....

Und die Uhrzeit sollte der pi sich über's Netz holen :-)

Ach ja - stimmt - war ein Gedankenfehler von mir.

[obrecht]

Wo finde ich denn den Errorlog?

in dem Verzeichnis, das in telex.json dafür konfiguriert ist:

Code: Alles auswählen

  "errorlog_path": "piTelex/",

Viel Erfolg!