TIA Struktur in Array of Bytes kopieren

gargantua

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

ich möchte gerne Daten von einem Profibus-Gerät lesen.
Es handelt sich dabei um eine 6 Byte große Struktur.

Eine passende UDT namens "SensorData" habe ich schon angelegt.

TYPE "SensorData"
STRUCT
StatusDevice : Byte;
StatusMesswert : Byte;
Messwert: Real;
END_STRUCT;
END_TYPE


Zum Lesen der Daten nutze ich DPRD_DAT (SFC14). Leider kann man DPRD_DAT keine Strukturen übergeben sondern nur einfache Arrays.
Ich habe nun ein 6 Byte großes Array definiert (Temp_1 : Array [1 .. 6] of Byte) und damit die Daten gelesen.

Gibt es eine Möglichkeit dieses Array in eine gleich große Struktur vom Typ "SensorData" zu kopieren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe gleich mal in der Hilfe nachgeschaut.
BLKMOVE gibt es nur bei der S7-1500, ich habe die S7-1200 :sm9:.
Dort gibt es nur MOVE_BLK, der funktioniert aber auch nur mit Arrays.
 
Etwas gebastelt in SCL. Musst du wissen, ob's dir gefällt

Im Datenbaustein "DATEN":
SensorDaten vom Typ "SensorData"

im FC noch eine temp. Variable tmp_dword als DWord angelegt

Code:
"DATEN".SensorDaten.StatusDevice := #Temp_1[1];
"DATEN".SensorDaten.StatusMesswert := #Temp_1[2];
#tmp_dword.B0:=#Temp_1[3];
#tmp_dword.B1:=#Temp_1[4];
#tmp_dword.B2:=#Temp_1[5];
#tmp_dword.B3:=#Temp_1[6];
"DATEN".SensorDaten.Messwert:=DWORD_TO_REAL(#tmp_dword);

HINWEIS:
Bei der S7-1200 (ab FW V2.0) und der S7-1500 haben Sie die Möglichkeit, bitweise auf Variablen vom Datentyp Byte, Word oder DWord zuzugreifen. Hierfür benötigen Sie STEP 7 V11+SP1+Update 2 (oder höher).
Quelle

 
Zuletzt bearbeitet:
.
Sc.... TIA,
hast recht,
das ist dieser Beitrag: HIER .

Aber vielleicht weiss da einer der anderen
User mehr, die mit TIA arbeiten.

Alternativ verschiebst die 6 Byte mit dem
Move-Befehl erstmal einzeln.
 
@shutdown:
Das ist natürlich die sauberste Lösung. Werde ich wohl so übernehmen.

Ich komme eigentlich aus der C/C++ Welt, deshalb eine Frage:
Gibt es bei TIA-Strukturen so etwas wie Padding (d.h. zwischen einzelnen Elementen einer Struktur werden Leerbytes eingefügt, so dass die Elemente immer auf einer durch 2 oder 4 teilbaren Speicher-Adresse liegen)? Das würde mir erklären warum DPRD_DAT nur mit Arrays funktioniert.
 
@Pipboy: Das habe ich auch mal probiert und es funktioniert.
Ich werde trotzdem die Variante von shutdown_TIA12 nutzen. Das ist einfach sauberer (dann bin ich unabhängig davon wie TIA die Struktur verwaltet und muss auch die Bausteinoptimierung nicht abschalten).

Danke für Eure Hilfe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@shutdown:
Das ist natürlich die sauberste Lösung. Werde ich wohl so übernehmen.

Ich komme eigentlich aus der C/C++ Welt, deshalb eine Frage:
Gibt es bei TIA-Strukturen so etwas wie Padding (d.h. zwischen einzelnen Elementen einer Struktur werden Leerbytes eingefügt, so dass die Elemente immer auf einer durch 2 oder 4 teilbaren Speicher-Adresse liegen)? Das würde mir erklären warum DPRD_DAT nur mit Arrays funktioniert.

Hi all

ja in der wundersamen Welt des TIA gibt es Padding. Sogar zwei Regelsätze :ROFLMAO:

Standard Baustein verwenden das was Siemens seit 15 Jahren macht. Das Meiste ist auf 2Byte ausgerichtet. Bei Array of BOOL wird es ungemütlich. Aber alles im Buch des Hans Berger beschrieben und von AWL Masochisten ausgiebigst verwendet.
Optimierte Bausteine verwenden scheinbar ganz andere Regeln. Man kann das sehen, wenn man in einem bunt Typ gemischten DB immer nur einen Wert auf FF oder FFFF oder FFFFFFFF setzt, und dann mit Wireshark das Laden mitschneidet :D. Wenn ich mich nicht verzählt habe, dann liegen die Daten immer so, dass sie ihrere Größe entsprechen. Also ein 2 Byte Typ liegt auf einer durch zwei teilbaren Adresse. Ein 4 Byte Typ liegt auf einer durch 4 teilbaren Adresse. Ein 8 Byte Typ liegt auf einer durch 8 teilbaren Adresse. BOOL und ein Byte typen liegen in einem Byte. Ja, für ein BOOL scheint ein ganzes Byte verwendet zu werden. Strukturen bleiben zusammen. Arrays auch. Die Elemente einer Struktur werden durcheinander gewürfelt. Wenn ich das richtig sehe, dann die Großen zuerst. Aber Vorsicht mit Strukturen, wie Strukturen zueinander liegen, habe ich nicht untersucht, da hat mich die Lust verlassen. :rolleyes:

Die Reihenfolge in der die Elemente in den DB kommen spielt scheinbar keine Rolle. Pech für AWL Freaks. Klares aus für AR Jongleure.

Alles in allem kann man wohl sagen, dass die Regeln für die optimierten DB vermutlich dazu beitragen, dass der Prozessor ohne Byte und Bit-Geschiebe die Daten schnell aus dem Speicher holen kann. Andere (richtige?) Sprachen wie C# und Java machen das ja auch so. Und schnell meint 6 mal schneller schreiben und drei mal schneller lesen als Standard DB.

'n schön' Tach auch.
HB

Wireshark ist mein Freund.
 
@HelleBarde: War das 1200er oder 1500er?

Die letzten DB Untersuchungen habe ich mit einer 1516 und TIA V12.0 gemacht. 6 mal schneller schreiben bezieht sich auf die 1500 und V12.

Die 1214 (also vermutlich alle 1200) ist ein wenig anders. Da wurden auch bei optimierten DB im TIA V10.5 mehrere BOOL in einem BYTE gesammelt. Es machte keinen messbaren Unterschied ob das BOOL im optimierten oder im standard DB lag. Es machte jedoch gelegentlich einen Unterschied ob das REAL standard oder optimiert lag. Und zwar immer dann, wenn das REAL im Standard auf einer krummen zu liegen kommt. Die Unterschiede sind jedoch bei weitem nicht so klar und eindeutig wie bei der 1516. Und bei 10.5 gab es auch noch keinen RUNTIME.

Was ich jedoch noch nicht probiert habe ist ob mit TIA V12 und der 1214 neue Unterschiede zu Tage treten. Und ob es jetzt dort einen RUNTIME gibt.

So ein Tag ist einfach zu kurz um neben all den Wünschen der Kunden auch noch die CPU zu durchleuchten.

'n schön' Tach auch
HB
 
Zurück
Oben