FW oder Virenscanner kann ich ausschließen, aber deine erste Idee klingt gar nicht mal so schlecht! Mein Programm braucht in der Tat ein paar Sekunden zum Start, da erst noch ein größeres TreeView aus der
DB befüllt wird nebst anderem Init-Krams. Ich werde morgen testweise eine Pause einbauen, ich hoffe dass sich das Problem jetzt nicht zu rar zum brauchbar testen macht.
Ich kenne das auch noch von Siemens SPSen, die nach (auch regulärem) Trennen der Socket-Verbindung zu projektierten Fetch/Write Ports rund 20s brauchten bis sie wieder eiine Verbindung annahmen. Aber seit wir auf das S7Online Protokoll via libnodave umgestiegen sind, kein Problem mehr. Von daher absolut plausibel. Bin gespannt.
Das einzige was mich ein wenig pessimistisch stimmt ist, dass ich heute morgen im Log Verbindungsversuche durchgehend von 4:30 bis 9:00 Uhr hatte, und ich das Prgoramm dann beendet habe. Ich hoffe, dass das Gateway dann aktiv geblockt hat wegen zu früher Anfragen oder so. Was aber auch dämlich wäre. Egal, probieren! Danke!
Edit wegen deinem Edit: Klingt durchaus auch plausibel. Ich weiss jetzt nicht wie genau die Gateways intern funktionieren - Mini-PCs sind es definitiv nicht - aber vielleicht haben die ein vergleichbares Problem. Das könnte auch ggf. erklären warum schnell wiederholte Anfragen den Zustand einfrieren: Vielleicht hat der "tote" Socket noch eine Karenzzeit nach dem er das Reset geschickt hat, welche ich so immer neu aufziehen würde. Probieren!
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)