TIA TIA V13 - Im FB Eingangsword nach Localword übertragen

[rkoe1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an Alle,

ich habe folgendes Problem. Vielleicht kann mir jemand dabei helfen.

In Step 7 V5.5 konnte ich im FB ein Eingangsword in den temp-Bereich in ein LW übertragen und dort die einzelnen Bit's bearbeiten. Im TIA V13 funktioniert das zwar immer noch, wird aber als Warnung angezeigt.

L "STW1" (Word)
T LW0 (Bit0-15)

Gibt es eine Möglichkeit das anders zu lösen?

Viele Grüße
rkoe

 

[Pinky]

Darüber habe ich mich auch schon geärgert. Als Ersatz hat Siemens den Slice-Zugriff eingebaut.
Wenn du jetzt auf die einzelnen Bits in einem Wort zugreifen möchtest kannst du das folgendermaßen:
Deklariertes Wort : #wort
zugriff auf Bit 0 : #wort.%X0
...
zugriff auf Bit 15 : #wort.%x15

 

[rkoe1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank, probier' ich mal aus.

 

[Pinky]

P.S. das geht allerdings nur bei den 1200 und 1500 Steuerungen.

 

[hucki]

Wenn Dir der Slicezugriff nicht weiter hilft, weil Du z.B. über eine Schleife der Reihe nach auf die Bits zugreifen willst, kannst Du auch mit AT Sichten (z.B. ein Array) auf die Eingangsvariablen legen.
Beim FB funktioniert das auch trotz Optimierung. Dazu gibt's schon ettliche Beiträge hier im Forum.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ein Eingangsword in den temp-Bereich in ein LW übertragen und dort die einzelnen Bit's bearbeiten. Im TIA V13 funktioniert das zwar immer noch, wird aber als Warnung angezeigt.

L "STW1" (Word)
T LW0 (Bit0-15)

Wir kennen nun leider nicht den Text Deiner Warnung, doch vielleicht sollst Du nicht absolut (auf undeklarierte?) TEMP-Variablen zugreifen?
Versuche es mal über eine Struktur (ähnlich der AT-Sicht in SCL):
AWL: Word in TEMP-Struktur kopieren und auf Bits zugreifen

Gibt es eine Möglichkeit das anders zu lösen?

Ja gibt es, z.B. per Wordverknüpfung mit Bitmasken, wie es schon "die alten Römer" vollsymbolisch gemacht haben.

Harald

 

[rkoe1]

Hallo PN/DP,

die einzelnen Bit's in dem LW hab' ich normal deklariert. An Wordverknüpfung hab' ich bisher noch nicht gedacht, versuch ich aber mal. Wird aber vom Code etwas mehr wenn ich alle 16 Bits brauche.
Vielen Dank für die Info.

 

[rkoe1]

Hallo Pinky,

muss das leider bei einer 315 einsetzen und hab einige FB's bei denen das so umgesetzt wurde. Ist aber auch nur eine Warnung und die Funktion ist grundsätzlich in Ordnung. Ich hab' nur immer gerne ein "sauberes Projekt".

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hahaha, ja ja, die alten Römer...

Machen wir doch mal ne Liste von dem was für das Thema möglich / sinnvoll ist.

[B][COLOR=#ff0000]S3-300/400[/COLOR][/B]
[B] KOP/FUP/AWL/SCL[/B]
   Kopieren über Adresszugriff (z.B.: LW0 - Nachteil nicht symbolisch)
   Bit-Masken
   Word auf boolStruct kopieren mit BLKMOV
[B] AWL[/B]
   Kopieren über Pointer und Adressregister (Nachteil: Pointer eben)
[B] SCL[/B]
   Word auf boolStruct kopieren mit AT-Sicht 

[COLOR=#ff0000][B]S7-1200/1500[/B][/COLOR]
[B] SCL/FUP/KOP - optimiert[/B]
   Slice - Zugriff
   Bit-Masken
 
[B] SCL/FUP/KOP - nicht optimiert[/B]
   Word auf boolStruct kopieren mit BLKMOV (Nachteil: Legacy) (Normales Move geht nicht)
   Word auf boolStruct kopieren mit AT-Sicht (geht zwar im FB als optimiert aber eben nur dort)

Wenn ich was vergessen hab, bitte melden.

Ich persönlich würde mir im Moment für die 300er 2 kleine FCs schreiben die aus einem INT ein Array of Bool und umgekehrt machen.
Dafür würde ich dann SCL und die AT-Sicht nehmen, oder in KOP/FUP/AWL die Bitmasken. Das kann man dann ich Zukunft auch noch schön auf die 1500 portieren.


Sonst wäre de BLKMOV auch noch OK, der ist zwar in der 1500 ein Legacy-Baustein, aber mal ehrlich, ein 300er-Programm hat normalerweise so viele BLKMOV im Einsatz,
da machen 1 oder 2 mehr auch keinen Unterschied.

 

[de vliegende hollander]

Hallo Rkoe,

Vielleich kann Mann es lösen in dem ein PLC-Datentyp benutz wird.
Zum Beispiel

Anhang anzeigen 28546

Dann hast du im FB alles Symbolisch.

Ich weiß nicht wie der Rest deines Programms ausseht, ob es möglich ist in dein fall. Dann muss im Programm auch immer das PLC-Datentyp verwendet werden.

Bram

 

[PN/DP]

die einzelnen Bit's in dem LW hab' ich normal deklariert.

Das LW0 ist aber nicht deklariert. Darauf schreibst Du ja absolut adressiert - und ohne Rücksicht, ob Deine Ziel-Bits tatsächlich an dieser Adresse liegen. Das ist schon OK so, daß TIA Dir dafür eine Warnung um die Ohren haut

Harald

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das LW0 ist aber nicht deklariert. Darauf schreibst Du ja absolut adressiert - und ohne Rücksicht, ob Deine Ziel-Bits tatsächlich an dieser Adresse liegen. Das ist schon OK so, daß TIA Dir dafür eine Warnung um die Ohren haut

Harald

Das TIA so hartnäckig meckert, kann ich wiederum nicht verstehen, wenn ich als Programmierer
In einen in sich geschlossenen Baustein auf Lokaldaten zugreife, wo ich versichere, das diese nur
für diesen Zweck verwendet werden und ich gewährleisten kann, das an keiner anderen Stelle darauf
zugegriffen wird, warum dann nicht.

Dann soll Siemens erst einmal das TIA Portal zu Ende entwickeln und Möglichkeiten schaffen, außer
SCL und AT-Sicht, Daten umzuladen, um solche aus Siemens Sicht umsaubere Lössungen zu suchen.
In der Classic Welt war es der normale Weg und in der schönen neuen Welt ist es auf einmal verpönt.

Bei einen so starken Umbruch zur Classic Welt währe da mal Zeit und Möglichkeit gewesen, um Automatisieren
in 5 Minuten zu schaffen. Jetzt sucht man Stundenlang nach Lössungen.

 

[PN/DP]

Das TIA so hartnäckig meckert, kann ich wiederum nicht verstehen [...]
In der Classic Welt war es der normale Weg und in der schönen neuen Welt ist es auf einmal verpönt.

Direkt absolut adressiert auf TEMP-Adressen zugreifen war auch schon zu Step7-classic-Zeiten Pfui. Da gab es auch schon Warnungen, wenn man in AWL mit dem FUP/KOP-Compiler ins Gehege kam. TIA warnt jetzt eben immer bei solchen Zugriffen, wohl auch deshalb, weil es dadurch schnell passieren kann, daß im Programm uninitialisierte TEMP-Daten gelesen werden.

Harald

 

[rostiger Nagel]

daß im Programm uninitialisierte TEMP-Daten gelesen werden.

Da ist man doch als ersteller des Programm selber dabei, musst man ja nicht machen.

Ach ja, das Problem initialisierten Daten ist bei 1200/1500 auch kein Problem mehr,
wenn Mann optimiert arbeitet.

Temporäre- und Out-Variablen sind beim Aufruf in nicht optimierten Bausteinen undefiniert. Bei optimierten Bausteinen sind die Werte immer mit dem „Defaultwert“ vorbelegt (S7-1500 und S7-1200 Firmware V4). Dadurch entsteht kein zufälliges Verhalten, sondern ein reproduzierbares Verhalten

 

[Ottmar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi!

*Schnauf*
Man sollte halt einfach nicht vergessen, dass man seinen Programmierstil und die Art Probleme anzugehen, vor langer Zeit auch mal an die Möglichkeiten einer Programmierumgebung angepasst hat.
Das "Lokaldatengeschubse" wird sogar bei kleinen Datenumfängen schon unübersichtlich. Meiner Meinung ist es eine Art zu programmieren, die überholt ist. Meist werden solche Aktionen viel zu oft und unbedacht verwendet.

Die Entwicklungsumgebung eines Automatisierungssystems wie z.B. Siemens-S7 besitzt im Vergleich zu einer Hochsprachen-Umgebung aus definierten Gründen bestimmte Einschränkungen. Die Ablaufsicherheit bei z.B. zur Laufzeit generierten Variablen im Vergleich zu vorab definierten Variablen und Speicheradressen erhöht die Ablaufsicherheit enorm.
Und das ist es worauf es in der Automatisierungstechnik ankommt - sichere, definierte Abläufe. Hier wird auf Hardware zugegriffen und das vergessen viele Programmierer gerne.


Gruß,

Ottmar