Ist OPC das Richtige für uns?

Grün

Level-1
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo allerseits!

Ich bin Softwareentwickler und habe gerade angefangen, mich mit OPC auseinanderzusetzen.

Bevor wir uns nun, bei einem aktuellen Projekt, für den Einsatz von OPC entscheiden, möchte ich hier ein paar Fachleute fragen, ob das in unserem Fall sinnvoll ist.

Wir haben eine von einer SPS gesteuerte Maschine, die für das Handling von Werkstücken zuständig ist und einen PC mit Sensoren, der Messaufgaben übernimmt.
Wenn die Maschine ein Werkstück an eine bestimmte Position gefahren hat, soll sie dem PC ein Signal senden, damit dieser die Messung startet.
Wenn die Messung abgeschlossen wurde, soll der PC die Messwerte wieder der SPS zur Verfügung stellen. Eine Messung dauert ungefähr 100 ms.

Meine Aufgabe wäre es, die OPC-Funktionalität in die Anwendung auf dem Mess-PC zu integrieren.

Nach meinem bisherigen Verständnis würde man OPC A/E nutzen um die Messung auszulösen und OPC DA um die Messwerte zu übertragen. Ist das korrekt?
Ich möchte nur sicherstellen, dass wir hier nicht mit Kanonen auf Spatzen schießen und dass auch das Auslösesignal nicht unnötig verzögert wird.

Mit freundlichen Grüßen
Michael
 
Hallo,

OPC ist ein verbreiteter universeller Standard, aber die
Umsetzung mit einem gewissen Aufwand verbunden.

Wenn für die SPS einen OPC-Server vorhanden ist,
müsstest Du in Deine Mess-Software einen OPC-Client
integrieren.

Damit wärst Du flexibel und könntest Deinen Mess-PC
an beliebige andere OPC-Server anbinden.

Wenn diese Flexibilität nicht gefordert ist, wäre eine
direkt Anbindung über das Protokoll der SPS vielleicht
der einfachere Weg.

Vor längerer Zeit habe ich dazu mal was geschrieben:

http://www.sps-forum.de/hochsprachen-opc/34028-opc-vs-s7-kommunikationstreiber.html#post246289

Die nächsten Fragen wären jetzt - um welche SPS geht
es und muss es voll universell sein?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo und vielen Dank!

Es handelt sich, wie in dem Link, um eine Simatic S7 und eine möglichst universelle Schnittstelle wäre sehr interessant für uns.
Wichtig wäre halt noch, dass das Auslösesignal möglichst zeitnah von der Mess-Software registriert werden kann.
Hast du da Erfahrungswerte?

Mit freundlichen Grüßen
Michael
 
Ich würde eine TCP/IP (bzw. ISO on TCP) Verbindung aufbauen und ein Telegramm hin und her schicken. Das ist schon recht universtell und mit einem Lebensbit und Timeout auch gut zu überwachen. Man muss hier halt in beiden Systemen Anpassungen vornehmen und kann nicht einfach in den DB von der SPS schauen.

Dafür ist es recht universell.
 
Ich habe jetzt den Simulationsserver von Matrikon installiert und das folgende OPC DA Toolkit verwendet um eine Client-Anwendung zu schreiben.
http://sourceforge.net/projects/opcclient/
Ein gratis Toolkit für OPC AE habe ich leider nicht finden können.
Soweit funktioniert zwar alles, aber das Auslösesignal braucht ca. 20 ms - 80 ms vom Sender zum Empfänger, selbst wenn ich die Update Rate und die Time Granularity in den Servereinstellungen auf den kleinstmöglichen Wert setze.
Das ist natürlich nicht akzeptabel. Daher werde ich dem Programmierer der SPS wohl vorschlagen müssen, doch eine direkte TCP/IP-Verbindung aufzubauen und OPC nicht zu verwenden.
 
Also wenn ich das Richtig verstehe benötigst du Zeitgenau Messungen.
Jetzt stellt sich für mich die Frage:
1. Benötigst du die Messwerte exakt zugeordnet zu einem Zeitpunkt um dann eine Auswertung zu machen? Oder
2. Benötigst du "Realtime" Auswertung um sofort mit der Messsoftware auf Ereignisse zu reagieren. Z.b. Prozesse in Realtime optimieren.

