# Mit C# auf SPS zugreifen



## Red-Sh4nks (24 Januar 2010)

Hallo erst mal.

Ich würde gerne mit C# auf eine SPS zugreifen.
Genauer gesagt eine S7-300 CPU 315. Die SPS
ist mittels Profibus verbunden.

Wie stell ich diesen Zugriff an? Kann ich ganz
einfach über die serielle Schnittstelle arbeiten?
Gibt es Beispielcodes?

lg Marco*


----------



## Rainer Hönle (24 Januar 2010)

Einfach eine Bibliothek wie libnodave, ACCON-AGLink oder ähnliches benutzen.
RS232 geht nicht. Es wird ein entsprechender Adapter benötigt.


----------



## Red-Sh4nks (24 Januar 2010)

Ich würde das ganze gerne ohne libnodave
zustande bringen. Also nur mit C#. Ist sowas
überhaupt möglich?

lg*


----------



## Rainer Hönle (24 Januar 2010)

Klar ist das möglich. Einfach das Protokoll direkt in C# implementieren.


----------



## Red-Sh4nks (24 Januar 2010)

Ok. Woher weiß ich welches Protokoll
ich implementieren muss? Und wie komme
ich zu so einem Protokoll?

lg*


----------



## Indi.An-er (24 Januar 2010)

Hallo,
jede Kommunikation zu einer SPS-Steuerung unterliegt einem fest definiertem Protokoll, welches die Hersteller nicht so ohne weiteres herausgeben.



Red-Sh4nks schrieb:


> Ich würde das ganze gerne ohne libnodave
> zustande bringen. Also nur mit C#. Ist sowas
> überhaupt möglich?
> 
> lg*



allerdings, wenn du eine externe native C#Komponente benutzen möchtest -also nur verwalteten C#-Code-, kein Problem das ist möglich, schau doch bitte einmal hier http://sps-forum.de/showthread.php?t=31324


----------



## Dr. OPC (26 Januar 2010)

Ein komfortable und auch "wiederverwendbare" Möglichkeit wäre dann noch OPC. 

1) Dazu benötigt man einen OPC Server, der die SPS(en) kapselt und die Daten der SPS auf dem PC bereitstellt. Den gibt es für 600-800 Euro, entweder für PB-DP oder S7 Protokoll. 

2) Den Client kann man in C# schreiben, da gibt es fertige (einfache) Bibliotheken. Die kosten so um die 600 €. Oder man nimmt die .NET-API der OPC Foundation (ist etwas komplizierter).

Der Vorteil: eine funktionierende, industrietaugliche Protokollimplementierung in C# kann man selber wohl nicht für 800€ programmieren (selbst wenn man sich nur den Mindestlohn zahlt, ist das nicht zu schaffen) .  Weiterhin ist es eine Standardschnittstelle (mit Hersteller-Support, also Garantie)  und als Extra kann man Server und Client Komponenten austauschen, falls man mal eine andere SPS verwendet oder den Client mal woanders verwenden möchte.

Der Nachteil: man muss etwas Geld in die Hand nehmen (lohnt sich für die Heizungssteuerung daheim vermutlich nicht). Wenn es aber das Geschäftsmodell ist jedem seiner Kunden das Rad neu zu erfinden und eine individuelle Lösung zu programmieren, kann man mit OPC nicht so viel Geld verdienen. Meiner Erfahung nach sind die Kunden aber auch nicht blöd und bekommen recht schnell heraus dass man ihnen eine selbsgebastelte Lösung für 15.000€ verkauft hat und für 1.500€ hätten sie etwas "von der Stange" bekommen, was auch noch stabiler läuft und nicht bei jeder kleinen Änderung der Hardware kommplett neu programmiert werden muss.
Wie gesagt alles eine Frage des Geschäftsmodells.

Zurück zum Thema: auch OPC kann man mit C# machen, es ist halt nicht "reines" .NET bis zum Treiber runter (Gott sei Dank, werden viele sagen), und schicke Bibliotheken gibt es auch (z.B. ClientACE von Kepware). OPC XML-DA geht auch native .NET und das ganz neue OPC UA geht sowieso native in jeder Sprache.


----------



## StefanK (30 Januar 2010)

*C#*

Hi, 

hab das hier im Netz gefunden, funktioniert gut:
http://s7net.codeplex.com/

