Mit Windows 7 Zeitverzögerungen

Hallo,

ich habe nach dem Umbau und Update „Verzögerungen im Betriebablauf“. Ich dachte das gibt es nur bei der Bahn, aber nun bin ich auch betroffen.

Die Historie:

[ul]
[li]Atom Board mit 7x USB nach RS232 ausgebaut
[/li][li]Board mit i3 3220T 8GB 10x RS232 on Board eingebaut (NMF93-Q77)
[/li][li]Win 7 Prof. 64Bit und IPS 3.0 installiert
[/li][li]settings.json und die Skripte meiner 2.6 Version kopiert
[/li][/ul]

Nun kommt es zu den Verzögerungen. Wenn über eine serielle Schnittstelle Befehle kommen, sollen Wagoports für etwa 300 millisekunden einschalten. Kommt innerhalb von kurzer Zeit die gleichen Befehle soll bei einigen Ports dieser erst ausgehen wenn keine Befehler mehr nachkommen.
Nun gehen die Ports meisst erst etwa 0,5-3 sec. verzögert an und aus, gehen garnicht mehr aus oder auch mal garnicht erst an.
Ein Timer der jede Minute die Uhrzeit zum Display am RS232 sendet kam auch schon 10 sec. zu spät.
LEDs an einer anderen RS232 gehen 0 - ca. 3sec verzögert an und aus.

Ich habe an der Seriellen den Debug Modus eingeschaltet - die Daten (Befehle) sind sofort dort zu sehen wenn ich auf die Fernbedienung drücke und der µC sie damit sendet.

Tests die ich durchgeführt habe:

[ul]

[li]IPS 3.0 auf 2.6 (Win7) - Fehler
[/li][li]WIN 7 auf XP Prof (IPS2.6) - OK
[/li][li]IPS 2.6 auf 3.0 (XP) - OK
[/li][li]WIN 7 neu gemacht und IPS 3.0 - wieder Fehler
[/li][/ul]
Habt Ihr noch Ideen was ich machen/testen/schauen kann?

Danke und Gruß

Jan

Hi,

hat keiner eine Idee, oder Fehlen Infos die ich noch beitragen kann?

Hab noch mal Win7 und nun mit IPS 3.1 neu installiert.

Fehler wieder da:(
Das Script das die Daten von dem µC auswertet wird sofort bei drücken der Fernbedienungstaste gestartet. Ich hab mal das Skript bei der Ausfürung genauer beobachtet das von dem Ersten gestartet wird. Es hat stark schwankende ausführungszeiten. Wenn es gut geht sind um etwa 390ms. Is sind aber Werte bis 8500ms.
Es kommt auch vor das Wago Port eingeschaltet wird und das Skript dann eine lange Pause einlegt bis er dann wieder ausgeht.


<?
 
 
 
//                $t2 = IPS_GetVariable(40174);
//                if((time()-$t2['VariableUpdated'])>1) setvalue(40174, false);
//                if(getvalue(40174)) return; // Mehrfaches Triggern in kurzer Zeit verhindern
//                   SetValue(40174, true);
 
                   ModBus_WriteCoil(53960,true);
                   COMPort_SendText(20531 , "\xffEc\0\0\xfe"); //Display C löschen
                  COMPort_SendText(20531 , "\xffEp\2\0Rolladen AUF\0"); //Text zum Display Zeile0 Stelle2
                  COMPort_SendText(20531 , "\xffEp\2\1Esszimmer 1\0"); //Text zum Display Zeile1 Stelle2
                   IPS_Sleep (300);
                   ModBus_WriteCoil(53960,false);
 //         IPS_Sleep(4000);
          IPS_RunScript(59090); //Starte Script 15887  = zur Standard Display-Anzeige zurück
                   
 
?>

Die Zeilen 5+6+7+8+16 hab ich den Test ausgeklammert

Hi Jan,

ich habe keine Erfahrung mit ser. Kommunikation mit IPS. Aber vielleicht noch die eine oder andere Idee.

Testweise mal ein anderes Installationsmedium für Win7 genutzt?
Nach der Win7-Installation mal keine MS Updates gezogen und nur IPS installiert?
Hast Du irgendeine Möglichkeit, RX/TX zu monitoren und festzustellen, ob die RS232 wirklich zeitverzögert kommuniziert?
Überprüfen, ob der Fehler mit einem FTDI USB/RS232-Adapter bestehen bleibt.
Energiesparoptionen im BIOS und in den Eigenschaften des seriellen Adapters mal deaktiveiert?
In Win7 Energieoptionen -> Profil „Höchstleistung/High Performance“ ausgewählt?
Ist Netzteil noch das selbe?
Falls Masseproblem, einfach mal die Spannung zw. PC-Gehäuse und der Masse des ser. Kabels gemessen?
Kabel defekt? ;o)
Alternative Treiber probiert?

VG
Björn

Hab nur ein 64bit Medium

beim ersten Umstieg waren die Updates nicht schnell genug und die Fehler war auch da

