ToniTools

Das mit dem 1-2 mal den Dienst durchstarten kommt häufiger vor. Den genauen Grund dafür kenne ich nicht. Aber wenn die Settings.xml sauber gespeichert ist gibts keine Probleme. Hab den Tip auch mal auf meine Website genommen.

Das mit der langen Scriptlaufzeit gabs auch beim Snarlifier. Dort hab ich eine Ping-Funktion mit eingebaut um lange wartezeiten zu verhindern wenn der Rechner nicht antwortet. Das könnte ich auch bei den TTs einbauen.

1006 bedeutet ERR_COMMUNICATION_ERROR.

Toni

Hallo zusammen,

ich bekomme die TTs nicht zum Laufen.

Daten: XP mit SP3, IPS 2.04 (nicht 2.1!)
An dem Server arbeite ich per Remote Desktop.

Die dll ist im modules-Ordner. Client.exe läuft auf dem Server, die ini ist im gleichen Verzeichnis und hat die IP des Rechners.

Mehrfach habe ich den Rechner neu gestartet und auch den Dienst aus und angeschaltet.

Ich kann einfach keine Instanz anlegen; da gibt es nichts zum Auswählen auch nicht bei „alle Module anzeigen“.

Ist die Version 2.1 jetzt zwingend erforderlich, für die TTs?

Gruss NBA

Ja…

Die alte Version (für den Kernel 2.04) ist datentechnisch kompatibel und du findest sie auf Tonis Welt im Archiv… Nur downgraden und die Einstellungen bleiben erhalten.

Toni

Hallo Toni,

habe jetzt den Umstieg auf 2.1 gemacht. Ging alles super glatt bis auf deine ToniTools leider:

den „localhost“ kennt er gar nicht mehr. Da kommt immer der -1001 Error.

Ersetze ich den „localhost“ durch „127.0.0.1“ dann geht schon etwas mehr:

TT_TaskBarVisible("127.0.0.1",False);

funktioniert, aber es dauert ewig und es kommt der Fehler Warning: A ToniTools error occured: Communication error. (-1006) in [HMI\HMI_Taskbar_hide] on line 11

Ist die Taskbar ausgeblendet und ich blende sie wieder ein, so kommt kein Fehler. Ist die Taskbar aber eingeblendet und ich versuche sie trotzdem einzublenden, so kommt auch der 1006 Fehler (sehr seltsam)

	$idle = TT_Idle("127.0.0.1");

ghet leider überhaupt nicht. Ich bekomme keinen Wert retour und es kommt auch der 1006 Fehler.:mad:

Ob mit oder ohne Firewall macht keinen Unterschied. Auch auf meinem Testrechner ist das Verhalten genau gleich. Die ToniTools sind frisch von deiner Homepage gesaugt.

Gruß
Rubberduck

hi…

bin grad unterwegs in der s-bahn. localhost geht nicht weil ich aktuell keine namensauflösung drin hab. ip sollte aber gehen. was sagt denn die tonsole welche rechner sich am server angemeldet haben?

Hi Toni,

Tonsole meldet bei „Clients online“ den 127.0.0.1.

Gruß
Rubberduck

Dann verstehe ich dein problem nicht… Sollte dann schon auch gehen. :confused: Ich verstehe aber auch nicht sonderlich viel von „netzwerk-voodoo“. Hat aktuell noch jemand dieses 1006 Problem?

Toni

Hi Toni,

Ich hab jetzt mal auf meiner Testmaschine die settings.xml gekillt und das IPS dann quasi jungfräulich hochgefahren. Danach deine ToniTools-Instanz angelegt und ein kleines Skript in Anlehung an tgusi74 der scheinbar ja auch so ein Problem hat.


echo "IDLETIME = ".TT_Idle("127.0.0.1")." Sekunden
";
echo "UPTIME = " . TT_UpTime("127.0.0.1") . " Minuten
";
echo "MEMORY = " . TT_GetRAM("127.0.0.1",'TotalPhys') . " Bytes
";
echo "IPS.EXE - SPEICHER = " . TT_GetProcessMemory('127.0.0.1', 'ips.exe') . " Bytes
";

Das Ergebnis sieht dann so aus:


Warning:  A ToniTools error occured: Communication error. (-1006) in C:\IP-Symcon\scripts\36748.ips.php on line 4
IDLETIME =  Sekunden
UPTIME = 33 Minuten

Warning:  A ToniTools error occured: Communication error. (-1006) in C:\IP-Symcon\scripts\36748.ips.php on line 7
MEMORY =  Bytes

