Tixi.Com

Es gibt in der TICO kein Timeout für TiXML-Befehle.

Auch in der Firmware gibt es grundsätzlich kein Timeout bei der TiXML-Kommunikation.
Einzige Einschränkung:
Zwischen dem TiXML-Frame-Zeichen und dem darauffolgenden dürfen max. 5s liegen, sonst wird der Befehlsinterpreter nicht aktiviert.
Danach wartet das Modem alle Ewigkeit auf den Rest der Befehls, solange kein neuer Befehl geschickt wird.


Das ist immer abhängig vom Projekt (Systemauslastung) sowie der Größe der TiXML-Frames, die übertragen werden.
Die Software TILA hat z.B. ein Default-Timeout von 1min (reicht in 90% der Fälle), welches aber dort auch auf 5min erhöht werden kann. Bei riesigen Datenbanken kann es natürlich noch viel länger dauern, solche Daten machen aber eigentlich keinen Sinn...


Grundsätzlich:
Alle 30sec macht das Alarm Modem ein "Ping" zur verbundenen Gegenstelle (z.B. TICO). Antwortet der Host nicht, wird die TiXML-Session beendet.
Wenn man jedoch eine Datenübertragung mittendrin beendet, benötigt das Modem einige Zeit die Daten im Empfangspuffer zu verarbeiten. Besonders bei großen Dateien (z.B. komplilierte Webseiten) kann es schonmal einige Minuten dauern, bis der Socket wieder Verbindungen zuläßt.


Eigentlich nach 90s. Allerdings sind bei Modemverbindungen mehrere Dienste involviert (TCP-IP-Stack, Modem,...). Erst wenn alle Dienste Ihre Session beendet haben, ist das Modem wieder bereit. Länger als 2min haben wir aber noch nicht erlebt.

Einige Werte kann man durch eine versteckte "Timeouts"-Gruppe in der USER-Datenbank verändern. Dies ist aber nur ein undokumentiertes inoffizielles Feature .

Folgende Datenbankeinträge haben TimeoutFunktionen:

/ISP/ISP/PPPComm/KeepAlive
Modem-Watchdog des PPP-Server bei ausgehenden Verbindungen, z.B. Email-Versand (keine Aktivität in der Zeit -> auflegen).

/ISP/CBIS/KeepAlive
Modem-Watchdog des PPP-Server bei CBIS-Verbindung (keine Aktivität in der Zeit -> auflegen)

/ISP/CBIS/ResponseTime
Wartezeit zum Zugriff auf den Webserver nach CBIS Email.

/ISP/Webserver/KeepConnected
Webserver Timeout (keine Aktivität in der Zeit -> auflegen) unabhänging von CBIS, PPP
Wenn KeepConnected > CBIS/ResponseTime gilt nur KeepConnected.
Zählt sofort nach Verbindungsaufbau (wie ResponseTime), verlängert sich aber bei jedem HTTP-Zugriff.

/USER/Timeouts/RemoteWatchdog
Modem-Watchdog bei TiXML Einwahl

/USER/Timeouts/PPPTimeout
Modem-Watchdog bei PPP- Einwahl

/USER/Timeouts/RemoteSession
Verlust der Authentifizierung bei Inaktivität während TiXML Einwahl.
Danach ist ein erneutes Login notwendig.

/USER/Timeouts/TSAdapter_CB
Modem-Watchdog bei MPI Callback (Ausgehend)

/USER/Timeouts/TSAdapter
Modem-Watchdog bei MPI Einwahl (Eingehend)

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Vielen Dank für die schnelle Antwort.

Eine Frage habe ich noch. Ich konnte in der von TIXI angebotenen Dokumentation keinerlei Hinweise auf TimeOut-Zeiten finden.

Bei der seriellen Kommunikation mit dem TAM scheinen die TimeOuts in TICO extrem hoch gesetzt zu sein. Ist das TAM nicht in der Lage auf einen Befehl zu antworten, blockiert TICO.
Welche TimeOuts sind zu empfehlen.

