TIA Kopieren zwischen Standard DB und optimiertem DB

Mephisto · 11 September 2018

Hallo!

Ich hab hier ein mittelgroßes Problem:
Ich habe einen Standard (also nicht optimierten) DB in dem ein Array abgelegt ist.
Die Daten dieses DB möchte ich in einen optimierten DB kopieren.
In weiterer Folge soll das dann auch in die andere Richtung funktionieren.

Ich möchte einen SCL-FB schreiben, der diese Arbeit erledigt. Quell- und Ziel-DB sollen dabei als Außenbeschaltung (IN, INOUT, etc.) angegeben werden.
Hab dazu schon mit PEEK & POKE, MOVE_BLK und den Datentypen DB_ANY sowie VARIANT rumgespielt.

Zwischen zwei optimierten DBs klappt es wunderbar (PEEK & POKE)
Zwischen zwei Standard DBs klappt es wunderbar (MOVE_BLK)
Nur zwischen optimierten und Standard DB krieg ich es zum verrecken nicht hin.

Kann mir hier mal einer vielleicht einen guten Tipp geben?
Bin für jede Hilfe dankbar.

mfg mephisto

ducati · 11 September 2018

ne Schleife und das Array durchkopieren?

Aus der DB-Nummer dann die Variable zusammenzubauen sollte doch irgendwie gehen? Bei Step 7 Classic ging das jedenfalls noch.

Gruß.

Mephisto · 11 September 2018

Bei Step7 Classic ging gas noch, bei TIA leider nicht mehr, dafür gibt's jetzt Peek & Poke

ducati · 11 September 2018

ok, warum unbedingt nen FB dafür? Sind doch nur 3 Zeilen SCL-Code, den Du im normalen Programm einfach in nen Netzwerk packen kannst...

Gruß.

ducati · 11 September 2018

in der TIA Hilfe hab ich das hier gefunden:

#MyDBAny.%DBX30.0
Absolute Adressierung der Variablen "DBX30.0" im dem globalen Datenbaustein, der zur Laufzeit am Parameter "MyDBany" übergeben wird.

geht das nicht? also #MyDBAny.arrayelement ???

gruß.

JesperMP · 11 September 2018

Wenn die Daten die man übertragen will mittels UDT definiert sind, geht das in SCL ?

"optimiert_db".udt_data := "nicht_optimiert_db".udt_data ;

Also, keine Schleife oder sonnst.

ducati · 11 September 2018

JesperMP schrieb:
Wenn die Daten die man übertragen will mittels UDT definiert sind, geht das in SCL ?

"optimiert_db".udt_data := "nicht_optimiert_db".udt_data ;

Also, keine Schleife oder sonnst.

Ja, aber er will die DB-Nummern bzw. DB-Namen variabel gestalten... Und er hat kein UDT sondern Arrays...

Gruß.

JesperMP · 11 September 2018

Vielleicht ist den alternative Verfahren (mit SCL) akseptabel, wenn man sieht wie einfach es geht.
Selbst wenn man in KOP oder FUP programmiert, dann kann man heute ein einzelne SCL Zeile in ein KOP oder FUP Baustein reinmachen. Das finde ich genial, genau für solche Aufgaben (*).
Dann braucht man nicht über PEEK/POKE/MOVE_BLK o.Ä zu kümmern.

Und UDTs ist mMn. eigentlich Pflicht wenn man zwischen unterschiedliche Bausteine Daten hin und her senden will, ob Array oder kein Array.

*: Bemerk, Lob an TIA (!).

ducati · 11 September 2018

falls der optimierte DB die "Remanenzeinstellung "Im IDB setzen"" hat, sollte eigentlich auch "Pointern" in AWL gehen...

aber ich würd eigentlich auch einfach den 3 Zeiler im normalen Programm unterbringen, also ohne Kopier-FB...

Gruß.

ducati · 11 September 2018

letzte Idee: Array-DBs verwenden mit dem Befehl ReadFromArrayDB - WriteToArrayDB. aber keine Ahnung ob der bei optimiert und nichtoptimiert funktioniert

Gruß.

hucki · 11 September 2018

ducati schrieb:
falls der optimierte DB die "Remanenzeinstellung "Im IDB setzen"" hat, ...

Diese Einstellung ist nur für Variablen in optimierten FBs möglich.
Ansonsten hat man ja schließlich auch keinen I(nstanz)DB, in dem man die Remanenz setzen könnte.

PN/DP · 11 September 2018

Mephisto schrieb:
Zwischen zwei optimierten DBs klappt es wunderbar (PEEK & POKE)
Zwischen zwei Standard DBs klappt es wunderbar (MOVE_BLK)
Nur zwischen optimierten und Standard DB krieg ich es zum verrecken nicht hin.