Warning:  A ToniTools error occured: Communication error. (-1006) in C:\IP-Symcon\scripts\36748.ips.php on line 8
IPS.EXE - SPEICHER =  Bytes

Also schon seltsam. TT_Uptime geht immer. TT_GetProcessMemory ging auch einmal. Dann nicht mehr.:confused:

Kille ich den TTClient-Task, so melden TT_Idle, TT_GetRAM und TT_GetProcessMemory den 1001-Fehler (Ist ja klar). Nur TT_UpTime, welches als einziges vorher ging, meldet dann den 1006-Fehler :confused:

Mein Problem ist, dass ohne deine genialen Tools mein Touch+Server nicht mehr richtig funktioniert (Screensaver, Taskbar on/off, zu gewissen Zeiten kein Screensaver, Im Idlezustand generierung von Graphen,…).Ich sehe schon wieder ein paar graue Haare mehr im Spiegel:(

Gruß
Erich

Hallo Toni,
Hallo Rubberduck,
ich habe natürlich auch immer noch das Problem mit der „-1006“

… wie sieht es mit dem Versuch aus

Das mit der langen Scriptlaufzeit gabs auch beim Snarlifier. Dort hab ich eine Ping-Funktion mit eingebaut um lange wartezeiten zu verhindern wenn der Rechner nicht antwortet. Das könnte ich auch bei den TTs einbauen.

Wenns nicht hilft, schaden kann es ja nicht :wink: (aber das mein LOCALHOST (127.0.0.1) nicht erreichbar sein soll glaube ich nicht :smiley:
) ==> ist das Script nicht nach 1500ms fertig, kommt mit Sicherheit mindestens eine Funktion aus dem Testscript mit -1006 zurück

kann auch wie Rubberduck feststellen das „TT_UpTime“ und „TT_Shredder“ noch nie mit einen Fehler zurückgekommen ist, alle anderen Funktionen wechseln sich ab „TT_GetProcessMemory“, „TT_Idle“, „TT_GetRAM“ , …

tgusi74

Hallo Toni,

gibt’s dazu schon eine Idee von dir? Oder brauchst du noch Infos?

Viele Grüße
Rubberduck

Die „-1006“ bedeutet, wie bereits erwähnt, Netzwerkfehler. Das bedeutet die Kommunikation kommt nicht zu stande oder bricht mitten im Datentransfer ab.

Keinen Plan was das sein könnte. Wenn das Netzwerk funktioniert sehe ich keinen Ansatzpunkt zum debuggen. Bei mir - und ich nehme an allen anderen Usern - funktioniert es einwandfrei…

Hab aktuell über 200 unterschiedliche IP-Adressen, die die neuen TTs von meiner Seite geladen haben. Selbst wenn nur die hälffte die TTs produktiv einsetzen ist das eine stattliche Anzahl User. Und Probleme in dieser Richtung sind mir sonst nicht bekannt.

Toni

Schade, werde dann wohl die ToniTools ad acta legen müssen. Da ich ja nur einer von zwei betroffenen Anwendern bin, sehe ich ein dass du keine genauere Analyse machen möchtest. Sollten zukünftig noch andere Anwender mit demselben Problem hinzustoßen so halte ich hier nur zur Sicherheit die Erkenntnisse der letzten 4 Stunden erfolgloser Fehlersuche fest:

[ul]
[li]Selbes Verhalten auf 3 verschiedenen Maschinen.
[/li][li]XP-Deutsch SP2 und SP3
[/li][li]Installation des MS-Loopback-Adapter bringt keine Hilfe.
[/li][li]Änderung der Loopback-Adresse bringt keine Änderung im Verhalten.
[/li][li]Komplett neu aufgesetztes IPS mit nur einem Testskript reagiert auch fehlerhaft.
[/li][li]Sobald die Verbindung nicht mehr über Loopback geht, sondern ein anderer Rechner angesprochen wird, geht es (2 Maschinen: Jede für sich lokal geht nicht, Abfrage der Remote geht (natürlich nach Änderung der ini))
[/li][/ul]

Leider gibt es keine Möglichkeit mit einem Packet-Sniffer den Loopback-Port zu tracen. Darum sind damit meine Möglichkeiten der Fehlereingrenzung erschöpft.

Sollte noch jemand eine gute Idee haben, bin ich dafür natürlich sehr dankbar. Ansonst bleibt mir nichts anders mehr über, als die benötigten WinAPI-Zugriffe irgendwie extern selbst zu schreiben.

Gruß
Rubberduck

Möchtest ist gut… Was kann ich denn machen? Von Netzwerk hab ich keinen blassen schimmer und unter W2k, WinXP und Vista hatte ich bislang keine Probleme.

Sobald die Verbindung nicht mehr über Loopback geht, sondern ein anderer Rechner angesprochen wird, geht es

Tja… Die Pointe ist, dass ich nur mit der 127.0.0.1 entwickle. Andere Rechner binde ich erst ein wenn ich mir sicher bin, dasss alles funktioniert. Und die Netzwerkkomponente, von mir selbst entwickelt, basiert auf einer weit verbreiteten Standardlösung die, neben unzähligen Delphi-Anwendern, auch paresy kennt und verwendet (Indy). Die von mir entwickelte BiDi-Client-Server-Client Komponente wird auch bei uns in der Firma in zwei Projekten mit ca 200 Clients verwendet. Allerdings nicht mit localhost - Hätte nicht gedacht, dass das einen unterschied macht…

Wenn du also einen Vorschlag hast wo ich diesen Bug suchen soll… Immer her damit.:rolleyes:

Wenn du Software und Hardware ausgeschlossen hast, was soll ich dir erzählen? Mal ne Standard PCI-Netzwerkkarte probiert? Verwendest du Win oder Hersteller treiber? Was ist ein MS-Loopback-Adapter? Dass „localhost“ nicht funktioniert hast du gelesen?

Edit:

Hast du mal versucht deine externe IP in der INI einzutragen? Ich kanns grad nicht testen. Dann müsste diese in der Tonsole angezeigt werden und auch ansprechbar sein.

Toni

Hallo Toni,
Hallo tgusi74,

sorry erstmal für die späte Antwort - war auf Dienstreise.

Ich habe das Problem zwar nicht gelöst aber erfolgreich umschifft:

Der Fehler tritt immer auf, sobald die Anfrage auf die lokale Adresse geht. Egal welche lokale Adresse. Das bedeutet, immer dann wenn die Pakete nicht auf das Netzwerk gehen, sondern lokal rückgespiegelt werden, kommt der Fehler. Also warum nicht einfach die Pakete aufs Netzwerk raussenden und irgendwo retourspiegeln?! Nur wo geht das? -> Am Standardgateway. Was habe ich im Detail gemacht:

1.) Ich habe meiner Netzwerkkarte eine 2. IP-Adresse verpasst: Die erste lautet x.x.x.16, die 2. ist x.x.x.17. Das muß zwar nicht sein, aber so gehe ich auf nummer sicher, dass ich nicht eine andere Applikation welche auch einen Loopback macht beeinflusse.