Allerdings versteh ich nicht wieso ohne libnodave o.ä. Ich nutze das sehr oft.

Gruß
Stefan


----------



## Red-Sh4nks (1 Februar 2010)

Ok, inzwischen ist mir der ernome Vorteil
von Libnodave bewusst geworden. Ich werde
doch Libnodave verwenden. 

Bin zur Zeit dabei den Beispielcode aus dem
Ordner dot.net/cs/simpleiso_tcp.cs zu verwenden.

Da tun sich aber neue Probleme auf:
1. Wenn ich den Code in ein Projekt kopiere, können die
ersten 3 definition nicht gefunden werden.
  static libnodave.daveOSserialType fds;
  static libnodave.daveInterface di;
  static libnodave.daveConnection dc;

2. Parameter werden gefordert. Wo kann ich die
Parameter mitgeben?

3. Ich arbeite über Profibus. Benötige ich trotzdem
eine IP von der SPS die ich als Parameter mitgeben muss?

lg Marco*


----------



## Red-Sh4nks (3 Februar 2010)

3. hat sich erledigt. Ich benötige keine IP Adresse wenn
ich über Profibus arbeite

Meine MPI Adresse ist MPI2.


----------



## RobiHerb (3 Februar 2010)

*Die anderen Fragen?*

Hat sich das mit Frage 1 und 2 erledigt?

ROB


----------



## whatisnesps (3 Februar 2010)

*600 Euro!*

Hallo alle,

ich frage mich immer wieder, warum sich Leute freiwillig selbst geißeln!??!?!
Wir bei Jetter legen unser Kommunikationsprotokoll nicht nur offen, sondern stellen dem Programmierer eine Bibliothek zur Verfügung, die er einfach in sein Projekt einbindet. Welche Programmiersprache Sie dabei verwenden, bleibt Ihnen überlassen. Damit haben Sie vollen Zugriff nicht nur auf die Steuerung selbst, sondern auch auf alle an sie angeschlossenen Module!! Und das natürlich über Ethernet TCP/IP, wer arbeitet im Jahre 2010 noch mit seriellen Schnittstellen??? 

Einen OPC-Server haben wir zwar auch im Programm, aber wieso sollte ich eine zusätzliche Fehlerquelle in mein Projekt einbauen, wenn ich nicht muss? 

Weitere Fragen zu diesem Thema beantworte ich sehr gern.

Mit freundlichem Gruße


----------



## eYe (3 Februar 2010)

*Werbung*



whatisnesps schrieb:


> Hallo alle,
> 
> ich frage mich immer wieder, warum sich Leute freiwillig selbst geißeln!??!?!
> Wir bei Jetter legen unser Kommunikationsprotokoll nicht nur offen, sondern stellen dem Programmierer eine Bibliothek zur Verfügung, die er einfach in sein Projekt einbindet. Welche Programmiersprache Sie dabei verwenden, bleibt Ihnen überlassen. Damit haben Sie vollen Zugriff nicht nur auf die Steuerung selbst, sondern auch auf alle an sie angeschlossenen Module!! Und das natürlich über Ethernet TCP/IP, wer arbeitet im Jahre 2010 noch mit seriellen Schnittstellen???
> ...




*Nach Werbung & Produktneuheiten verschieb*


----------



## Dr. OPC (3 Februar 2010)

Das wäre natürlich der Idealfall, wenn jeder Herrsteller seine Kommunikationsprotokolle offenlegen würde und auch eine (getestete und gut beschriebene) Programmierschnittstelle kostenlos dazulegt. Leider sind nicht alle so vorbildlich, wie Jetter oder beispielsweise auch Beckhoff mit ihrem ADS-Protokoll.

In der weiterhin idealen Welt muss dann allerdings auch die gesamte Anlage ausschließlich aus SPSen eines Herstellers bestehen, ansonsten müsste man ja alle diese schönen, kostenlosen, offenen, aber leider unterschiedlichen Bibliotheken bedienen, wenn man übergreifend Daten aufsammeln muss.

Ich vermute als Programmierer eines HMI oder SCADA Systems kann dies zu einer Lebensaufgabe werden. Selbst ein kleines Diagnose Tool oder eine BDE muss dann für Jetter einmal und für Beckhoff zum zweiten mal entwickelt werden. 