Ich habe auch keine Erfahrung mit Kopieren zwischen DB mit unterschiedlicher Zugriffsart, doch hier hast Du irgendwie was durcheinander gebracht: PEEK & POKE arbeiten mit Adressen - das kann gar nicht mit "optimierten" DB funktionieren.
MOVE_BLK oder MOVE_BLK_VARIANT müsste nach meiner Vorstellung auch mit "optimierten" DB und auch gemischt gehen wenn man gleiche Datentypen symbolisch angibt (ich habe es nicht ausprobiert). Probleme bekommt man doch immer nur, wenn man unsymbolisch quer im Speicher rumstochern will. Musst Du wirklich Ziel oder Quelle aus DB-Nummern zusammenbasteln? Vergiss doch diese Nummern. Kann man nicht zwei IN_OUT-Parameter machen:
- SRC_Array : ARRAY [0..99] OF BYTE
- DEST_Array : ARRAY [0..99] OF BYTE
und dann direkt die Arrays symbolisch dranschalten? Wäre auch viel einfacher nachzuvollziehen.

Harald

JesperMP · 11 September 2018

mMn. es geht nicht einfacher:

ich988 · 11 September 2018

Das wurde schon beschrieben

Er möchte jedoch nach DB-Nummer referenzieren. Daher klappt die Methode leider nicht.

Mal so out of the Box gedacht.
Geht nicht in TIA noch der klassische Block Move?
Damit würde es gehen.

hucki · 12 September 2018

ich988 schrieb:
Er möchte jedoch nach DB-Nummer referenzieren.

Wo steht das?
Und wenn wirklich, warum nicht symbolisch, wenn nur von 2 DBs die Rede ist?

Mephisto · 12 September 2018

Hallo!

Zunächst mal vielen Dank für die vielen Inspirationen!
Leider ist mir die Struktur der nicht optimierten DBs vorgegeben.
Mit UDTs arbeiten ist ebenfalls keine Option da die Bausteine für den Kunden geschrieben werden und dessen Programmierer eher Implementierer sind und sich mit UDTs nicht auskennen (wollen).

Ich bin jetzt zu folgender Lösung gekommen:
Ich lese die Variablen nur noch aus den nicht optimierten DB in meinem SCL-FB ein.
Dazu übergebe ich die DB Nummer als DB_ANY.
Ich laufe nun alle relevanten Einträge des DB mittels PEEK in einer Schleife durch und kopiere sie mir in den STAT Bereich meines iDBs.
Mit diesen Werten kann ich dann arbeiten, mit HMI und anderen Bausteinen drauf zugreifen etc.
Nach der Bearbeitung kopiere ich die Variablen wieder mittels POKE und einer Schleife von meinem STAT Bereich in die DBs.

Das funktioniert soweit ganz gut.

Werd auch gleich noch eine Hand voll Danke verteilen

JesperMP · 12 September 2018

Ich muss kommentieren, obwohl das es dir gelungen ist mit PEEK und POKE und DB-Nr usw.

Mephisto schrieb:
Leider ist mir die Struktur der nicht optimierten DBs vorgegeben.
Mit UDTs arbeiten ist ebenfalls keine Option da die Bausteine für den Kunden geschrieben werden

UDTs sorgt einfach 'nur' für ein gemeinsame Struktur. Ein klaren Vorteil wenn Programme von mehrere Personen entwickelt werden muss.

Mephisto schrieb:
[..] und dessen Programmierer eher Implementierer sind und sich mit UDTs nicht auskennen (wollen).

Dann sind sie Idioten, und dürfen eigentlich nicht mit TIA arbeiten. Laut Siemens Programmierletfaden, darf man z.B. kein Struktur (inkl. Arrays) als Baustein Eingabe-parameter machen. Alle nicht-einfache Daten müssen mittels UDTs definiert werden.
Wenn du z.B auch vermeiden will das direkt in ein IDB von aussen geschrieben wird, dann den Struktur als FB Ein/Ausgabe-Parameter einrichten (*). Dann kannst du die PEEKs und POKEs sparen.

*: Das geht ohne oder mit UDT, aber mMn. wäre es schöner/besser/sicherer mit UDT.

Onkel Dagobert · 12 September 2018

Hallo Mephisto,

Mephisto schrieb:
.. Ich lese die Variablen nur noch aus den nicht optimierten DB in meinem SCL-FB ein.
Dazu übergebe ich die DB Nummer als DB_ANY.
Ich laufe nun alle relevanten Einträge des DB mittels PEEK in einer Schleife durch und kopiere sie mir in den STAT Bereich meines iDBs.
Mit diesen Werten kann ich dann arbeiten, mit HMI und anderen Bausteinen drauf zugreifen etc.
Nach der Bearbeitung kopiere ich die Variablen wieder mittels POKE und einer Schleife von meinem STAT Bereich in die DBs. ..

Könntest du mir mal ganz kurz erklären, wofür ein solcher Aufwand notwendig ist?

JesperMP · 12 September 2018

Ein paar Bilder erklärt es viel besser:

Siehst du, einfach ?

hucki · 12 September 2018

Versteh' ich auch nicht, warum man das nicht symbolisch macht.
Die Arrays müssen nicht mal einem udt entstammen. Die gleiche Struktur reicht vollkommen, damit Jespers einfache Methode funktioniert.
Der udt schützt nur noch vor einseitiger Veränderung der Arrays.

TIA Kopieren zwischen Standard DB und optimiertem DB

Level-1

Level-3

Level-1

Level-3

Level-3

Level-3

Level-3

Level-3

Level-3

Level-3

User des Jahres 2014

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-3

Level-1

User des Jahres 2014

Level-1

Level-3

Level-3

Level-3

User des Jahres 2014

Similar threads

Wir schützen deine Privatsphäre