2.) Diese neue Adresse habe ich in die TTClient.ini an Stelle der 172.0.0.1 eingetragen.

3.) Jetzt habe ich dem System mitgeteilt, dass alle Anfragen an die x.x.x.17 zuerst an mein Standardgateway x.x.x.254 gehen sollen (Dieses spiegelt sie dann automatisch retour). Das geht über die DOS-Box:

route -p add x.x.x.17 mask 255.255.255.255 x.x.x.254 metric 1

4.) TTClient neu starten und ab geht die Post :smiley:

@Toni: Hier noch die Antworten auf deine Fragen, falls dir das Problem noch wo anders unterkommt:

Mal ne Standard PCI-Netzwerkkarte probiert?

3 verschiedene Rechner mit 3 verschiedenen Karten. Laptop/Desktop gemischt. Sogar ne Virtuelle Maschine Probiert.

Verwendest du Win oder Hersteller treiber?

Bunt gemischt.

Was ist ein MS-Loopback-Adapter?

How to install the Microsoft Loopback adapter in Windows XP

Dass „localhost“ nicht funktioniert hast du gelesen?

ja, ist mir klar

Edit:

Hast du mal versucht deine externe IP in der INI einzutragen? Ich kanns grad nicht testen. Dann müsste diese in der Tonsole angezeigt werden und auch ansprechbar sein.

Habs mehrfach probiert über die normale Netzwerkkarte, den Loopback-Adapter und ein virtuelles Netzwerk. Tonsole hat den Client immer richtig angezeigt!

So, jetzt kann ich mich wieder mit ruhigem Gewissen an neue Dinge herantasten (So eine Fehlersuche hat schon auch gute Seiten - Ich habe mal deine Doku gelesen. Da sind mir einige seeehr interessante Funktionen ins Auge gesprungen:rolleyes:)

Viele Grüße
Rubberduck