IM IPS das Debugfenster der seriellen Schnittstellen. Kommt dort sofort an

Idee, probiere ich beim nächsten Win7 Test aus -zu Zeit wieder XP drauf-

hoffe alle Energie-bla-bla gefunden zu haben, werde bein nächsten Win7…

wird auch getestet/gesucht

das alte beim 1.Test, 2. Test ein anderes

bei XP gehts mit gleicher Hardware

bei XP gehts mit gleicher Hardware, und 10x Seriell mit gleichem Fehler

hab gestern welche gefunden. Nächster Win7 Test…

Danke für die Tips

Jan

So, beim Basteltreffen mal wieder Probiert…

  • WIN7 64bit neu aufgesetzt und neue Treiber verwendet
  • feste IP vergeben
  • WAGO und PC mit X-Kabel direkt verbunden
  • die andere LAN Buchse des MB genutz
  • die freie deaktiviert
  • PCI-E LAN Karte eingebaut
  • WIN7 32bit installiert

alles nichts geholfen.

In den Debugfenstern kann man sehen das die Seriellen Schnittstellen sofort die Daten bekommen und senden, die Skripte gleich starten. Sobald im Skript die Wago angesprochen wird stockt es. Das sieht man auch beim Debug der Wago - die Daten gehen verzögert raus.

Gibt es noch Ideen?

Jan

Hallo zusammen,

welcher Treiber wird für die Onboard Seriellen benutzt ?
Kann aus der Doku beim Hersteller leider den Chipsatz der COM-Ports nicht
erkennen.

Ich würde es auch mal mit einem FTDI-USB-Seriell testen.

Das kann auch mit den Einstellungen der COM-Ports im Bios bzw.
im Gerätemanager zu tun haben. Übertragungsrate, FIFO-Puffer
Handshake etc. Bei Windows 7 werden andere Standardeinstellungen
gesetzt als bei XP

Dann würde ich mal 9 COM-Ports im Bios deaktivieren und nur mit einem
Port testen.

Ich habe bei mir massive Probleme mit dem Timing meiner Heizungssteuerung
am Seriell-Port mit XP gehabt. Ich spreche die Serielle Schnittstelle nun direkt
über PHP an. Seit dem ist das Problem behoben.

Nur mal als kleine Anregung eine Ausschnitt aus meinem Script:

$fp = fopen ("COM4:", "w+");
if (!$fp)
	{
    echo "Uh-oh. Port not opened.";
    }
	 else
	 {
	 if ($Command == "V520000")
	{
	fwrite ($fp, ($Command.$Ckecksum));
    	ips_sleep(300);
fwrite ($fp, ($Command.$Ckecksum));
    	ips_sleep(300);
    	
	 	}

Gruß Udo

Die COM-Ports scheinen nicht das Problem zu sein. Die Daten werden sofort eingelesen und verarbeiten und auch wieder zurückgegeben. Sobald aber die Wago über´s LAN ins spiel kommt, gibt es die Verzögerungen. Wir haben die Skripte mal so umgebaut das erst die ganzen „seriell“ Sachen bearbeitet werden und dann die Wago, das Skript läuft bis zum ersten Wago-Befehl ohne Verzögerungen. Wenn die Debug-Fenster offen sind, kann man das auch sehr schön beobachten.
Ich hab mal wieder WIN7 64bit frisch drauf gemacht und getestet…
kein einziger Treiber - geht, freu… …aber warum nur? Hatte ich es doch nicht schon mal so??? Der Test erfolgte über die „AN“ „AUS“ Schaltknöpfe in der WAGO-Port Konfiguration, damit kein Skript und keine anderen Ports usw. dabei die beeinflussen könnten.
Chipsatz Treiber installiert - geht nicht mehr
Wir haben es noch mal mit anderen Treibern für die LAN-Schnittstelle versucht und Einstellungen in WIN7 für diese rumprobiert - nigs. Leider waren es alles nur Intel karten. Für die alte PCI 3Com keine Treiber mehr gefunden. Wird mal nach anderen Karten suchen.

Man weiß auch langsam garnicht mehr was man so alles wann in welcher Reihenfolge gemacht hat…

Jan

Vielleicht noch eine kleine Idee.

Mal in der Netzwerkkarte den LAN-Port auf 100mbit und Half-Duplex festeinstellen.

Ich habe hin und wieder in der Vergangenheit das Problem gehabt das Gigabit-Karten
sich „verschlucken“ wenn die an 100mbit hängen und auch der Voll-Duplex macht schon mal Probleme.
MTU-Wert wäre auch noch eine mögliche Ursache.

Wenn die Karte am Gigabit - Switch hängt dann stellt die sich bei Win7 je nach Treiber automatisch auf JUMBO-Frames ein, was für 100mbit Geräte problematisch ist.

Da XP das noch nicht unterstützt hat, wäre das die Erklärung warum es mit XP auf gleicher Hardware läuft.

Also einfach mal testweise die Netzwerkkarte wie oben geschrieben umstellen.

Gruß Udo

Alternativ mal folgendes testen:

Unter win7 auf die kommandozeile wechseln und folgendes prüfen:
Ab win7 (soviel ich weiss) wurden netzwerkseitig einige Optimierungen vorgenommen.
Diese bereiten manchmal mit „älterer“ Hardware Probleme.

Daher auf die Kommandozeile wechseln und folgendes anschauen.

netsh int tcp show global

dort steht vermutlich :
->Receive-Side Scaling State: Enabled
-> Receive Windows Auto-Tuning Level: Normal
-> Add-On Congestion Control Provider: ctcp

Wird wie folgt geändert (dabei passiert nichts schlimmes am System!)

netsh int tcp set global RSS=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global congestionprovider=none

Danach in Registry (regedit.exe) wechseln und folgende Schlüssel nachtragen:

[b]HKLM\System\CurrentControlSet\Services\Tcpip\Parameters[/b]

Dort „Neuer DWord WertENABLETCPA mit 0 erstellen

PC neustarten und alles nochmals testen…

War einer der Tests, aber mit 10mbit, da meine Wago nur 10 macht.

Läuft mal wieder auf XP damit es einsetzbar ist. Beim nächsten Versuch werd ich es testen.

Dank Euch beiden.

Jan

Hallo Jan,

ich setze selber keine WAGO ein deshalb wusste ich nicht das die nur 10mbit kann.

dann natürlich 10mbit Half-Duplex

Wenn das Problem nur mit der Wago auftritt was ja so scheint, dann würe ich mir
eventuell mal für knapp 10 EUR eine einfache Realtek PCI Netzwerkkarte besorgen. Aber
keine Gigabit sondern nur eine 10/100er.

Gruß Udo

Kommt auf dasselbe Ergebnis wie mein Vorschlag :slight_smile: - Nur kostet mein Lösungsvorschlag nix :wink:

Bei einer neuen/alten Netzwerkkarte könnte es aber weiterhin vorkommen, dass Win7 standardmäßig versucht die Karte „zu optimieren“… mit den genannten Einstellungen…

Nee, gibt auch andere, meine Version kann halt nur 10.

Eure Diskusion untereinander hilft mir zu verstehen was und warum ich was ausprobieren soll:)

