Nun zu meiner Frage:
Zur Visualisierung und Programmierung reichen derzeit die Möglichkeiten der Motion Control aus (Profibus, Visualisierung mit systemeigener Software) - wie schaut es aber aus, wenn ich zusätzlich mit Datenverwaltungen über eine DB arbeiten möchte, visualisieren und programmieren mit VC++, wie schaut hier die Schnittstelle aus zwischen der Windowsanwendung und dem IndustriePC, dh. wie kann ich Daten austauschen, wie greife ich auf Datenbanken zu ?

Es geht mir hier nicht um Details, sonder nur, wie das grundsätzlich aussieht. Außer SPS-Programmiererfahrung habe ich noch relativ gute (Schul-)Kenntnisse in C.

Vielleicht könnte mir da wer helfen , danke schon mal im Voraus.

Ganz abgesehen davon gibt es natürich auch noch spezielle Visualisierungs-Werkzeuge...
Wenn Du unter Windows was eigenen machen willst, Rate ich Dir zu C# und Windows-Forms.

Wie sieht es eigentlich mit dem DB-System aus - was verwendet man ? - Oracel, SQL, MS ...?

...rate ich davon ab, da schon zu alt...

alt == schlecht?

Folglich ist es angebracht, wenn man die Daten über einen Puffer abkoppelt, d.h. die Applikation schreibt regelmäßig in den Puffer, und dieser wird von einem Thread in die DB geschaufelt. Man sollte in der Visualisierung niemals darauf angewiesen sein eine Verbindung zur DB zu haben, und man sollte niemals auf die Zugriffszeit der DB angewiesen sein.

Wir setzen PostgreSQL ein, auf einem Linux-Server, dort nimmt ein JavaBeans via Webservice die Daten von den Windows-Systemen an.

Ansonsten kann ich auch - wie Jochen sagt - den MS SQL Express empfehlen.

In solchen Systemen kann man schon gut Daten wegschreiben, bis zu 100ms in der Größenordnung einiger 1000 Datenpunkte ist kein Hexenwerk.

Und bei OPC unterstütze ich ebenfalls Jochen: Softing. Softing. Softing. Nix anderes. Es gibt billigere Lösungen für OPC, aber das ist der Beste.

Die SPS stellt einen sogenannten "OPC-Server" zur Verfügung, der bietet ein Abbild aller Daten in der SPS als Baum an. Diesen OPC-Server bekommt man z.B. vom Hersteller der SPS oder von Drittanbietern. Nun benötigt man einen OPC-Client - den man mit Hilfe einer API wie von Softing - den man in sein Programm einbaut. Dieser OPC-Client liest/schreibt nun Daten vom OPC-Server. Das kann man dann verwursten. Wichtig ist, daß der OPC-Client und der OPC-Server nicht auf dem gleichen Rechner laufen müssen, sondern sie können auf unterschiedlichen Rechnern sein, die Daten werden dann via Netzwerk zwischen dem OPC-Server und dem OPC-Client übertragen.

Die Anbindung zur Datenbank ist dann z.B. ADO.NET.

----
@Jochen: habt Ihr eigentlich schon mal OPC XML DA ausprobiert? Taucht das? Schnell?

@Jochen: habt Ihr eigentlich schon mal OPC XML DA ausprobiert? Taucht das? Schnell?

Taucht nix, ewig langsam... zumindest um Faktoren langsamer als COM.
Es ist laut OPC-Foundation auch nicht dafür gedacht eine Kommunikation mit einer SPS zu machen, sondern eher um weiter oben angesiedelte Systeme miteinander zu verbinden.
Die UA zielt da auch eher auf Dinge ausserhalb der SPS ab... Die OPC-Foundation sieht die SPS nur noch als ein Punkt für OPC...

Mir ist es ja hauptsächlich darum gegangen, nicht in die falsche Richtung loszustarten - ich denke, nun fürn Anfang das richtige System gewählt zu haben. Danke.