Siemens API??? wie geht das?

[david.ka]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,
ich habe mal so ein kleines Anliegen.
was ist Siemens API? ich weiß dass es eine Schnittstelle zum Siemens (PCS7 in meinem Falle) System ist, aber wie kann ich mit damit Programmieren?

Visual Studio? direkt im WinCC oder BatchCC?
oder bittet Siemens da seine eigenen Entwicklungsumgebungen?

sind das einfache dll´s die ich in meinem z.B. C# Programm einbinden kann?

was kann ich mir darunter genau vorstellen? wie funktioniert das ganze?

Bin über jede Antwort dankbar.

Grüße
David

 

[Rainer Hönle]

Ist hier die Siemens SAPI gemeint? Da gibts bei Siemens die Handbücher glaub ich sogar zum runterladen. Ist eine Schnittstelle um "einfach" auf S7-Steuerungen bzw. die Variablen zugreifen zu können. Sinnvoll mit C/C++ unter Win32 einsetzbar. Ist ein Variante um Softnet zu verwenden.
Was ist die eigentliche Aufgabenstellung? Vielleicht gibt es einfachere Alternativen.

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

danke erstmal.
will es in C# machen.

ich muss die archivierung automatisieren und die ganzen chargendaten in einer Oracle Datenbank ablegen.

habe schon komplexere sachen gemacht, doch noch nie mit Siemens PCS7 Batch. & API.

laut Siemens kann man über API darauf zugreifen können.
ich muss nur wissen wie ich anfangen soll....

 

[Question_mark]

S7 API oder was ???

Hallo,

ich habe mal so ein kleines Anliegen.

Ich habe Dein Anliegen durchgelesen, aber klein oder trivial ist es auf keinen Fall.

chargendaten in einer Oracle Datenbank ablegen

Wenn es darum geht, eine schnelle und effizitiente Anbindung einer SPS an eine Oracle Database vorzunehmen, ist Delphi die erste Wahl. Das Siemens API ist nicht mehr die erste Wahl einer Datenanbindung einer Applikation an eine SPS.
Für die Realisierung solcher Verbindungen setze ich folgende Komponenten ein :
Delphi 7 oder Delphi 2006 Version Professional
Simatic OPC Server
OPC Client von Kassl Gmbh
Oracle Data Acess Component
Für die Verbindung von Delphi zur Simatic S7 brauche ich je SPS-Variable ca. 1 Minute, die Anbindung von Delphi an Oracle dauert Dank ODAC ca.5 Minuten und ich bin schon zur Designtime auf der Datenbank. Solche Tools machen das Leben wirklich einfach.
Aber zurück zum Thema C# : Die SAPI.DLL stellt eine Schnittstelle zur S7 dar, die man von C, C++ oder Delphi aufrufen kann. Ich glaube nicht, dass man über C# darauf zugreifen kann (wer es besser weiss, darf mich gerne berichtigen). Das Interface ist von Siemens mehr schlecht als recht dokumentiert. Das liegt daran, dass es verschiedene Versionen der DLL gibt, aber nur eine offizielle Dokumentation und Schnittstellenbeschreibung. Und die passen manchmal halt nicht zusammen. Ausserdem ist natürlich dazu immer eine Lizenz von Simatic Softnet erforderlich (Meine persönliche Meinung, vielleicht kann das jemand mal beim grünen Riesen verbindlich nachfragen).
Anbindungen von S7 an Oracle habe ich auf dem o.a. Weg mehrfach realisiert, ich bin teilweise selbst überrascht, dass diese problemlos seit ca. 2 Jahren im Dauerbetrieb laufen(und das unter Windoof XP).
Also kurz zusammengefasst, ich bezweifle, dass die Sapi.dll von Siemens noch weiter unterstützt wird, der von mir angegebene Weg zur Oracle-Anbindung scheint mir z.Zt. die optimale, zukunftsgerichtete Lösung zu sein.

Gruß
Question_mark

PS : Wenn Du noch Fragen zu dem Thema hast, bitte per PN.

 

[afk]

Re: S7 API oder was ???

Für die Realisierung solcher Verbindungen setze ich folgende Komponenten ein :
Delphi 7 oder Delphi 2006 Version Professional
Simatic OPC Server
OPC Client von Kassl Gmbh

