TIA Mehrere DBs zu einem DB zusammenfassen

Entkalker

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich möchte einen DB für einen OPC UA Server freigegeben.
Dafür sollen alle vorhandenen Variablen unterschiedlicher Datenbausteine zu einem
Datenbaustein zusammengefasst werden. Wie mache ich das?

Gruß Josh
 
Du könntest zum Beispiel im OPC UA DB die Datenbereiche die übertragen werden müssen festlegen. Danach baust du dir einen FC der die Daten aus den anderen DBs sammelt und zum OPC UA DB per MOVE verschiebst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In dem FC den Egon323 erstellen will könnte man das nicht mit poke_blk machen? den Offset für die verschiedenen DB die du kopieren willst kannst du dir ja vielleicht ausrechnen und als variable antragen, dann wärst du sicher falls du mal einen DB erweitern willst?
Nur mal so als Idee, wie genau das aussehen müsste weis ich auch noch nicht, hab noch nicht so viel mit poke_blk gearbeitet.
Siehe in der hilfe poke_blk das Beispiel, so könnte ich mir das vorstellen.
Damit kannst du deinen komplette DB kopieren.
Man müsste nur irgendwie die göße des DB auch automatisch ermitteln können, damit du immer die richtige Länge hast.
 
Der TE hat nicht angegeben welche CPU er verwendet - deshalb wird es schwierig im konkrete Tipps zu geben zu MOVE/POKE-Varianten, die es dann womöglich für seine CPU gar nicht gibt.

Harald
 
Der TE hat nicht angegeben welche CPU er verwendet - deshalb wird es schwierig im konkrete Tipps zu geben zu MOVE/POKE-Varianten, die es dann womöglich für seine CPU gar nicht gibt.

Harald

OPC UA ist mir nur bei den Plus PLC bekannt, daher bin ich davon ausgegangen des der TE eine solche verwendet.

Möge der TE uns doch bitte aufklären.
 
Ich hab noch nicht genau verstanden was du vor hast. Möchtest du wirklich ganze DBs zu einem zusammenfassen nach dem Motto: DB_OPC := D1 + D2 + ... + Dx?
 
Ja genau das ist der Plan ein DB der an den OPC Server weitergegeben werden soll. Grund dafür ist das es ein universeller DB werden soll der in allen Projekten wiederverwendet werden soll und mit wenig Aufwand angepasst werden kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also erstmal grundsätzlich: so eine Funktion gibt es nicht. Heißt also selber bauen. Dafür wären folgende Infos ganz wichtig:

Wie sehen deine DBs denn aus? Sind das Arrays, UDTs oder einzelne Variablen unterschiedlichen Typs oder gar von allem etwas? Und sind deine DBs optimiert und soll der OPC-DB optimiert sein?
 
"Schnittstelle nach außen" und "universell" und "in allen Projekten wiederverwenden" ist für mich ein Widerspruch in sich - oder haben alle Deine Projekte die selben Variablen? Wie viele Variablen sind bei Dir "alle Variablen"? Sind das nur Kleinst-Projekte mit 50 Variablen? Oder sind alle Deine Variablen als Arrays organisiert?

Die Struktur des Sammel-DB und das Zusammenkopieren von vielen Variablen bzw. Datenbereichen wird erfahrungsgemäß in jedem Projekt stark angepasst werden müssen, und es wird ziemlich haarig und aufwendig, wenn da womöglich auch noch Variablen aus "optimiertem" Speicher dabei sind.

Harald
 
Es sind sowohl Arrays als auch einzelne Variablen. Was meinst du mit optimiert?

Die Programme sind in den Grundzügen gleich aufgebaut.
Außerdem geht um die Variablen wie Laufzeiten (gesamt, Tag, Monat...), Betriebszustand (run, stop)
 
Wenn du auf die Bausteineigenschaften deiner DBs schaust, dann gibt es dort unter dem Tab "Attribute" die Option "Optimierter Bausteinzugriff". Damit steht und fällt dann die Möglichkeit größere, zusammenhängende Bereiche mittels Pointer zu kopieren.
 
Dazu ist noch zu bedenken das es ja nicht damit getan ist die dbs auf den komplettdb zu kopieren. Womöglich will man ja über OPC auch schreiben. Also muss auch zurückgelesen werden. Was passiert wenn ein schreibzugriff vom programm grad überschrieben wird bevor gelesen werden kann?

