Daten über TSend_C an OPC-Server senden

[Lord Cartman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey zusammen,
ich stehe vor einem kleinen Problem.
Zunächst mal die Komponenten:
Verbaut ist die CPU 1211C. Die Programmierung erfolgt über das TIA Portal V10.5.
Die AUfgabe besteht darin die Daten eines Datenbausteins an einen OPC Server zu senden. Defaultmäßig ruft der OPC-Server die Daten ja über Polling ab. Da das bei größerer Teilnehmerzahl aber eine zu hohe Netzlast verursacht, wollte ich das Pollen durch ein erreignissgesteuertes Senden ersetzen.
Meine Frage wäre eig nur: woran erkenne ich das die neue Variante mit dem gesteuerten Senden geklappt hat? Die variablen im db werden durch einen scanner aktualisiert und simultan auch im opc server.
Kann man irgendwo nachschauen oder einstellen nach welchem verfahren der server die daten annimmt

Danke schonmal für die Hilfe

LG
Cartman

 

[BPlagens]

Steh auf der Leitung

Hallo!

Also entweder ist da die Entwicklung an mir vorbei gegangen oder ich blicke es einfach nicht!

Du willst Daten an einen OPC-Server schicken?
Mal ganz blöd wie sieht denn das in der Praxis aus? Dann müsste man ja eine art virtuellen DB im PC erstellen aus dem sich dann der OPC-Server bedient.

Also solch eine Funktion habe ich noch bei keinem OPC-Server gesehen.

Ich kenne Varianten bei denen der OPC-Server nur 1Bit pollt und daran erkennt das sich was getan hat - dann holt er den Rest - aber das ist bestimmt kein Standard.

Falls ich da was nicht blicke: War eine kurze Nacht!

 

[Lord Cartman]

Zuviel Werbung?
-> Hier kostenlos registrieren

die nacht war kurz, der tag wird dafür umso länger

vlt reden wir wirklich aneinander vorbei. also die sps bekommt die daten über einen barcodescanner und speichert diese in einem db ab.
***Ich kenne Varianten bei denen der OPC-Server nur 1Bit pollt und daran erkennt das sich was getan hat - dann holt er den Rest***
diese variante läuft ja auch bereits erfolgreich, sprich der opc server holt sich regelmäßig immer die daten aus dem datenbaustein.
für das weitere projek will ichs aber so machen, dass die sps, sobald sie neue daten hat, diese an den opc-server sendet. dafür gibts ja den baustein tsend_c. die frage die sich mir jetz stellt ist, wie man dieses pollen des opc's beenden kann, da er die daten ja zugeschickt bekommt.
bzw was man noch machen muss, damit er diese daten empfangen kann?

 

[BPlagens]

Meiner Meinung nach geht das nicht!

Du musst ja im OPC-Server deine Tag`s anlegen - und diese liegen ja in der SPS.

Du bräuchtest ja eine Funktion im OPC-Server in der du einen Empfangspuffer erstellst und dann sagst welcher Tag wo im Puffer zu finden ist.

Ich bin der Meinung das es das so nicht gibt (von spezial Lösungen mal abgesehen).

Der OPC-Server müsste ja quasi die Funktion TRECV_C beinhalten. Selbst wenn er das hätte würde dies ja nichts über die Struktur der Daten aussagen.

Was ich mir vorstellen könnte:
Auf dem PC läuft zusätzlich eine SoftSPS auf der TRECV_C läuft und die Daten der einzelnen SPSen sammelt. Der OPC-Server greift dann auf die SoftSPS zu.

Also wie gesagt, ich kenne keinen OPC-Server der Daten empfangen kann. Der OPC-Server ist immer der "aktive Datenabholer" und stellt diese Daten den OPC-Clients zur Verfügung.

Was setzt zu denn als OPC-Client ein? Der OPC-Server holt ja nur die Daten die man ihm sagt. Evlt. kannst du ja deinen Client so einrichten das er nur auf das Bit "neue Daten da!" achtet (also der OPC-Server nur dieses Bit pollt) und bei einem Ereignis dann die benötigten Daten einmalig holt.

dafür gibts ja den baustein tsend_c

Na ja nicht wirklich - dieser Baustein dient ja primär dazu, Daten zwischen SPSen auszutauschen. Klar kann man auch Daten an einen PC schicken. Aber eben nicht an eine OPC-Server.

 

[Lord Cartman]

hmm...
genau die funktion mit der sich der empfangspuffer erstellen ließe is ja die gesuchte nadel im heuhaufen
Ich hab jetz im OPC Scout, bzw im OPC Navigator unter S7_connection -> blocks die funktion "brcv" gefunden. dort lassen sich neue items ähnlich anlegen wie bei einem neuen Item unter "objects". Das auslesen einer variable hat auch schon geklappt, obwohl ich nur die adresse der variable angegeben hatte die in dem DB existiert, aber nich gesagt hatte das die variable überhaupt in dem db steht. trotzdem hat sich der angezeigte wert nach einem test-scannen vom scanner aktualisiert.
war das jetz vlt die gesuchte funktion?

blicke da mom irgendwie nich durch, da man ja auch keinen direkten unterschied erkennt^^

An die softsps hatte ich auch schon gedacht, die wäre dann die notlösung wenn das hier nich klappt.

Einen Client setz ich derzeit nicht ein. die Daten sollen wie gesagt von der sps auf den server gelangen. von dort werden sie mit einem opc router weitergesendet an eine sql datenbank. zzt arbeit ich mit dem opc-scout, der ja die eigenschaften eines clients hat.

 

[BPlagens]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sorry, da hört es dann bei mir auf! :-(

Aber welchen OPC Router nimmst du denn?
Der von Inray kann doch auf Ereignisse reagieren (wie "mein" Bit) und dann bestimmte Tags in die SQL-DB einfügen.

Man kann doch auch ein VBA-Script antriggern (ging zumindest bei der Testversion von Inat damals).

Dann hättest du doch was du willst.

Viel Erfolg!

 

[Lord Cartman]

schade, aber willkommen im klub
der router is von inray, hab mich aber noch nich so intensiv mit dem befasst.
wenn der router auf ereignisse reagieren kann ist das ja gut, aber bekommt der die daten nicht von dem server, und der hat dieses erreignissproblem? *der zusammenhang server-router is wie gesagt noch neuland

Dank dir trotzdem für deine Hilfe

 

[BPlagens]

Also eigentlich ist es ja so:

- Inray meldet den zu beobachtenden Tag (das Bit) beim OPC Server an
(Ich würde das so machen, das der OPC-Server bei Änderung ein Ereignis auslöst)
- Der OPC-Server pollt nun ständig das Bit
- Wenn sich jetzt das Bit ändert bekommt dies Inray mit und führt die gewünschte Aktion aus (sprich die anderen Tags-holen und in der SQL-DB eintragen)

Wie gut sind denn deine Programmierfähigkeiten? Da du ja den Siemens OPC-Server nimmst gibt es ja im Programm-Ordner einige sehr gute Beispiele.
Ich habe nie eingesehen soviel Geld für Inray auszugeben das ganze lässt sich mit 20 Zeilen Code erledigen.

 

[Lord Cartman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine idee is gut, aber du versuchst ja den zugriff von router auf server erreigniss gesteuert zu regeln. mir gehts ja vorerst "nur" darum das abbild im Server mit den Daten ausm dem DB der SPS zu aktualisieren und das eben ohne pollen.

meine fähigkeiten sind noch nicht so berauschend, von daher is der konventionelle weg wohl der leichtere

am besten wäre, sps und die sql datenbank bekommen icq, dann solln die sich schreiben wenn was is

 

[Lord Cartman]

Hab mitlerweile rausgefunden das man zuerst ma eine TCP Verbindung einrichten muss, klingt ja auch logisch. anschließend lässt sich im opc scout unter der tcp verbindung ein receive baustein aufrufen, der das datenpaket dann von der sps empfängt.

*ein kleiner schritt für einen menschen, doch ein großer schritt für mich

 

[BPlagens]

Cool - danke für die Rückmeldung!

Aber wie ist denn jetzt der Aufbau des Tag-Namen?

Muss ich nächste Woche doch glatt mal selber mit spielen!

Viel Erfolg!

 

[Lord Cartman]

Zuviel Werbung?
-> Hier kostenlos registrieren

wie das entgültige ergebniss aussieht kann ich dir noch nich sagen. hab jetz erstma nur rausgefunden das die kommunikation über diesen baustein zu bewerkstelligen ist.
unter der tcp-connection lassen sich "receive" und receivedata" bausteine, bzw variablen hinzufügen.
normalerweise sollte dann das gesamte datenpaket des puffers hier empfangen werden und bei mehreren variablen dann wieder entsprechend aufgeteilt werden um den daten-knäul zu entwirren.
wenns soweit is, stell ich die fertigen tags hier rein^^

 

[Dr. OPC]

Sorry hatte das hier nicht gesehen.

Im Prinzip habt ihr das ja schon heraus gefunden. Es ist tatsächlich so das der OPC Server (zumindest der von SimaticNET), wenn man eine BReceive-Variable anlegt (und in eine aktive OPC Gruppe hängt) einen "Empfangspuffer" bereitstellt, in den dann eine SPS mit dem dazugehörigen BSend "senden" kann. Ich habe das mal in einem anderen Thread beschrieben:
http://www.sps-forum.de/showpost.php?p=241397&postcount=3

Also alleine durch die Verwendung des OPC Items wird entschieden ob ein sogenannter Blockdienst oder ein Variablendienst verwendet wird
1) Blockdienst: S7:[Verb_1]BRCV,1,B0,1024
2) Variablendienst: S7:[Verb_1]DB1,B0,1024

Beide Varianten liefern die gleiche Datenmenge, aber bei 1) muss eine SPS auf RID1 etwas senden und bei 2) wird vom OPC Server aus gepollt. Nun kann man bei den Blockdiensten weitere "OPC-Items" angeben, die dann (nur) einen "Ausschnitt" des gesamten Empfangspuffers repräsentieren.

In beiden Fällen muss eine S7-Verbindung projektiert werden. Bei 1) muss diese beidseitig sein, sonst weiss die SPS ja nicht wohin gesendet werden muss.

Der ganze Zusammenhang wird im Handbuch "Industrial Communication with PG/PC Volume 2 - Interfaces" im Kapitel "2.5.5 Bufferoriented services" ganz schön beschrieben (wird mit SimaticNET mitinstalliert)

Ob das Ganze auch mit S7-1200 funktioniert kann ich nicht sagen, habe es bisher nur mit 300 und 400 probiert und dort FC5 und FC6 aufgerufen.

 

[Lord Cartman]

Hey,
ich danke dir für deine Unterstüzung.

Zu der Verwendungsmöglichkeiten der Items: Die Variante2, also die mit dem Variablendienst, hatte ich ja bereits projektiert, das läuft auch soweit gut. Bei der ersten Variante muss noch die Verbindung auf beidseitig eingestellt werden, das könnt vlt schon der Fehler gewesen sein. Wo lässt sich das denn einstellen?

Meine Idee war gewesen eine neue Verbindung über TCP einzurichten. Dadurch erscheint im OPC-Navigator ja eine neuen Verbindung: Send/Receive. Hier lässt sich unter receive eine neue Definition hinzufügen, entweder der default-empfangspuffer oder selbst erstellt variablen/Items. Leider erscheint in diesem Puffer keinerlei Daten und er wird auch als ungültig angezeigt.

Hab mal ein screenshot angehängt ums zu verdeutlichen. (Der grüne Bereich funktioniert über pollen, der rote bereich is die neue verbindung)

*von siemens gibts auf offizieller seite übrigens noch keine freigabe ob dieses zusammenspiel überhaupt funktioniert. kann auch sein dass wir unnötig diskutieren

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Customer Support fand ich folgendes Beispiel, wie ich finde ganz gut erklärt.
http://support.automation.siemens.com

Beitrags-ID: 21523291
da wird Send/Receive mit OPC gezeigt

Also ich hol mal etwas weiter aus:
Es gibt das S7-Protokoll ("modern") und das SR-Protokoll ("alt" aus S5 Zeiten) für beide gibt es Variablen und Blockdienste. BSEND/BRCV ist S7 Protokoll (da muss eine S7Verbindung angelegt weden) und SEND/RECEIVE ist SR Protokoll (und es muss eine TCP/ISOonTCP Verbindung angelegt werden). Da OPC prizipiell mit Variablen (Items) arbeitet, ist der Variablendienst eigentlich besser geeignet um ihn mit OPC zu verwenden. Dennoch können mit OPC auch Blockdienste benutzt werden, in OPC ist das dann erstmal eine Variable vom Typ ArrayOfByte und der Client muss halt irgendwie selber wissen was, ab welchem Offset, was bedeutet. Da das keinen OPC Client von sich aus wissen kann, können nun auf dem "Empangspuffer" zusätzlich Variablen definiert werden, die quasi einen "Ausschnitt" aus dem Array als einzelne OPCVariable darstellen. In Richtung SPS existiert aber immer nur der ganze Puffer. Wenn noch niemals etwas von der SPS gesendet wurde ist die "Quality" der OPC Variablen, die den "Empfangspuffer" darstellt, immer "bad", daher muss erstmal etwas gesendet werden.

Auch vielleicht hilfreich ist
Beitrags-ID: 40556214
da wird eine Verbindung zwischen 1200 und 300 gezeigt.

 

[Dr. OPC]

Hatte deine Frage zur Verbindungseinstellung überlesen.
Steht aber auch in Beitrags-ID: 21523291

Also die Verbindung wird in Netpro angelegt und dort gibt es "One-Way" oder eben nicht. Weiterhin sollte die Verbindung als "Permanent" projektiert werden, sonst würde sie nach jeden Senden bzw. Empfang wieder abgebaut werden. Das ist im Prinzip nicht schlimm (nur langsamer) aber hat auch zur Folge das die dazugehörige "OPC-Empfangspuffer-Variable" zwischendurch immer wieder Quality=bad bekommt da der OPC Server sich erschreckt wenn die Verbindung plötzlich weg ist.

 

[Lord Cartman]

Also wenn ich dich richtig verstanden habe, dann muss zunächst der "normale" empfangspuffer hinzugefügt werden. der wird im opc-navigator mit einem klick auf den receive-katalog direkt angeboten. (Siehe screenshot obiger beitrag) Seine Bezeichnung im Scout ist anschließend: "SR:[TCP_connection1]receive". Für seinen Wert steht "{}" und für den Typ "uint8[]".
Nachdem der hinzugefügt ist, müssen noch weitere benötigte items hinzugefügt werden? mit den werten die angegeben werden müssen, zb adresse , wird dann der wert des items in dem empfangspuffer angegeben, aus dem die variable gebildet werden soll?

Ich glaub das problem is eig fundamentaler, da die kommunikation zwischen opc und sps nicht funktionier. der zustand "ungültig" ändert sich leider auch durch ein "scannen" nicht.

Die Verbindung ist in Netpro bereits angelegt. die s7 verbindung läuft wie gesagt bereits erfolgreich (polling-verfahren funktioniert), und die neue tcp-verbindung steht auch, aber eben ohne erfolg. zu dem "one-way": kann man das irgendwo nachprojektieren bzw überhaupt ansehen, was eingestellt ist?

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

sorry war vielleicht missverständlich.

"SR:[TCP_connection1]receive". Für seinen Wert steht "{}" und für den Typ "uint8[]"

Das bedeutet es wird im OPC Server ein Empfangspuffer bereitgestellt, falls nun über SR-Protokoll auf der TCP-Verbindung jemand etwas sendet (einen Send in der SPS aufruft) dann kommt das hier an (und stellt sich als Array of unsigned integer 8bit dar). Es kommt also als ByteArray.

Nun weißt aber nur Du (der die SPS programmiert hat) wo in diesem Array welche Daten ab welchem Offset wie zu interpretieren sind. Nur Du weisst z.B. dass ab Offset-Addresse 12 die nächsten 4 Bytes eigentlich eigentlich Doppelwort sind und die Temperatur des Kessels enthalten. Nun kann man, muss man aber nicht, ZUSÄTZLICH Variablen definieren, die "Ausschnitte" aus dem Puffer enthalten, und dann könnte man SR:[Verbindung]receive,DWord12,1 definieren (oder so ähnlich, musste nochmal nachschauen im Handbuch).

Falls Du schon eine funktionierende S7-Verbindung hast, solltest du den BSEND und BRCV probieren (S7:[Verbindung_1]BRCV), falls die SPS das unterstützt.

Das SR-Protokoll funktioniert ähnlich aber etwas anders. Du musst eine Verbindung und ein Protokoll einstellen, dass von beiden unterstützt wird. Der OPC Server kann prinzipiell alles, was für eine SPS ist es denn und über welchen CP geht das? Ich habe es mit 315/343 und 412/443 ausprobiert und es geht.

 

[Dr. OPC]

Ah verstehe Du machst TSend, damit wird die Sache etwas komplizierter.
Für den TSend müssen einige Dinge vorab richtig aufgerufen werden damit die Verbindung überhaupt zustande kommt, in der SPS wird die Verbindung quasi "on the fly" konfiguriert. Genauer gesagt FB65 "TCON" und die Datenstruktur UDT65 "TCON_PAR" mit den Verbindungsparametern zum Aufbau der TCP Verbindung. Hierbei entscheidend ist das die TCP Endpoint Konfiguration korrekt angegeben wurde. IP Adressen, Portnummern auf beiden Seiten, auch sollte nur eine Seite "aktiv" sein.

Die Verbindungseite im OPC Server wird normalerweise mit NetPro projektiert, hier muss dann also die zur SPS passende Seite der Verbindung eingestellt werden.

Erklärt wird das hier:
Beitrags ID: 29737950 im Customer Support
http://support.automation.siemens.com/WW/llisapi.dll?query=29737950&func=cslib.cssearch&content=adsearch%2Fadsearch.aspx〈=de&siteid=cseus&objaction=cssearch&searchinprim=0&nodeid0=10805384&x=0&y=0

 

[Lord Cartman]

ok. ich glaub das prinzip des empfangens hab ich jetz verstanden
das problem liegt wahrscheinlich an der herstellung der kommunikation. die verbindung soll ja zwischen einer s7-1211C mit dem opc server hergestellt werden. in der 1200er reihe gibts diese bsend und brcv baustein leider nichmal mehr, sondern nur noch tsend und trcv.
das CM der sps ist die 1241. das is aber nur für die kommunikation über rs232 da, also die verbindung mit dem scanner. die verbindung zum server läuft über die integrierte schnittstelle auf der cpu ab.

zu den TCON und TCON_PAR: diese bausteine gibts leider auch nicht in der 1200er reihe. bei dem TSEND_C der im katalog steht lässt sich der zu sendende datenbereich angeben und über ein eingangsparameter "connect" eine verbindung anbinden. diese verbindung wird über ein eigenschaftsfenster für den baustein konfiguriert. Hier lassen sich die IPs für beide Teilnehmer angeben, der Verbindungstyp (hier TCP), die Verbindungs-ID (hier 1), welcher der Partner aktiv ist und zu guter letzt der Partner-Port (Hier 2000).
das wars schon mit den konfig auf sps seite.

die ganzen beispiele auf siemens seite beziehen sich ja leider auf die älteren 300/400er reihen. den brauchbaren teil davon hab ich schon rausgefischt, aber leider noch ohne erfolg :-|