Telexforum.de

Hallo Fred,

die 726 (erst seit zwei Stunden im Einsatz) geht sofern gut bei "normalem" Gebrauch, wenn man aber die /itelex-twitlnliste.cgi?spr=de auffragt während eine Verbindung dann schmiert diese ab, bei der 666 war das nicht so.

Update: Beim senden einer Lochstreifen von 726 an 666 Die Verbindung wird seitens den Sender (726) unterbrochen, als ob man die Schluß-Taste druckt, die Empfänger bekommt noch nichts mit, dann steigt die Empfänger nach 15 Sekunden auch aus, und wird eine Systemmeldung: /// Zeitueberschreitung bei wiederaufnahme der verbindung /// ausgegeben.

Also das Verhalten haben ich bei dem Vorgänger bei mir aber auch bemerkt.
Reset bei Abfrage der "Bus-Tln-Liste"
Beispielsweise in der 715 und davor auch.
Ist hier für die 706 beschrieben : https://www.telexforum.de/viewtopic.php ... t=10#p2495

Fand es unschön aber nicht tragisch.

Ich wollte Dich (Johannes) gerade bitten, die Version 706 zu testen... Aber wenn Du Zeit hast, mach das bitte nochmal:

Die 706 ist hier: https://sourceforge.net/p/itelex/code-0 ... format=raw

Eine Bugfix-Hack-Version der 726 ist hier (nur temporär): http://www.telexupdate.de/ethernet/main.hex

Ich bin gespannt.

Version 715 :
Fernschreiber ONline und 0 0 gewählt.
Während es klackert die Busteilbehmer ab gefragt ubnd es kam zum Reset.:

Debug_LowestSP = 1CD2
XMCRA = 85
SystemStartZeit = 16.03.2017 19:35:08, ResetFlag = 08
VCC [mV] = 5051 5073 5028 5051 5073 5073 5028 5051 5073 5051
Statistik-Daten zurücksetzen
Ethernet: 6338 Bytes in 32 Paketen LockErrors 0

Ich probiere nun mal die Bugfixed Version aus.

Version 726 (Hack Bugfix):

Gleiche Verhalten wie die "normale" 726 , reset
00:00:00,19: Neustart 726 Reset-Flags 08

Version 706:

Gleiche Verhalten wie die "normale" 726 , reset

20:12:38,18: http-request: itelex-menu-de.html from 79.20.53.136

20:12:40,18: iTelex(47450): Socket Sendung: (3) 06 01 81 --> Res 3 SumAnz 3/03

20:12:40,20: iTelex(47453): Socket Empfang: (19/19) 02 0E 04 06 0A 1B 0E 04 0D 1
D 0D 0A 04 1F 12 18 06 01 03 --> BufUsed 19
00:00:00,19: Neustart 706 Reset-Flags 08

Version Build 726 ITA2 50 Baud at Date: Mar 15 2017 19:28:25

Fernschreiber online, 0 0 gewählt und dann Bus-Teilnehmerliste abgefragt.
Reset.

ZeitServerAbfrageTimerEnde = 8280
NTPUpdateDiffSeconds = 0
Debug_LowestSP = 1CD2
XMCRA = 85
SystemStartZeit = 16.03.2017 20:14:54, ResetFlag = 08
VCC [mV] = 5006 5073 5073 5028 5051 5073 5073 5051 5073 5051
Statistik-Daten zurücksetzen
Ethernet: 16434 Bytes in 167 Paketen LockErrors 0

Vergesst die Debug-Info, ich glaube auch so dass die Karte sich resettet...
Passiert das nur bei der Bus-Teilnehmer-Liste? Oder auch bei anderen Eingaben über die HTML, z.B. Rufnummern-Liste?
Ich habe es reproduzieren können. Okay... Meine TWI Library scheint einen BUG zu haben, der bei "Doppel"-Beanspruchung zuschlägt. War damals bei der Uhrzeit-Verteilung ja auch so. Aber dass die 666 da wiederum fehlerfrei ist, ist nicht nachvollziehbar.

FredSonnenrein hat geschrieben:Vergesst die Debug-Info, ich glaube auch so dass die Karte sich resettet...
Passiert das nur bei der Bus-Teilnehmer-Liste? Oder auch bei anderen Eingaben über die HTML, z.B. Rufnummern-Liste?
Ich habe es reproduzieren können. Okay... Meine TWI Library scheint einen BUG zu haben, der bei "Doppel"-Beanspruchung zuschlägt. War damals bei der Uhrzeit-Verteilung ja auch so. Aber dass die 666 da wiederum fehlerfrei ist, ist nicht nachvollziehbar.

Hängt es eventuell auch mit der Firmware der Partnerkarten zusammen, mit welchen via TWI kommuniziert wird ?

Version 666:

Du hast Recht Fred, die 666 ist somit auch "empfindlich" für eine Abfrage, aber die Verbindung schmiert nicht ab sondern das Senden/Empfangen (666 <> 666) der Zeichen wird langsamer bis sogar stockt, dann innerhalb 5 Sekunden wird alles wieder normal laufen ohne das es zur "Datenverlust kommt"

Die "Auszeit" ist abhängig von der Zeit welche die Ethernet-Karte braucht die HTML / CGI Befehle zu verarbeiten, die 666 ist relativ schnell (5 S)
die 726 blockiert den Browser (Chrome/Firefox)

Ich muss es mir nochmal anschauen, es kann sein, dass wegen der Abfrage die regelmäßigen Lebenszeichen stocken, deswegen die TW39 Karte abschaltet und deswegen die Ethernet-Karte abschaltet.