Na ich hab doch geschrieben, ich will ein Programm schreiben mit dem ich Daten aus mehreren PLCs lesen kann und gleichzeitig
Das habe ich schon verstanden - nur deine letzten Ausflüge Richtung Echtzeit-Erweiterung passen nicht ins Bild - oder du hast eben immer noch nicht
gesagt was du mit der Erweiterung machen willst/dir erhoffst? Und weil ich nicht verstehe was dir das in deine jetzigen Situation bringen soll wirkt dein
Echtzeitfachwissen ein wenig Wikipedia-basiert
mein Wissen über Multi-Threading erweitern und die Grenzen der Soft-realtime von Windows und vb.net austesten.
denkst du das du mit den 30ms per TCP/IP und den paar Threads schon an die Grenze von Windows/VB.Net gehst? - das fehlt aber schon noch was
die SPS ist hier die stark beschränkende Einheit - und moeglicherweise dein Chart wenn schneller Datenkommmen - und da kannst du nur noch mit direkter SPS<->PC TCP/IP-Kommunikation (also mit SPS Programmierung) mehr erreichen
Das hat aber alles absolut nichts mit der Echtzeitfähigkeiten von deinem Betriebssystem noch VB.Net zu tun - oder was denkst du?
Erstmal: Profiler - wo sind deine Bottlenecks
ANTS von Redgate (als Demo)
http://www.red-gate.com/de/products/dotnet-development/ants-performance-profiler/
1. Strategie - Belastungstest deiner Infrastruktur (mit Profiler)
Erweiter dein Sytem um eine "künstliche" SPS(libnodave Klasse) die sehr sehr viel schneller Daten liefert als die echte SPS und schau welche Raten du da erreichst
Falls du die libnodave Aufrufe in einer Klasse gekapselt hast diese durch einen libnodave-Fake ersetzbar machen (mit gleichem Interface)
du solltest damit so nah wie moeglich an der SPS bleiben damit deine künstliche SPS auch durch deine normale Infrastruktur Daten liefert - keine Abkürzungen
damit kannst du im Profiler viel deutlicher feststellen wie Performant deine Verarbeitung ist UND Synchronisationsprobleme-Probleme besser/häufiger Aufdecken -> langsam=fast immer sicher, sau-schnell=böse
erstmal deine GUI komplett für das Profiling abkoppel (mach es am besten abkoppelbar) - und keine Ausgabe (auch nicht Konsole - die ist noch langsamer wegen den Consolen-Puffern)
2. Strategie - eine schnellere SPS die ueber libnodave funktioniert
Installier (als Demo) dir die Soft-SPS von Deltalogic damit kannst du unbegrenzt Read/Write per libnodave machen
http://www.deltalogic.de/automatisierungstechnik/software/accontrol-s7-win32.html
nur eben schneller als mit der echten SPS
3. Strategie - auch mal eine andere Kommunikationlibrary - siehe AGLink (
http://www.deltalogic.de/automatisierungstechnik/software/accon-aglink.html) - auch mit VB.Net, einfach nur als vergleich
Vergleichen ist immer gut um ein Gefühl für die Komponenten (GUI, SPS-Kommunikation, Infrastruktur) zu bekommen
(4. Strategie) ein anderes Chart-Tool
also
Code:
SPS (echte S7, Accontrol) --------> Kommunikations-Object ( per Libnodave, als Simulation (=brutal schnell), AGLink) ----> deine Infrastruktur (Liste, Puffer, etc) ----> GUI/Chart (z.B. [URL]http://arction.com[/URL])
fuer die Verbindungsabstraktion wuerde ich zur Vereinfachung folgendes machen
Code:
class DBVar
DB-Nr, Offset, Value
interface Verbindung
Verbindung(IP, Rack, Slot)
Read(DBVar)
Read(DBVar[])
konrekte Klassen mit den spezifischen Konstruktor und Read-Methoden
class LibnodaveVerbindung: Verbindung
class AGLinkVerbindung: Verbindung
class SimulationVerbindung: Verbindung (liefert einfach fixe Werte - kein Random weil das auch Zeit kostet)
wenn du dann die Verbindungsklasse als generischen-Parameter in deinen Test gibts kannst du leich hin und her wechseln
- und dein ganzer Code mit Thread pro SPS, Thread pro Verbindung usw bleibt voellig unveraendert (das/soll muss auch so sein)
und du musst damit es Sinnvoll ist die Strategie 1 (Profiling, Messen) und dann Strategie 2 fahren
Gleichzeitig bin ich auf der Suche nach Verbesserung der Realtime-Faehigkeiten.
Denn unter vb.net bin ich da sicher an der Grenze des machbaren.
Wenn du auf der TCP/IP-Seite nichts mehr reissen kannst (und die Kommunikation dort ist ja nicht wirklich Umfrangreich)
kannst du nur doch an deinem Programm arbeiten - da wäre Strategie 1-4 schon mal der richtige Weg
Wenn ich da mehr C++ programmieren muss, auch gut.
erstmal dein VB.Net Programm ordentlich Benchmarken (die künstliche Tests mit einer simulierten SPS)
das Wissen laesst sich genau so auf C++ anwenden - nur eben kleiner/statische