Jan

@ Mastermind

Wobei ich nicht ausschließen möchte, das die Southbridge von dem Intelchipsatz auch
ein wenig zu diesem Problem beiträgt gerade weil die auch noch mit der Verwaltung der 10
seriellen beschäftigt ist. Oder es einfach ein Problem des Win7 Intel-ICH Treiber ist.

Daher der Vorschlag mit der getrennten Netzwerkkarte.

Gruß Udo

Das der Rechner mit den 10 RS232 unter WIN7 mehr zu tun hat als unter XP kann ich mir nicht vorstellen.
Leider habe ich in den nächsten Tagen auch keine Zeit zu testen (braucht ja etwas länger sone Aktion). Ich sammel aber Eure Idenn und Tips und werde sie dann testen, vor allem werde ich noch mal als erstes ohne Chipsatz-Treiber probieren ob es dann wieder geht. Dann den Treiber drauf und Eure Tips durch gehen.

Jan

Danke das hat leider keine Besserung gebracht.

Nach einigen vielen Tests und ausprobierten Dingen - z.B. WIN8 und ging auch nicht - haben wir die Ethernet-Kommunikation mit der Wago beobachtet. Dort ergeben sich wiederholnde Pausen in der Kommunikation die einige Sekunden andauern.
Die Einzige Besserung hat sich nur ergeben wenn von den 35 eingerichteten Eingängen der Wago 32 zum Test gelöscht wurden, die Pausen traten extrem selterner und kürzer auf.
Auf dem folgenden Bild sieht man die letzten Einträge vom Debug-Fenster wenn solch eine Pause eintritt.

Hat einer eine Idee was da schief läuft?

Jan

Hallo,

Vielleicht hilft das hier (im Thread ganz unten):
http://www.control.com/thread/1341225864

Uups steht ja so ähnlich schon in #10.
GGf. müsste man mal mit Wireshark die TCP Verbindung loggen, und schauen, warum von der WAGO keine Antwort kommt.

Grüße

Kalle Wirsch

Neue Infos… …es geht:)

Weiterer werdegang bis zur Funktion:
die WIN7 Platte wieder eingebaut und…
-einen weiteren 842 ausgeliehen - gleiche Problem wie bei meinem 842er
-einen 341 von einem netten Forumskolegen gekauft - und siehe da, mit diesem geht es

Er ist jetzt seit etwa einer Woche in Betrieb und es geht immer noch.
Jetzt kommt nur noch die nächsten Tage eine WIN7 Neuinstallation drauf, damit die ganzen Test und Spielereien nicht irgendwo noch rumschlummern.

Danke für die Hilfen/Tips

Jan