Eine kostenfreie Alternative dazu ist libnodave von Zottel (Open Source 8)).
SimaticNET oder ein OPC Client wird dabei nicht benötigt, und eine Delphi-Komponente ist auch dabei.
Außerdem liefert Zottel Beispiele für diverse andere Programmiersprachen mit, unter anderem auch für C#.

Gruß Axel

 

[seeba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann jede C-DLL in C# verwenden. Man benötigt lediglich eine Wrapper-Klasse, welche die Funktionen kapselt.

 

[Rainer Hönle]

Man kann jede C-DLL in C# verwenden. Man benötigt lediglich eine Wrapper-Klasse, welche die Funktionen kapselt.

Und das kann ganz schön aufwändig werden, speziell wenn asynchrone Funktionen im Spiel sind. Da funkt einem die Gültigkeit der Variablen und der GC ganz schön dazwischen. Und Softnet unterstützt bzw. verwendet asynchrone Funktionsaufrufe.

 

[Question_mark]

Oracle und SPS

Hallo,

SimaticNET oder ein OPC Client wird dabei nicht benötigt

Trotzdem bevorzuge ich die OPC Variante gegenüber LibnoDave oder SAPI-DLL. OPC hat gegenüber allen anderen Varianten durch den OnChange-Event für mich den Vorteil, dass meine Applikation nur bei Änderung von Daten in der SPS oder bei Benutzeraktionen etwas tun muss. Das umherschaufeln der Daten wird im Hintergrund von den OPC-Komponenten erledigt (ja, ich bin manchmal etwas faul).
Leider gibt es die Oracle ODAC Komponenten von CoreLab nicht für C#, die sind wirklich allererste Sahne. Auf dem Client-PC wird nicht einmal ein Oracle-Client benötigt, ODAC kann die Verbindung zum Oracle-Server direkt über das Netzwerk aufbauen. In den Query-Komponenten kann man direkt die SQL-Anweisungen schreiben. Die Beschreibung findest Du hier :
http://www.crlab.com/
Vielleicht findest Du etwas ähnliches für C#.

Gruß
Question_mark

 

[afk]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: Oracle und SPS

SimaticNET oder ein OPC Client wird dabei nicht benötigt

Trotzdem bevorzuge ich die OPC Variante gegenüber LibnoDave oder SAPI-DLL. OPC hat gegenüber allen anderen Varianten durch den OnChange-Event für mich den Vorteil, dass meine Applikation nur bei Änderung von Daten in der SPS oder bei Benutzeraktionen etwas tun muss. Das umherschaufeln der Daten wird im Hintergrund von den OPC-Komponenten erledigt (ja, ich bin manchmal etwas faul).

Jeder gute Softwareentwickler sollte (in Grenzen) faul sein, das steigert die Kreativität erheblich ! :lol:

Ich bevorzuge in meinen Programmen auch OPC, darum habe ich mir in Delphi eine OPC-Client-Komponente und auf Basis von libnodave einen eigenen OPC-Server geschrieben. :wink:

Wenn ich aber vor der Wahl stehen würde, für diesen Anwendungsfall (Programm, das Daten aus der SPS in eine Datenbank schaufelt) entweder das SimaticNET-Paket zu installieren (und eine Lizenz dafür zu kaufen), oder in meinem Progrämmchen die Daten halt zyklisch zu pollen, dann würde ich mich in dem Fall wohl für letzteres entscheiden.
Erstens ist das bei so einer Anwendung meistens auch nicht viel aufwendiger, da oft ein einziges Signal der Trigger für das Lesen der anderen Daten ist, und daher nur dieses Signal zyklisch gepollt werden muß. Und wenn das Programm öfter eingesetzt wird, dann lohnt es sich schon allein wegen der für den OPC-Server anfallenden Lizenzkosten.

Gruß Axel

 

[Zottel]

Soweit ich weiß pollen auch alle OPC-Server die Daten der SPS.

 

[afk]

Soweit ich weiß pollen auch alle OPC-Server die Daten der SPS.

Das ist völlig richtig, ein OPC-Server kann ja schließlich auch nicht durch "hellsehen" wissen, was sich in der SPS getan hat. :lol:

Er macht halt "nur" das Programmieren der Anwendung bequemer, auch weil OPC momentan wohl die einzige einheitliche Schnittstelle zum Zugriff auf Daten in unterschiedlichen Steuerungen aus verschiedenen Programmen und Programmiersprachen heraus ist.

Die Belastung auf der Seite der Kommunikation zur SPS ist dabei teilweise sogar deutlich höher als beim direkten Polling in der Anwendung, weil der OPC-Server normalerweise versucht, in jedem Poll-Zyklus alle Daten zu holen. Im oben von mir genannten Beispiel würde es jedoch reichen, nur das Triggersignal ständig zu pollen und die anderen Daten nur dann zu holen, wenn's laut Trigger notwendig ist. Und das belastet die SPS und den Bus dann eben deutlich weniger. :wink:

Gruß Axel

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit ich weiß pollen auch alle OPC-Server die Daten der SPS.

Ohne SPS-Programmänderung stimmt das. Ob es OPC-Server mit Send-/Receive-Unterstützung (o.ä.) gibt, weiss ich nicht. Nachteil wäre hierbei auch die notwendige Projektierung und Programmierung in der SPS.

Er macht halt "nur" das Programmieren der Anwendung bequemer, auch weil OPC momentan wohl die einzige einheitliche Schnittstelle zum Zugriff auf Daten in unterschiedlichen Steuerungen aus verschiedenen Programmen und Programmiersprachen heraus ist.

Deshalb sollten die Anfragen sinnvoll gruppiert und jeweils mit notwendigen und nicht mit dem minimal möglichen Abfrageintervall versehen werden.

Die Belastung auf der Seite der Kommunikation zur SPS ist dabei teilweise sogar deutlich höher als beim direkten Polling in der Anwendung, weil der OPC-Server normalerweise versucht, in jedem Poll-Zyklus alle Daten zu holen. Im oben von mir genannten Beispiel würde es jedoch reichen, nur das Triggersignal ständig zu pollen und die anderen Daten nur dann zu holen, wenn's laut Trigger notwendig ist. Und das belastet die SPS und den Bus dann eben deutlich weniger.

Ich bin mir da nicht sicher, ob sich das gravierend auf die Zyklusbelastung auswirkt. Wenn ich von einigermaßen intelligenten CPs ausgehe, sollten diese den gesamten Protokollverkehr selbständig abhandeln. Die Datenübergabe an den CP darf dann auch nicht länger dauern als ein SFC20-Aufruf. Und wenn ich dann auch noch den realisierbaren Nutzdatendurchsatz einer WinAC die alles selber macht mit ca. 1 MByte/s gegenüber einer 416-2DP mit 443-1 und ca. 50-60 KByte/s ansehe, sind wir da noch lange nicht am Anschlag.
Ein großer Vorteil der OPC-Server ist, dass bei der Entwicklung (wahrscheinlich) mehr Aufwand in die Optimierung der Anfragen zur Minimierung der Request-/Response-Pakete gesteckt wurde, als es bei einer normalen direkt programmierten Lösung der sein wird. Dadurch kann der Datendurchsatz höher ausfallen, speziell bei verteilten Anfragen.

 

[Question_mark]

S7SAPI, wie jeht dat denn ?

Hallo,

Ob es OPC-Server mit Send-/Receive-Unterstützung (o.ä.) gibt, weiss ich nicht, weiss ich nicht.

Ähemm, aber Herr Hönle.....
Der Simatic OPC-Server hat die sogenannten Blockdienste (bei einer S7-Verbindung). Damit kann man aus der S7 z.B. mit dem SFB 12 "BSEND" bis zu 64k große Blöcke an den OPC-Server senden. Umgekehrt funktioniert das auch vom PC zur S7, in der S7 kann der SFB 13 "BRECV" entsprechend Datenblöcke vom OPC-Server empfangen.
Der Simatic OPC-Server verarbeitet ausserdem "SCAN"-Meldungen aus der S7. Bei den "SCAN"-Meldungen überprüft die S7-400 CPU Variablen (die zuvor entsprechend in der Symboltabelle projektiert sein müssen) selbsttätig auf Änderungen und schickt bei Änderungen einen Event mit den geänderten Daten an den OPC-Server. "SCAN" also deshalb, weil die S7-CPU selber die projektierten Variablen auf Änderungen scannt.
Dann kann der Simatic OPC-Server noch "ALARM"-Meldungen verarbeiten. Dies sind Meldungen, die der Anwender im STEP7-Programm durch Aufruf und entsprechende Parametrierung z.B von SFB35 "ALARM_8P" anstossen kann.
Nachteil ist, dass man die Block-, Scan- und Alarmdienste in der S7 programmieren muss. Auch eine Verbindungsprojektierung ist dazu erforderlich. Ausserdem benötigen diese Dienste eine andere Verbindungsressource (0x10 bis 0xDF) als die Variablendienste (0x02).
Bei "BSEND", "SCAN" und "ALARM" wird also die Kommunikation von der CPU gesteuert, und nicht vom OPC-Server.
Jetzt noch ein kleines aber : ich weiss nicht, ob das auch in der S7-300 CPU funktioniert ? In einer 400-er CPU sind aber die o.a. Dienste funktionsfähig und auch schon von mir eingesetzt. Diese Dienste sind übrigens natürlich auch schon in der S7Sapi.Dll vorhanden.

Gruß
Question_mark

 

[Question_mark]

Hallo,

Deshalb sollten die Anfragen sinnvoll gruppiert und jeweils mit notwendigen und nicht mit dem minimal möglichen Abfrageintervall versehen werden

Genau meine Meinung. Darum sieht ja der OPC-Standard auch die Deaktivierung/Aktivierung von Gruppen oder Items vor. Sinnvoll wäre z.B. bei einer Visualisierung je Seite (oder Formular) alle Items dieser Seite in einer OPC-Gruppe zusammenzufassen und die Gruppe nur zu aktivieren, wenn die Seite auch sichtbar ist. Mit dem Aktivieren der Gruppe werden die Werte automatisch aktualisiert und ein Event vom OPC-Server ausgelöst, so dass direkt aktualisierte Daten zur Verfügung stehen.

Gruß
Question-mark

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: S7SAPI, wie jeht dat denn ?

Ähemm, aber Herr Hönle.....

Man lernt nie aus. Und ich bin gerade noch in einem Alter wo man dazulernen kann :wink:

BSEND und BRECEIVE sind mir schon bekannt. Nur ist mir der praktische Nutzen in Verbindung mit einem OPC-Server nicht ganz klar. Dort will ich doch den Wert diverser Variablen wissen. Wie der Name sagt, kann ich mit den B-Funktionen Datenblöcke an einen Gegenstelle schicken. Eine Information über den Inhalt der Daten muss aber hier in das Telegramm kodiert werden, da keine spezielle Anfrage erfolgte. Was hat da der Siemens OPC-Server als Standard definiert bzw. wie werte ich den Inhalt aus?

Bei den SCAN-Meldung weiss ich nur, dass eine Änderung der Variablen über Stop gehen muss. Ist dies richtig? Eine Änderung an einer laufenden Anlage wäre somit schwierig. Die Anzahl der Scan-Varaiablen ist auch sehr begrenzt. Und je mehr vorhanden sind, desto größer ist der Abfragezyklus.

Und zum Schluss: was kann ich alles mit den Alarmdiensten anstellen und wo finde ich weitere Infos?

 

[Question_mark]

Hallo,

Eine Information über den Inhalt der Daten muss aber hier in das Telegramm kodiert werden,

Die Identifikation erfolgt über die bei der Projektierung von BSEND b.z.w BRECV angegebene R_ID. Diese muss dann Bestandteil des OPC Itemnamens sein. Ein gültiger Itemname wäre z.B. "BRCV,8,B2,4". Das heisst also 4 Bytes ab Byte 2 im Empfangspuffer mit der R_ID = 8. Durch die R_ID ist die Zuordnung der Daten eindeutig gesichert.

wie werte ich den Inhalt aus?

In der Syntax für die Variablennamen von blockorientierten Diensten kann optional ein Datentyp angegeben werden :
BRCV,<RID>{,<Typ><Adresse>{,Anzahl>}} b.z.w
BSEND,<Länge>,<RID>{,<Typ><Adresse>{,Anzahl}}
Die Datenstruktur des Blockes sollte natürlich bekannt sei. Der Vorteil liegt eben daran, dass hier die Kommunikation von der SPS gesteuert werden kann (naja, zumindest das Senden) und die Blockgröße von 64k.

eine Änderung der Variablen über Stop gehen muss. Ist dies richtig?

Ja, das ist richtig. Wenn man Items ändert, muss das Projekt neu auf die CPU geladen werden, dabei wird die Symboltabelle neu eingelesen und die Projektierung der alarmfähigen Items neu geladen (sonst hat die CPU eben nicht die benötigten Informationen), ich vermute diese in einem Systembaustein.

was kann ich alles mit den Alarmdiensten anstellen

Siehe PCS7. So kommen die Meldungen durch den OS-Transfer in das WinCC-Projekt und werden dort in das Meldesystem übernommen.

und wo finde ich weitere Infos?

Das ist nur sehr spärlich bis garnicht dokumentiert. Als erster Ansatz vielleicht in der STEP7 Hilfe für
"ALARM" ---> "Bausteinbezogene Meldungen" b.z.w
"SCAN" ---> "Symbolbezogene Meldungen"
nachschlagen. Einige Infos stehen auch im Siemens Handbuch "Einführung OPC-Server für SIMATIC NET" im Kapitel 5.3.

Gruß
Question_mark

 

[Rainer Hönle]

Danke für die schnelle Antwort

 

[afk]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deshalb sollten die Anfragen sinnvoll gruppiert und jeweils mit notwendigen und nicht mit dem minimal möglichen Abfrageintervall versehen werden

Genau meine Meinung. Darum sieht ja der OPC-Standard auch die Deaktivierung/Aktivierung von Gruppen oder Items vor. Sinnvoll wäre z.B. bei einer Visualisierung je Seite (oder Formular) alle Items dieser Seite in einer OPC-Gruppe zusammenzufassen und die Gruppe nur zu aktivieren, wenn die Seite auch sichtbar ist. Mit dem Aktivieren der Gruppe werden die Werte automatisch aktualisiert und ein Event vom OPC-Server ausgelöst, so dass direkt aktualisierte Daten zur Verfügung stehen.

In der Theorie hört sich das zwar ganz gut an, aber welche Visualisierung macht das schon ?

Üblicherweise beschränken sich (PC-basierte) Visualisierungen ja nicht nur auf das pure Anzeigen von Daten, sondern bieten Funktionen zum Verarbeiten der Daten im Hintergrund (Datalogging, Alarmprotokoll, usw.). Da wäre das Deaktivieren von Gruppen, die gerade nicht angezeigt werden, ziemlich kontraproduktiv.

Und was das Abfrageintervall angeht, da lassen sich in vielen Fällen leider keine klaren Grenzen ziehen. Wenn ich Analogwerte habe, die sich normalerweise nur sehr träge ändern, dann komme vielleicht mit einer langsamen Aktualisierung dieser Werte klar, wenn ich eben nur diese Werte betrachte. Wenn mir die SPS zu diesen Werten dann aber auch noch Alarme generiert, dann ist es schon ziemlich schlecht, wenn der Bediener einen Alarm gemeldet bekommt, ihm aber gleichzeitig ein Wert angezeigt wird, der sich noch im grünen Bereich befindet.
Ich weiß da schon ziemlich sicher, wessen Telefon dann als nächstes klingelt ... :?

Abgesehen davon beeinflußt das Aktualisierungsintervall in den OPC-Gruppen laut meinen Erfahrungen mit dem SimaticNET OPC-Server dessen Poll-Zyklus überhaupt nicht, der wird nämlich in der Projektierung des OPC-Servers fest eingestellt.

Trotz all der Haken und Ösen ist OPC für viele Anwendungen mit Sicherheit das richtige Mittel zum Zweck, aber eben auch nicht für alle.

Kommt halt immer auf den Einzelfall an. :wink:

Gruß Axel

 

[Rainer Hönle]

Abgesehen davon beeinflußt das Aktualisierungsintervall in den OPC-Gruppen laut meinen Erfahrungen mit dem SimaticNET OPC-Server dessen Poll-Zyklus überhaupt nicht, der wird nämlich in der Projektierung des OPC-Servers fest eingestellt.

OK, ich ging von unserem OPC-Server aus. Und der versucht zumindestens den Wunsch zu erfüllen. :wink:

 

[david.ka]

Hallo Leute,
danke für die vielen Antworten. doch leider trifft das nicht ganz zu. ich will nicht auf die SPS zugreifen, sondern ins PCS7 Batch System. brauche die Chargendaten. diese sind im BatchSystem und nicht in der SPS.
ist da das SAPI dafür geeignet?


grüße
david