Mit C# auf SPS zugreifen

Red-Sh4nks

Level-1
Beiträge
42
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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*
 
Einfach eine Bibliothek wie libnodave, ACCON-AGLink oder ähnliches benutzen.
RS232 geht nicht. Es wird ein entsprechender Adapter benötigt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
jede Kommunikation zu einer SPS-Steuerung unterliegt einem fest definiertem Protokoll, welches die Hersteller nicht so ohne weiteres herausgeben.

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
 
Zuletzt bearbeitet:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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*
 
3. hat sich erledigt. Ich benötige keine IP Adresse wenn
ich über Profibus arbeite

Meine MPI Adresse ist MPI2.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Werbung

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


*Nach Werbung & Produktneuheiten verschieb*
 
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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#.
 
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?
 
Zuletzt bearbeitet:
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 ;-)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :)
 
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.
 
Zurück
Oben