Da aber der Begriff Messoftware gefallen ist denke ich das Du 1. meinst.
Dazu würde ich dann vorschlagen nutze Zeitstempel. Dabei wäre dann eigentlich egal ob Du OPC nutz oder "normale" TCP Telegramme.
Dabei werden dann die Werte im Messprotokoll zur Zeit des Zeitstempels korrekt ein sortiert. Die meisten Leitsystem arbeiten mit dieser Methode um genau die Probleme mit dem Zeitversatz zu umgehen.

Sollte es doch 2. sein kann ich nur sagen entweder eine SoftSPS, dann läuft alles auf dem selben Rechner, oder die Auswertung auf der SPS machen.
Allerdings machen 80ms wirklich so viel aus?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@schaible.r: das gleiche wollte ich ihm auch erst schreiben. Aber er schickt keinen Meßwert von der SPS zum PC. Die Sensoren sind am PC angeschlossen, er schickt nur das Kommando zum messen und bekommt den Meßwert zurück.
 
Nach meinem bisherigen Verständnis würde man OPC A/E nutzen um die Messung auszulösen und OPC DA um die Messwerte zu übertragen. Ist das korrekt?
Ich möchte nur sicherstellen, dass wir hier nicht mit Kanonen auf Spatzen schießen und dass auch das Auslösesignal nicht unnötig verzögert wird.
Warum muss ein Messung "ausgelöst" werden ?
Weil es ist ein Teil das in ein bestimmte Messvorgang bearbeitet werden muss, und der "Kurvenform" von die gemessene Werte ist von Bedeutung ?
In den Fall sollte den gesammte Messvorgang von der Steuerung gesteuert werden, und die Messwerte von den Steuerung abgefangen und gespeichert.
Die Messdaten können entweder alle ein eigene Zeitstempel haben, oder wenn das Messinterval konstant ist können die Messdaten in ein Array gespeichert werden, ohne individuelle Zeitstempel.
 
Die Sensoren sind am PC angeschlossen,
Ah ! Das ist ja ein ganz andere Geschichte. (edit: Was in den 1. Eintrag klar und deutlich zu lesen war).
Und wie sind die Sensoren an den PC angeschlossen ?

, er schickt nur das Kommando zum messen und bekommt den Meßwert zurück.
Es wird nur 1 Messwert pro Sensor aufgenommen und übertragen ?

Ich verstehe nicht warum die Sensoren nicht direkt am Steuerung angeschlossen sind. Warum muss ein PC dazwisschen ?

edit: Wie Zeitgenau müssen die Messungen aufgenommen werden ?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
es geht doch aus dem 1. Post von Ihm eindeutig hervor das eine spezielle Mess-Software eingesetzt wird (also sicherlich auch speziellere Mess-Hardware) z.B. Konturmessung per Laser oder sowas
nicht einfach nur kontinuierliche Messwert-Erfassung bei Durchlauf...


@Grün - sag doch mal genau was deine Mess-Software macht und warum das nicht in der SPS ist - damit diese Diskussionen beendet werden


ansonsten ist AGLink von Deltalogic nach meiner Erfahrung das schnellste um ohne SPS-Programmänderung zu kommunizieren - wenn
es aber wirklich nur ein paar Werte + Los-Gehts-Überwachung ist könnte auch ein wenig TCP/IP-Code auf PC und SPS reichen
um das zu realisieren
 
Hey, jetzt geht's hier ja rund. Vielen Dank, dass sich so viele Leute mit meinem Problem beschäftigen.
Ich versuche den Prozess mal besser zu beschreiben.
Vereinfachungen mache ich nur, wo sie für den Prozess nicht relevant sind.
Die Sensoren, von denen ich schrieb, sind mit dem PC verbunden auf dem die Messsoftware läuft.
Das von mir gewählte Wort "Messsoftware" ist vielleicht etwas irreführend.
Die Software stellt aufwändige Berechnungen an. Die Sensoren lassen sich nicht direkt mit der SPS verbinden.

