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?
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
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?
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.
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);
}
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…
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.
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:
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.
Kommt auf dasselbe Ergebnis wie mein Vorschlag - Nur kostet mein Lösungsvorschlag nix
Bei einer neuen/alten Netzwerkkarte könnte es aber weiterhin vorkommen, dass Win7 standardmäßig versucht die Karte „zu optimieren“… mit den genannten Einstellungen…
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.
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.
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.
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.
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.