# Datenbaustein an OPC



## Human (9 März 2007)

Hallo!

Ich bin gerade immernoch dabei an meinem SPS-OPC-MSSQL-Projekt. Die Kommunikation zwischen den einzelnen Komponenten läuft auch immernoch gut.

Ich möchte einen kompletten Datenbaustein von der SPS von meinem OPC-Server als String holen lassen.

In dem Datenbaustein habe ich ganz oben einen String mit 0 Zeichen eingefügt, damit ich die 2 Steuerbytes habe. Diese manipuliere ich (beide Steuerbytes auf Dezimal 254) und bekomme dann einen 254 Zeichen langen String am OPC-Server. Soweit so gut!

Das Problem besteht jetzt darin, dass der OPC-Server den String abschneidet, sobald in dem String ein Byte Dezimal 0 ist.

Kann ich den Datenbaustein sonst noch irgendwie "rüberschmeißen" ohne 200 Items erstellen zu müssen?


----------



## Question_mark (9 März 2007)

*String*

Hallo,



			
				Human schrieb:
			
		

> dass der OPC-Server den String abschneidet, sobald in dem String ein Byte Dezimal 0 ist



Wundert mich nicht, die "0" ist die Endekennung des Strings ...




			
				Human schrieb:
			
		

> Kann ich den Datenbaustein sonst noch irgendwie "rüberschmeißen" ohne 200 Items erstellen zu müssen?



So ganz auf die Schnelle, ohne gross nachzudenken : Array of byte ????

Gruss

Question_mark


----------



## Hamster (23 März 2007)

Hallo Human

Der OPC DA Server von Siemens unterstütz den Blockdienst. Du kannst um grössere Datenmengen in deine Applikation (OPC-Client) zu verschieben BSEND/BRCV verwenden. Damit kannst du Daten bis 64kB versenden. Die Kommunikation kannst du von der S7 her anstossen.
Der Einsatz von BSEND/BRCV auf PB DP setzt jedoch einen CP vorraus!

Wie hast du deine String-Variente genau umgesetzt? Würde mich interessieren.

Gruss Hamster


----------



## Human (23 März 2007)

Das mit dem String habe ich relativ schnell wieder verworfen, wäre zu aufwendig geworden.

Den Lösungsansatz hätte ich ja schon:
Die 0-Bytes ein Bit auf TRUE und dann ein Konfigurationsbyte entweder auf 1, wenn das Byte genau so übergeben werden soll, auf 2, wenn das eine Bit "verfälscht" worden, aber da hätte ich das dann erst auf der CPU "codieren" und im Programm wieder "decodieren" müssen, das wäre aber sicher ein Riesenaufwand geworden und ich hätte doppelt so viel übertragen müssen, als ich eigentlich müsste oder einfach zu jedem Byte 1 dazuzählen, aber dann wäre wieder die Gefahr, dass es nach -1 wieder auf 0 springt...

Zum Glück arbeiten noch ein paar sehr erfahrene SPS-Programmierer mit mir zusammen und haben mir den Tip mit dem SFB12 und SFB13 gegeben.

Ich habe das auch so weit hinbekommen, dass ich von der CPU die Daten übertragen bekomme und auch etwas in einen DB auf der CPu schreiben kann, doch wenn ich die Referenz-ID (nicht die Verbindungs-ID) auf der CPU und im OPC-Item ändere und PC und CPU neu starte bekomme ich eine Fehlermeldung 6 vom BSEND zurück, was heißt, dass die Gegenstelle "DISABLED" (steht so in der Hilfe in der Fehlerbeschriebung) ist, vielleicht eine Idee, was ich falsch mache?


----------



## afk (23 März 2007)

*Warum so umständlich ?*



Question_mark schrieb:


> So ganz auf die Schnelle, ohne gross nachzudenken : Array of byte ????


QM hat Dir die Lösung doch schon genannt, warum betreibst Du also so einen Aufwand ?  

Im OPC-Server stehen dir neben den einfachen Datentypen auch Arrays von diesen Typen zur Verfügung. Wenn ich mich richtig erinnere, dann hängst Du an das OPC-Item einfach kommagetrennt die Anzahl der Arrayelemente an, und der OPC-Server liefert statt z.B. einem Byte ein Array of Bytes. Damit hast Du doch schon alles was Du brauchst, oder nicht ?


Gruß Axel


----------



## Human (24 März 2007)

Das mit dem String habe ich natürlich nicht umgesetzt, das wäre mehr oder noch weniger der letzte Weg gewesen (bloß so blöde Gedanken, die man sich macht, wenn abends mal langweilig ist).

Ich hatte dann 4 Mögliche Wege zum Einschlagen und habe diese mit meinem Chef erörtert:

Singel-Items: Bisschen arg unhadlich

Die String-Variante: Zu aufwendig

Dann blieben noch das Array of Byte und die Möglichkeit mit dem Blöcken:

Die Blöcke haben den großen Vorteil, dass man sie kontrolliert von der CPU senden kann und nicht wie das Array ständig neu geladen wird: Er hatte auch mal ein Programm geschrieben zur Kommunikation zwischen CPU und PC, damals aber noch über MPI, da hatte er das Problem, dass die Daten aus dem DB auch mal mitten im Zyklus geholt worden sind, was natürlich Fehler verursachte.
Ob der OPC die Daten immer nach einem CPU-Zyklus oder dazwischen oder sonstwie holt habe ich bisher noch nirgends gelesen, aber meiner Meinung nach ist das wohl der sicherste Weg die Daten "sauber" an den OPC zu schicken.

Auch wenn ich den Vorschlag von QM nicht angewendet habe bin ich trotzdem sehr dankbar für den Vorschlag, der mich schonmal ein ganzes Stück weitergebracht hat.


----------



## Question_mark (24 März 2007)

Hallo,



			
				Human schrieb:
			
		

> Ob der OPC die Daten immer nach einem CPU-Zyklus oder dazwischen oder sonstwie holt habe ich bisher noch nirgends gelesen



Du kannst davon ausgehen, dass die Daten immer asynchron zum SPS-Zyklus eintreffen.

Gruss

Question_mark


----------



## Question_mark (25 März 2007)

*Dein Chef, der Supertrottel*

Hallo,



			
				human schrieb:
			
		

> da hatte er das Problem, dass die Daten aus dem DB auch mal mitten im Zyklus geholt worden sind, was natürlich Fehler verursachte.



Nee wie schön, such Dir doch mal einen Cheffe, der auch ein wenig Ahnung hat...
Natürlich verläuft die Kommunikation beim OPC-Server völlig asynchron zum SPS-Zyklus. Und Du (und vor allem Dein Volltrottel aka Cheffe) werdet es mir wahrscheinlich nicht glauben :  Alles ist noch abhängigig von der im OPC-Server eingestellten Updaterate für die OPC-Groups b.z.w. OPC-Items  

Gruss

Question_mark


----------

