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.
ich habe vorgestern von V2.7 auf V3.2 umgestellt und habe ein ähnliches Problem.
Verwendet wird Windows 2008r2 64bit mit Realtek RTL8168B/811B-Familie-PCI-E-Gigabit-Ethernet-NIC (NDIS 6.2) als Onboard Karte
Folgender Code
$rollos = array(28839 /[Räume\Wohnzimmer\Rollladen links]/ ,35463 ,
32521 /[Räume\Wohnzimmer\Rolladen Tür rechts]/ ,18310 );
set_rollo(array(0,0,0,0));
function set_rollo($daten){
global $rollos;
for ($i=0;$i<4;$i++){
$time = -microtime(true);
ModBus_WriteRegisterByte($rollos[$i], $daten[$i]);
IPS_Sleep(10);
$time += microtime(true);
echo "Runde $i ".sprintf(’%f’, $time),PHP_EOL;
}
}
sorgt für folgende Ausgabe (mit mehreren Durchgängen immer ähnliche Ausgaben
Vorher musste ich mit V2.7 die Sleep auf 200ms setzen, damit die Rolläden (normal noch etwas mehr) nicht absolut gleichzeitig losfahren um Stromspitzen zu vermeiden. Sprich vorher wurde der Befehl absolut synchron ausgeführt.
bei mir hab ich den Fehler nur wegbekommen in dem ich eine andere Wago genommen habe. Nach Deiner Signatur hast Du aber nicht die 841er die bei mir die Probleme bereitet hat.
Alles andere, WIN 32 oder 64 bit / Netzwerkartentausch (Onboard, PCI, PCI-E, verschiedene Hersteller) / Netzwerkeinstellungen / Switch, Hub oder Kreutzkabel hat nichts gebracht. Eine Reduzierung der I/O-Bausteine brachte eine „kleine“ Besserung.
Aber es kann doch nicht sein, dass es mit der V2.7 auf dem gleichen Rechner ging. Ich habe dazu folgendes im Internet gefunden: http://sourceforge.net/projects/delphimodbus/ vielleicht hilft das ja noch weiter.
an paresy: wurde zwischen 2.7 und 3.2 irgendwas am TCP/IP Stack bzw. Modbus Modul in IPS umgebaut?
Es waren nicht die Verschiedenen IPS Versionen sondern WIN7 das die Probleme brachte. Ältere IPS Version mit WIN7 ging auch nicht. Demnach muss es wohl eine Änderung im Windows gewesen sein. Jede Kombination mit XP die ich ausprobiert habe hat funktioniert. Ich hatte auch befürchtet das die WIN7 Updates irgenetwas verändern und hatte alles getestet bevor ich die Updates installiert habe, aber nö.
Dann haben wir wohl nicht die gleichen Probleme, denn bei mir lief es mit Windows 7 lange problemlos. Das Problem ist Wago bekannt und es gibt eine neue DLL, diese müsste nur in IP-Symcon eingebunden werden, ich kann das leider nicht und ging auch davon aus, dass die Modbus Kommunikation weiterhin so läuft wie mit der alten Version.
Ich konnte es in der Zwischenzeit auf einem Windows 7 32bit Rechner mit Intel Netzwerkkarte Testen, gleiches Problem. Jetzt hoffe ich auf den IP-Symcon Support, dass denen noch was einfällt.
Nachtrag vom 09.01.: Ich habe heute Mittag mit einem kleinem Script
meine Modbus Geräte alle auf einen Schlag verändert und kann sagen, dass das Schreiben mit 2s Abfrageintervall wieder geht. Grund ist: Die Lese Anfrage blockiert die Kommunikation. Daher kommen die Schreibbefehle nicht mehr durch.
- Nur kostet mein Lösungsvorschlag nix 