Und genau deswegen hat jeder Hersteller auch einen OPC Server im Programm denn dann entwickelt man (den Client) nur einmal und die Software und Hardware wird untereinander "austauschbar". Das gefällt natürlich nicht allen Herstellern bzw. Lieferanten und solange eine Anlage "homogen" nur aus Komponenten eines Herstellers gemacht ist, macht OPC erstmal auch erstmal wenig Sinn. Mit "alles aus einer Hand" kann man auch mehr Geld verdienen und der Kunde kann auch nicht "mal schnell" den Hersteller wechseln.

Natürlich ist OPC eine zusätzliche Software-Komponente und somit auch eine potentielle Fehlerquelle aber will jemand wirklich alle seine HMI Software anpassen nur weil beispielsweise Jetter ein neues Modell einer Steuerung auf den Markt bringt oder Beckhoff seine Bibliothek leicht geändert hat oder es ein sonst ein Update gibt?

Ich denke von einer standardisierten Schnittstelle profitieren alle. Die tatsächliche physikalische Schnittstelle oder das Protokoll des Herstellers ist dann völlig irrelevant, Ethernet, Profibus und von mir aus auch RS232, Jetter, ADS oder S7 auch Modbus-TCP denn darum kümmert sich der OPC Server.

Klingt irgendwie "pro OPC" und beantwortet auch die Frage des Themenstarters nicht wirklich. Es gibt verschiedene Lösungsansätze für die beschriebene Aufgabe und OPC ist natürlich nur EINER davon, die Vor- und Nachteile mag jeder selber abwägen.


----------



## RobiHerb (3 Februar 2010)

*C# und SPS Zugriff*

Wie ich schon einmal an anderer Stelle hier im Forum erwähnte, ist OPC in die Jahre gekommen und eigentlich überholt.

Was viele nicht wissen, OPC ist im Kern eine Technologie, die auf Microsoft COM (15 Jahre alt) aufbaut und man sollte sehen, wie der Marktführer (mit dem grossen M) sich die Zukunft vorstellt.

Weitestgehend übersehen wird hier ein neuer Zweig des Windows 7, der sich mit Erfassen, Steuern und Regeln befasst, die Sensor and Localisation API:

http://msdn.microsoft.com/en-us/library/dd318953(VS.85).aspx

Hier ist erstmals in Windows im Betriebsssystem eine ganze Technologie integriert worden, die sich generisch mit Datenaufnahme (IO) befasst!

Diese Technologie wird in vielen Fällen, die Möglichkeiten bieten, die SPS im klassischen Sinne zu ersetzen. Ich denke sie wird so einfach zu handeln sein, wie heute der USB Anschluss, viele werden die Geräte darauf anpassen und dann Ade mit den proprietären Lösungen.

Microsoft hat damit den gesamten Markt über die Steuerung bis zum Navi und dem Internet als Verknüpfungsziel im Blick. Nicht falsch verstehen, das ist in Windows 7 schon drin, also keine Zukunfts Musik!

Vielleicht schaut Ihr auch mal auf Beckhoff, und lernt auch schon einmal C#.


----------



## Red-Sh4nks (4 Februar 2010)

RobiHerb schrieb:


> Hat sich das mit Frage 1 und 2 erledigt?
> 
> ROB



Frage 1 hat sich erledigt.
Ich habe durch Zufall einen Beitrag von jemandem
mit demselben gelesen. Und zwar muss man diese
Klasse einfach suchen und hinzufügen.
(ich hatte befürchtet selbst programmieren)

2 ist im Moment nicht so wichtig.

Nun sind neue Punkte aufgetaucht.
Da ich über MPI und CP5611 arbeite und meine
Adresse MPI2 ist, muss ich mit der Datei
libnodave-0.8.4.5\libnodave-0.8.4.5\Dot.NET\CS\simpleMPI.cs
arbeiten wenn ich das ganze soweit verstanden habe.

Etwas was mich zur Zeit sehr interessiert ist:
Wie finde ich meine Port-Nr heraus?

Ich hab hier mal ein paar Versuche gestartet.
http://www.imagebanana.com/view/n99jh8ow/cmdtests.bmp.png

Leider waren alle Misserfolge, daher hab ich sie
mal hochgeladen. Möglicherweise könnt ihr mir
sagen was ich falsch mache?


----------



## Red-Sh4nks (4 Februar 2010)