Da würde ich mir eher überlegen ob es nicht sinn macht direkt in die DBs zu kommunizieren. Man kann ja die Objekte vernünftig benamsen dann hat man überhaupt keinen Aufwand was anzupassen da die Objekte ja entweder existieren oder nicht.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmm grundsätzlich müsstest du die Struktur deiner einzelnen DB's in den einen kopieren und die Daten dann händisch rangieren. Ist dann eigentlich primitive Fleißarbeit. Die Frage nun wäre, ob du das wirklich zyklisch machen willst, da die Performance wohl in die Knie geht, wenn du in jedem Zyklus deine Daten packst. Vermutlich reicht bei den oben genannten Infos auch dein Cyclic interrupt (OB30 aufwärts). Wenn du allerdings aus dem OPC auch schreibst wird es nochmals aufwändiger.

Aber mal ne andere Frage: Warum machst du dir nicht die Mühe die Daten für den OPC aus den unterschiedlichen DBs abzuholen? So bist du doch auch hinsichtlich späteren Änderungen viel flexibler und hast dir auch die Arbeit mit dem Rangieren der Daten erspart...
 
Gelplant ist es den "OPC DB" auf eine Android App zu übertragen. Hierbei benutze ich den OPC DB zum fixieren der Variablen.
Bei Änderungen muss man dann nurnoch die Eingänge zum OPC DB ändern.
 
Also grundsätzlich kann ich das schon nachvollziehen das man genau EINEN Datenbaustein nimmt um zum OPC zu koppeln.

Nur so etwas möglichst universell zu schreiben, ist ohne den genauen Aufbau der Daten zu kennen unmöglich.

Wenn du optimiert unterwegs bist, dann bleibt dir bei einzelnen Variablen wenig übrig, als DB_OPC."Anzahl guter Produkte" := DB1."Anzahl guter Produkte"
Wenn es sich um Teilbereiche von Arrays handelt, dann würde ich wohl mit dem MOVE_BLOCK_VARIANT arbeiten.
Ganze Arrays lassen sich genau wie UDTs mit: DB_OPC."Array oder UDT" := DB1."Array oder UDT" zuweisen.

Wenn du allerdings nicht optimiert unterwegs bist, dann kannst du große Bereiche halt auch sehr gut mit dem BLKMOV und Pointern verschieben.

Es ist halt gerade schwer dir konkret zu helfen ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich sehe keine "Mühe" wenn die genannten Daten über Datentypen definiert sind. Man kann ja die Datentypen stufenweise Strukturieren, also Datentypen mit Datentypen definieren.
Das hilft auch wenn man alle Daten auf einmal zugreifen will oder nur untergeordnete Datenstrukturen, oder ganz unten die elementaren Datentypen.
Das beeinflusst auch nicht den CPU Performance, wenn die Daten nicht bei jeden Zyklus übertragen werden, da den Parameter über Pointer definiert werden. Die Daten werden nur übertragen wie man es programmiert. Es sir denn, es handelt um shr grossen Datenmengen und man schaufeln sie in jeden Zyklus.
Man braucht auch kein händischen rangieren, auch nicht bei Änderungen. Es passiert alles automatisch wenn man die Datentypen ändert.
Das sollte auch funktionieren egal ob optimiert oder nicht optimiert (wobei ich nie "optimiert" verwende).

Für den Übertragen über OPC nehme ich an das es ist auch mehr Performant die Daten ein ein Sammel-DB zu packen.
 
Ich sehe keine "Mühe" wenn die genannten Daten über Datentypen definiert sind. Man kann ja die Datentypen stufenweise Strukturieren, also Datentypen mit Datentypen definieren.
Das hilft auch wenn man alle Daten auf einmal zugreifen will oder nur untergeordnete Datenstrukturen, oder ganz unten die elementaren Datentypen.
Das beeinflusst auch nicht den CPU Performance, wenn die Daten nicht bei jeden Zyklus übertragen werden, da den Parameter über Pointer definiert werden. Die Daten werden nur übertragen wie man es programmiert. Es sir denn, es handelt um shr grossen Datenmengen und man schaufeln sie in jeden Zyklus.
Man braucht auch kein händischen rangieren, auch nicht bei Änderungen. Es passiert alles automatisch wenn man die Datentypen ändert.
Das sollte auch funktionieren egal ob optimiert oder nicht optimiert (wobei ich nie "optimiert" verwende).

Für den Übertragen über OPC nehme ich an das es ist auch mehr Performant die Daten ein ein Sammel-DB zu packen.

Das sehe ich genau so. Ist halt nur die Frage ob der TE das so strukturiert hat oder noch umstrukturieren kann/darf/will.
 
Zurück
Oben