Restauration TeKaDe FS200 für späteren Betrieb mit piTelex

DSchneid · #81

pyserial sollte am aktuellsten Stand sein

λ pip install pyserial
Requirement already satisfied: pyserial in c:\python37-32\lib\site-packages (3.5)

piTelex.log

Code: Alles auswählen

2025-08-15 17:30:16 ,   , ===== piTelex Rev. 002 2025-06-17 13:45 ========================================
2025-08-15 17:30:16 ,iTs, {CC}
2025-08-15 17:30:16 ,chT, {ST}{AT}
2025-08-15 17:30:24 ,MCP, {TP1}{WB}
2025-08-15 17:30:29 ,chT, >7
2025-08-15 17:30:35 ,MCP, {#!7}
2025-08-15 17:30:36 ,chT, {ST}

piTelex-errors.log
2025-08-15 17:30:16,203 piTelex [INFO]: ===== piTelex Rev. 002 2025-06-17 13:45 =====
2025-08-15 17:30:16,203 piTelex [INFO]: log_lvl: 20 INFO
2025-08-15 17:30:16,240 piTelex.txDevITelexCentralex [INFO]: Centralex: connecting to server tlnserv2.teleprinter.net:49491)
2025-08-15 17:30:16,603 piTelex.txDevITelexCentralex [INFO]: Centralex: socket connected
2025-08-15 17:30:35,656 piTelex.txDevITelexClient [INFO]: Get User: '7'
2025-08-15 17:30:35,656 piTelex.txDevITelexClient [INFO]: No user found for number '7'
2025-08-15 17:30:40,133 piTelex.__main__ [INFO]: Exit by Keyboard

im Telex.json ist nun das CH340 Modul projektiert wie folgt:

Code: Alles auswählen

	# Module type "CH340TTY"
    # requirements: pyserial (Linux: sudo apt install python3-serial)
    # TW39 or V10 teletype over USB-serial-adapter with CH340 chip or UART which supports 50 Baud
    "CH340TTY": {
          "type": "CH340TTY",
          "enable": true,
          "portname": "COM3",          # Windows:"COMx" Linux:"/dev/ttyUSBx"
          "baudrate": 50,              # 50, 75, 100, 110, 200
          "mode": "V10",               # modes: "TW39", "TWM", "V10", "EDS"
          "coding": 0,                 # 0=ITA2
          "loopback": false
        },

Verhalten ist immer noch gleich - empfangen kann ich aber beim Senden druckt der Druckkopf nur das erste Zeichen (hier die 7 weil ich ursprünglich 717171 wählen wollte).
Ob ich von HDX auf DX am FS umstelle macht keinen Unterschied.

bzgl Dailmode: hätte die im iTelex Modul projektiert gehört?Ich finde diesen Parameter gar nicht in der Wiki

Die og. Config habe ich probiert, brachte keinen Erfolg dann habe ich den Parameter wieder gelöscht und den vorhandenen Parameter dial_timeout von 0 auf floating gestellt "+"

Code: Alles auswählen

#"dial_timeout": 0,
  "dial_timeout": "+",

brachte auch keine Verbesserung
Hat meine Adaptervariante (Local Echo) vielleicht einen Einfluss auf dieses Verhalten - soll ich jene Adaptervariante nehmen für reinen Duplex Betrieb? (https://github.com/fablab-wue/piTelex/w ... dapter.png)

DSchneid · #82

hier die logs vom letzten Test mit dem dial_timeout:"+"

wieso ist hier ein ">" vor der 7 enthalten?

#83

Erstens scheine ich heute nicht meinen besten Tag zu haben (dialmode ist natürlich Quatsch, dial_timeout ist richtig).

Zweitens habe ich ehrlich keine echte Idee für den Fehler. Sofort nach drücken der ersten "7" kommt eine Bedingung, die als Drücken der ST Taste gewertet wird, also als Verbindungsende, und das ist beim FS200 eigentlich das Drücken der LOK Taste. Geht denn die LED in der LIN Taste nach der ersten "7" direkt aus oder leuchtet sie weiter und du musst händisch wieder auf Lokal schalten?

DSchneid · #84

Die LIN Taste leuchtet weiter und erlischt erst nachdem ich wieder LOK drücke.
Hier ein Video

PS: das von Amzon gekaufte CH340 Modul ist mittlerweile im Himmel - kann die COM Schnittstelle nicht mehr öffene auch nicht nit 3rd Party Programmen wie HTERM etc... (werde ich retournieren das Klumpat

)

#85

Dann besteht ja noch Hoffnung dass es am dem Adapter gelegen haben könnte. Denn die LIN Taste bewirkt ja, dass CTS auf logisch 1 geht.

DSchneid · #86

obrecht hat geschrieben: ↑Fr 15. Aug 2025, 21:46 Dann besteht ja noch Hoffnung dass es am dem Adapter gelegen haben könnte. Denn die LIN Taste bewirkt ja, dass CTS auf logisch 1 geht.

Das Video wurde bereits mit einem neuen alternativen Modul (USB/RS232) gemacht - das Fehlerbild war bei beiden Modulen gleich

LIN bleibt/blieb immer grün - der Drucker hat nur das erste Zeichen gedruckt

#87

Miss doch mal, wie sich CTS an der Schnittstelle verhält... ob es auf "1" bleibt oder zurück auf "0" geht.

DSchneid · #88

So ich habe mich mit meinem Oszi reingehängt am CTS Pin und dieser sieht wie folgt aus.

Screenshot 2025-08-16 094614.jpg

Sobald der FS eingeschalten wird, geht der Pegel auf -5,36V also "0".
Drücke ich die LIN Taste geht der Pegel auf +5,36V also 1.
Dieser bleibt solange (selbst nach Eingabe der Rufnummer zB 7171717) auf dem Level (+5,36V) bis ich die LOK Taste wieder betätige.

Danch sieht man noch die Verlauf wo der FS ausgechalten wird.....

#89

Das ist doch schonmal gut. D.h. die V.10 arbeitet soweit korrekt. Und die Datenübertragung funktioniert ja auch, sonst könntest du nicht empfangen oder senden. Jetzt muss "nur" noch geklärt werden, wieso piTelex nach dem ersten gesendeten Zeichen im WB Modus wieder auf Z zurück schaltet.
Du könntest mal versuchen, den loglevel auf DEBUG zu setzen, dann müllt er dich mit tonnenweise Meldungen zu, aber vllt lässt sich da irgendwas sehen. Nur nicht vergessen, anschließend auf INFO zurück zu gehen, sonst quillt irgendwann die Partition über

DSchneid · #90

hier bitte

der screenshot stammt nach der Eingabe der ersten Ziffer "7"
danach habe ich gewartet aufs Timeout und in der Python Console kam dann ein "abort"

die piTelex-error.log mit aktivierten Debug_level hier hier im Anhang.
Zur Vollständigkeit auch den pTelex.log

Telexforum.de