*Neuigkeiten*

Ok, die vorherigen Versuche von mir waren
so unbeholfen wie Schweine beim Stabhochspringen ^^

Aber ich habe mich weiter mit Libnodave auseinandergesetzt
und *Tadaaaaaa* ich hab den ersten anscheinenden Connect
hinbekommen:

http://www.imagebanana.com/view/eqtmwun/kurios.bmp.png

dabei sind aber wieder neue Fragen aufgetaucht :-(
Die Nr erklärt:
1: ich versuche die SPS in Stop zu setzen
2: mit der vorgeschlagenen -2 funktioniert es (anscheinend)
3: kombiniert aber wieder nicht...

Frage: Wie kann ich nun die SPS in stop setzen (stop ist nur ein Bsp.)

Hier die Debug Ausgabe:
http://www.imagebanana.com/view/o5lm9u8/libnodavedebug.bmp.png
Anscheinend kann liegt es am Adapter, oder sehe ich das falsch?

Bitte um schnelle Antwort, da ich sehr unter Zeitdruck stehe!

Herzlichen Dank im vorraus.

lg Marco ;-)


----------



## Red-Sh4nks (13 Februar 2010)

*Weitere Informationen*

Ist es auch möglich, dass beim Ausführen von TestMPI
bei einem Befehl: z.B.
Desktop\Libnodave\dot.net\cs\testmpi -d COM1

anstatt COM1 ein anderer Adaptername steht?
wie z.B. Simatic CP 5611 das der Befehl dann so
aussieht:
Desktop\Libnodave\dot.net\cs\testmpi -d Simatic CP 5611

Denn beide (COM1 und COM2) funktionieren nicht, wie ihr
in den obrigen Posts erkennen könnt. Hier ein Screenshot
meines Geräte Managers um eventuelle Missverständnisse zu
vermeiden:
http://www.imagebanana.com/view/d5i3zjo2/Adapter.bmp.png

Achja... Ich hab gegoogelt und mehrere Hinweise darauf gefunden,
dass Libnodave meinen Adapter CP 5611 unterstützt und mit Step 7
ist ein reibungsloser Zugriff auf die SPS möglich.

Bitte um baldige Antwort!

lg Marco


----------



## Jochen Kühner (13 Februar 2010)

*Cp5611*

Ich denke der CP56 wird von LibNodave nur über die Siemens DLLs unterstützt, und nicht direkt als MPI Schnittstelle.


----------



## Red-Sh4nks (15 Februar 2010)

*geschafft!*

ich kann in der Konsole mit tests7online die
SPS in Run und Stop befördern! Das ist schon
mal ein großer Schritt für mich 

Ich werde mit diesem Programm weiterarbeiten,
und den Code einfach in ein eigenes PRogram implementieren.

Danke an alle, ihr habt mir sehr geholfen.


----------



## Red-Sh4nks (4 Juni 2010)

*Auflösung*

Im Nachhinein ist man immer schlauer...

Mein Adapter (CP5611) wird nicht von Libnodave unterstützt. Das ist aber kein großes Problem. 

Lösung:
Habe Step 7 installiert und dannach eine Verbindung über S7-Online aufgebaut. Da Libnodave als tolles Feature auch die Step 7 Verbindung verwenden kann. Damit ist die Verbindung kein Problem mehr.


----------



## Jochen Kühner (4 Juni 2010)

Red-Sh4nks schrieb:


> Im Nachhinein ist man immer schlauer...
> 
> Mein Adapter (CP5611) wird nicht von Libnodave unterstützt. Das ist aber kein großes Problem.
> 
> ...



Wenn du meine erweiterete libnodave verwendest: http://www.sps-forum.de/showthread.php?t=36363 sollte damit über das s7online protokoll sogar routing möglich sein (wär schön wenn du das testen könntest, habs bisher nur per ethernet prüfen können!)


----------



## Red-Sh4nks (4 Juni 2010)

> Wenn du meine erweiterete libnodave verwendest: http://www.sps-forum.de/showthread.php?t=36363 sollte damit über das s7online protokoll sogar routing möglich sein (wär schön wenn du das testen könntest, habs bisher nur per ethernet prüfen können!)



Hab die SPS und den Server bereits zurückgegeben und kann es daher nicht mehr testen, sorry...

lg Marco*


----------