Die Maschine soll Bauteile analysieren. Je mehr Bauteile sie pro Stunde analysieren kann, um so besser.
Die Geschwindigkeit bewegt sich in der Größenordnung ein Bauteil pro Sekunde.
Der Prozess läuft, leicht vereinfacht, so ab:
- Die Maschine nimmt ein Teil und fährt es vor die Sensoren.
- Die Maschine teilt meiner Software mit, dass diese mit der Untersuchung des Bauteils beginnen kann.
- Die Software liest die Sensoren aus.
- Die Software teilt der Maschine mit, dass diese das nächste Werkstück vor die Sensoren fahren kann.
- Sobald die Berechnungen abgeschlossen sind, wird das Ergebnis der Maschine mitgeteilt, die basierend darauf eine Sortierung vornimmt.

Maschine und Software müssen also jeweils aufeinander warten.
Eine Verzögerung der Signale wirkt sich direkt auf den Durchsatz aus.
Das Platzieren der Bauteile vor den Sensoren wird auch nicht immer gleich lange dauern.
Wenn SPS und Messsoftware jetzt jeweils mindestens 100 ms vorher abschätzen müssen, wann sie mit ihrer jeweiligen Aufgabe fertig sind um dies rechtzeitig vorher mit Zeitstempel mitzuteilen, wird das Ganze sehr kompliziert.
Für mich sieht das jetzt danach aus, dass OPC nicht die Methode der Wahl ist.
 
Also wenn ich das richtig verstehe brauchst du einen "Trigger" aus der SPS um die Messung auf dem PC auszulösen, den errechneten Messwert schreibst du dann vom PC zurück in die SPS.

1) über OPC DA (mit DataChange-Mechanismus) hast du hier zusäztliche Latenzen drin (die Scan- und die Updaterate) denn der OPC Server "pollt" die SPS. Diese Pollzyklus ist "endlich" und üblicherweise nur bis 50ms oder 100ms einstellbar.

2) du könntest natürlich auch selber (als OPC Client) zyklisch lesen, das geht dann vermutlich schneller, bedeutet aber mehr Kommunikationslast für die SPS.

3) wenn es "deterministischer" sein soll, könntest du den Trigger "fest verdrahten" (also an der SPS einen Ausgang setzen und dieses "elektrische" Signal in einen deiner Sensoreingänge des PC verdrahten und als Trigger nutzen). Dann bekommst du den Trigger in "Echtzeit".

4) deinen berechneten Messwert kannst du dann über OPC wieder in die Steuerung schreiben, das geht direkt durch, ohne Latenz.

Alternativ kannst du dir auch ein eigenes TCP-Protokoll ausdenken und mit Handschake und ping/pong die Daten hin und herschieben. Ob du dann am Ende "deterministischer" bist (als mit 2. und 4.), bleibt zweifelhaft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Klar ist, daß Du dich ja schon entschieden hast das OPC nichts für dich ist.
Allerdings bin ich mir sehr sicher das Du mit jeder Methode gewisse Verzögerungen haben wirst.
Zusätzlich kommt hinzu das Du bei TCP Kommunikation entweder ein eigens Protokoll und einen Interpreter benötigst.
Dies wird dann höchst wahrscheinlich nicht viel Zeit sparen.
Aber das gilt es zu testen.

Jedenfalls wäre es echt cool wenn Du Deine Lösung zum Schluss beschreiben würdest. Würde mich dann echt interessieren auf welche Zeitdifferenz Du dann kommst.
 
Zusätzlich kommt hinzu das Du bei TCP Kommunikation entweder ein eigens Protokoll und einen Interpreter benötigst.
Dies wird dann höchst wahrscheinlich nicht viel Zeit sparen.

Naja, lassen wir mal Butter bei die Fische, eine Variable in einen Socket stopfen ist jetzt keine Raketenwissenschaft.

Mir fällt nur auf dass wir automatisch von einer Simatic ausgegangen sind. Bei einer anderen SPS gibt es auch noch andere Möglichkeiten was auszutauschen. ADS z.B. bei Beckhoff ist sehr performant.
 
Stimmt. Dies ist natürlich ein Punkt den man schon zu Anfang hätte klären sollen. Je nach SPS kämen dann evtl ganz neue Ergebnisse bei den Überlegungen raus.
 
Zurück
Oben