Derzeit arbeitet mein Programm mit folgenden Einstellungen.

DCB dcb={0}; //erzeugen des DCB (DeviceControllBlock)
dcb.DCBlength=sizeof(dcb); //zur Parametrierung der Kommunikation
GetCommState(m_PortHandle,&dcb);

switch(devSet->m_Connection.baud) //Setzen der BaudRade
{
case 0:dcb.BaudRate=CBR_115200; break;
case 1:dcb.BaudRate=CBR_19200; break;
case 2:dcb.BaudRate=CBR_9600; break;
}


dcb.ByteSize=8; //Datenformat festlegen
dcb.StopBits=ONESTOPBIT; // 8N1 (8DataBits,NONParity,1StopBit)
dcb.Parity=NOPARITY;

SetCommState(m_PortHandle,&dcb);


COMMTIMEOUTS timeouts={0}; //Timeouts festlegen
timeouts.ReadIntervalTimeout=1000;
timeouts.ReadTotalTimeoutConstant=1000;
timeouts.ReadTotalTimeoutMultiplier=1000;
timeouts.WriteTotalTimeoutConstant=1000;
timeouts.WriteTotalTimeoutMultiplier=1000;

SetCommTimeouts(m_PortHandle,&timeouts);




Eine ähnliche Frage habe ich zu TimeOuts bei der Kommunikation über TCP-IP.
Bricht die Verbindung hart ab, markiert das TAM den TiXML-Port immernoch als belegt. Ein erneuter Verbindungsaufbau ist dann nicht möglich. Ein Reset des TAM`s gibt natürlich den Port wieder frei; mich interessieren jedoch die voreingestellen Zeiten nach dem das TAM den Port automatisch wieder frei gibt. Kann man diese Zeiten ändern?


Ähnlich bei der Kommunikation über eine Telefonverbindung. Bricht die Verbindung ab (ohne das das (lokale) Modem angewiesen werden kann die Verbindung zu beenden), bleibt das TAM (remote) verbunden. Bei einem erneuten Anruf bleibt die Leitung dann logischerweise besetzt. Nach welchen Zeit beendet das TAM die Verbindung von sich aus? Kann man diese Zeit manipulieren?

Neben einer IP-Adresse ist für eine funktionierende TCP/IP-Kommunikation auch die Angabe einer Subnetzmaske nötig (so wie auf Ihrem Windows-PC), da das Netzwerkinterface sonst nicht weiß, ob der "Gegenüber" sich im gleichen Netz befindet.
Wenn das Gerät zudem noch andere Netze erreichen soll, z.B. das Internet, ist weiterhin die Angabe eines Gateways nötig. Zudem benötigt das Gerat für die Namensauslösung (z.B. des Mailservers) einen DNS-Server.

Folgende Konfiguration wird vermutlich für Sie passen:

Es wurde hier ein klassisches Class-C Netz mit einem Router (Gateway+DNS) unter der IP-Adresse 192.168.0.1 angenommen.

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Hallo

Ich möchte die IP des TAMs ändern.
Hierfür überschreibe ich in der ISP-Datenbank den Abschnitt <Ethernet>

Ich benutze folgenden Befehl:

[<SetConfig _="ISP" ver="v">
<Ethernet>
<IP _="192.168.0.2"/>
</Ethernet>
</SetConfig>]

Das TAM quittiert die Änderung und bei Überprüfung der Datenbank sehe ich, dass die Adresse wie gewünscht umgesetzt wurde.

Das Problem: Ich kann danach keine Verbindung (TCP/IP) aufbauen.
Auch ein PING ist nicht erfolgreich.
Zum Schreiben der Konfiguration habe ich eine serielle Verbindung benutzt. Nach der Änderung habe ich ebenfalls einen (weichen) Reset durchgeführt.

Das es sich um einen Fehler an der Konfiguration meines PCs handelt, schliesse ich aus denn ein Verbindungsaufbau zu der voreingestellten IP (192.168.0.1) des TAMs funktioniert fehlerfrei.

Viele Grüße aus Dresden
Tobias