TIA DB Bereichsabfrage

kliebisch.m

Level-1
Beiträge
120
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, ich habe einen DB mit 32 Bool und will in AWL (mit L DBxx.DBD0) abfragen, ob einer der Bools auf 1 ist. TIA gibt dafür eine Warnung aus, wenn ich auf den DBD zugreife. Kann ich es einstellen oder gibt es einen anderen Weg, dass mir TIA12 keinen Fahler mehr ausgibt? Herzlichen Dank.
 
...TIA gibt dafür eine Warnung aus, wenn ich auf den DBD zugreife
...dass mir TIA12 keinen Fahler mehr ausgibt? Herzlichen Dank.

Was denn nun? Fehler oder Warnung?
Die Warnung ist da, weil du nicht vollsymbolisch darauf zugreifst.
TIA will alles vollsymbolich haben.
Aber ne Warnung kann man unter Umständen auch ignorieren.

Ein Fehler wäre schlimmer...

Gruß wolder
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

welche CPU Familie möchtest du denn?
Bei einer 300/400 kann man ganz einfach abfragen ob DBx.DBDy <> 0 ist, denn eine DINT#0 hat man ja nur dann, wenn alle bits Null sind. Das kann man in allen fünf Sprachen ohne Aufstand hinbekommen. Und dann hat das Portal auch nix zu meckern, denn wenn du auf dein DBx.DBDy eine Varaible gelegt hast, dann ist ja alles symbolisch.

Bei einer 1200/1500 ist das nicht so einfach. Ist dein DBx standard, dann geht es so wie bei 300/400. Dafür wirst du aber mit deutlich langsameren Bitzugriffen belohnt. In irgendeinem Thread habe ich schon mal meine Messergebnisse dargestellt. Fazit: Lesen dauert 3 mal so lange und schreiben dauert 6 mal solange wie bei einem optimierten Baustein.
Bei einem optimierten Baustein, kann man nicht mit DBx.DBDy zugreifen. Da muss man jedes Bit einzeln adressieren. Das ist bei weitem nicht so schlecht wie es sich auf den ersten Blick anhört.

Es kommt drauf an, was in deinem Programm überwiegt. Wenn jemand 32 Bools deklariert, dann sollte man meinen er braucht auch 32 Bools.
Nehmen wir mal ein der Zugriff dauert einen Takt -- es ist völlig egal wieviele µs so ein Takt dauert.
32 Bools schreiben und 32 Bools lesen dauert in einem optimierten Baustein 64 Takte. Un zusätzlich willst du die 32 Bools auf Null vergleichen, das sind nochmals 32 Zugriffe und 32 or in SCL oder Kontakte in KOP oder ein OR mit 32 inputs in FUP. Das dauert 32 Takte :) macht zusammen 96 Takte bei einem optimierten Baustein.
Jetzt kommen die AWL Trickser und schalten den Baustein auf standard. Damit verlangsamen sich alle Zugriffe. Für den Vergleich muss man nur einmal Lesen. Das Lesen eines Standard-DWORD dauert bei der 1500 etwa 8 mal so lange wie das eines optimierten DWORD (hat mir RUNTIME verraten). Wie lange der Vergleich selbst dauert ... keine Ahnung, sagen wir mal einen Takt. Bei der 1200 scheint es keinen so großen Unterschied zu machen, aber es macht einen.

Dann haben wir zusammen: Schreiben 6 * 32 + Lesen 3 * 32 + Vergleich 8+1 = 297 Takte.

Oops das ist deutlich langsamer als bei optimierten DB mit nur 96 Takten! Und ich gehe davon aus, dass man mehr als 3 Zugriffe im Zyklus hat.


Was lerne ich daraus? Die Trickserei mit AWL ist schlecht für die Performance. All das Wissen der letzten 10 Jahre mit Step7 V3 bis V5 -- all die tollen Tricks im Berger Buch -- für die Katz. Für AWL Programmierer brechen schlechte Zeiten an.

'n schönen Tach auch
HB
 
Helle Barde
Bei einer 1200/1500 ist das nicht so einfach. Ist dein DBx standard, dann geht es so wie bei 300/400. Dafür wirst du aber mit deutlich langsameren Bitzugriffen belohnt

... hast Du das zufällig mal mit der von SIEMENS angegebenen äquivalenten S7-300 zur S7-1500 verglichen? Meine Erwartungshaltung wäre eigentlich, dass das alte Programm auf der neuen äquivalenten Steuerung gleich schnell läuft (ich brauche ja nicht zwingend mit optimierten Bausteinen arbeiten). Wenn ich dann auf optimierte Bausteine wechsle, dann läuft natürlich mein Programm schneller - siehe auch Programmierleitfaden für die S7-1x00.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi zako

auf der 300 gibt es keinen RUNTIME, da kann man so schlecht einzelne Befehle nachmessen.

Wenn man die Zykluszeiten von einigermaßen großen Programmen vergleicht, dann stimmt die Aussage in
http://www.siemens.de/industry/auto...emens_InnovationTour_2013-02_Präsentation.pdf schon. Aber für einzelne Befehle, ist es ohne RUNTIME praktisch unmöglich was nachvollziehbares zu messen.

Die Frage danach ob
das alte Programm auf der neuen äquivalenten Steuerung gleich schnell läuft
muss ich frei nach Radio Eriwan mit "Im Prinzip ja" beantworten. Aber im Einzelfall muss ich leider ein deutliches NEIN heraus brüllen. Insbesonders Spielereien mit ANY Pointern und Adressregistern sind spürbar langsam. Ein AWL lastiges Programm mit handgedengelten Arrayzugriffen hat auf der 1516 größere Zykluszeiten als auf der 317. Ein SCL lastiges Programm welches ja schon immer Arrayzugriffe mit indirektem Index hatte, hat auf der 1516 kürzere Zykluszeiten als auf der 317. KOP und FUP laufen auf der 1516 auch schneller als auf der 317. Nur gibt es auf der 317 keine Arrayzugriffe mit indirektem Index in KOP/FUP. Auf der 1500 geht das in allen Sprachen :) Danke S. :sad:

Baut man nun das AWL Programm um, also da wo man bisher mittels Adressregister ein array[#index] nachgebastelt hatte schreibt man nun einfach array[#index], dann wird das AWL Programm so schnell wie das SCL Programm. Und damit schneller als auf der 317.

Worauf es mir ankommt, ist klar zu machen, dass es sich lohnt die alten Programme auf die neue Welt anzupassen. Für das gleiche Geld bekommst du mehr Performance. Ich muss keine 1516 kaufen, weil die 1513 reichen kann. Sicher muss das der Einzelfall entscheiden. Wenn das Programm so fett ist, dass es nicht in Speicher passt, dann muss halt doch 'ne 1516 her. Aber im Maschinenbau sind die Programme oft gar nicht so groß, dafür muss die Zykluszeit kurz sein. Und wenn es mir gelingt durch Programmanpassung auf der 1511 den geforderten Zyklus her zu bekommen, dann habe ich für meinen Chef schon bei der zweiten verkauften Presse Geld reingeholt.

Wenn ich ein Auto mit 5 Gängen kaufe, dann will ich eben nicht nur im ersten und zweiten fahren.

'n schönen Tach auch
HB
 
Zuletzt bearbeitet:
Hi hucki

das AT ... au weh. Die Sichten auf das AT sind schlecht. Als Lehrer würde man sagen ungenügend.

Ich habe es noch nie gemocht und jetzt mag ich es noch weniger.

Wofür kann man das brauchen? Erstens um in SCL mit dem ANY zu hantieren. Zweitens um Speicher zu sparen. Drittens um Daten für TSEND/TRCV vor/nach zu bereiten.

Gegen 1) Das Gehampel mit dem ANY kann man sich auf der 1500/1200 schenken. Statt umständlich mit dem SFC20 zu kopieren, macht das in vielen Fällen einfach der MOVE in KOP/FUP bzw ein := in SCL. Das scheint S auch gemerkt zu haben und stellt alles auf das misteriöse VARIANT um. Aber zu dem hat man ja gleich noch weniger Zugriff.
Gegen 2) Man missbrauche einen FB mit AT um in dessen Instanz zum Zeitpunkt A den UDT X und zum Zeitpunkt B den UDT Y zu merken. Hoffentlich hat der Kollege das ausführlichst dokumentiert. Solche Stunts kosteten mich Wochen der Fehlersuche. ... Gut dass Vergewaltigung strafbar ist.
Gegen 3) Das klappt auch nur bedingt. Das Gerät von dem die Daten kommen könnte die Bytes in der falschen Reihenfolge haben. Statt wie S. fordert, mit den höherwertigen Bytes zuerst, halt so wie die µ-Controller aus dem Hause Intel mit den niederwertigen Bytes zuerst. Blöd dass es in SCL kein TAW gibt. Und dann liegt das REAL auch noch auf Byte 3. Nö, nö, dafür taugt das AT auch nicht.

Also AT geht nur da, wo du mit den langsamen Zugriffen hantierst. Es leistete in der Vergangenheit nur in 10% der gewünschten Anwendungen das was ich mir erhofft hatte. Ich habe es schon zu Step7 V5 nur für die Anwendung 1 benutzt und das ist weniger nötig denn je zuvor.

Statt dem AT möchte ich im Nachfolger von V12 schnelle Funktionen die es mir ermöglichen aus einem Array of BYTE ein REAL mit von mir spezifizierter Bytefolge zu lesen. Großer S, höre mein Flehen.

'ne schönen Tach auch
HB
 
Zuletzt bearbeitet:
Hallo und vielen Dank der Antworten,

leider ist es immer noch so, dass Siemens schon in ihrer "neuen TIA Welt" lebt, aber es stockt mit der neuen 1500er SPS in "Sachen Safety".
Somit kann ich für unsere Anwendungen die 1500 NICHT einsetzen und warte noch 10 Jahre, bis Siemens soweit ist.

Ich habe jetzt mitbekommen, dass das ein wenig anders ist in der "neuen Welt".
Ich muss nun schauen, wie ich die alten Programme hinbiege, dass diese mit neuen Displays und alter 300er SPS laufen.

Vielen Dank an alle.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo..
inzwischen schreiben wir das jahr 2020 und ich hab auch das Problem...
wir hatten ein V5.6 Version mit S7-300 und die neue Maschine bekommt eine 1513 CPU , habe alles migriert..
also Programm V5.6 auf V15.1 und CPU von 300 auf 1500
aber DB8.DBD4 <> 0 funktioniert nicht... Tia bringt ne Warnung beim Übersetzen.

TIA bringt folgende Warnung:
Netzwerk 46,Die Adresse wird nicht durch eine Variable belegt.,,,10:33:57



DB8.DBX0.0,
DB8.DBX1.0, DB8.DBX3.1, DB8.DBX4.0, DB8.DBX4.1, DB8.DBX4.2 usw usw sind einzelne Text Stör-Meldungen für das Display.

DB8.DBD0 <> 0 oder DB8.DBD4 <> 0 wurde bei uns genutzt um zu erkennen ob irgendwo eine Störmeldung ausgelöst wurde (= Meldung einer Störlampe)
nur bei 0 ist alles okay.

Habt ihr da inzwischen was Brauchbares zum Umsetzen?


stoerung-1.JPG


Oder kann ich die Warnung später einfach ignorieren und es wird funktionieren?

 
Zuletzt bearbeitet:
Moin,
eine Warnung ist eine Warnung und kann somit ignoriert werden. Aber ich kann dir nur dringend empfehlen nicht nur deine SPS ins neue Jahrtausend zu befördern, sondern auch den gesamten Code drauf ;)
Deine Bitmeldungen sind doch laut Bild ein Array - da könntest du also in einer Schleife überprüfen ob ein Bit gesetzt ist. Oder mit der Funktion Gather das Bit-Array in ein Word schieben und dann das Word wieder auf <>0 prüfen. Viele Wege führen nach Rom (außer es ist Corona :ROFLMAO: )
 
Worauf es mir ankommt, ist klar zu machen, dass es sich lohnt die alten Programme auf die neue Welt anzupassen.
Ich sehe das auch so.
Bis jetzt konnte ich mich erfolgreich gegen direkte (ohne Anpassungen) Konvertierungen 300->1500 wehren.
KOP/FUP und SCL lassen sich recht einfach konvertieren/nachprogrammieren.
Und längere AWL-Haufen sind es sowieso wert, sie neu zu programmieren.
Spätestens wenn es daran geht, den konvertierten Code auch in Betrieb zu nehmen, sollte man auch verstehen, was genau in dem AWL-Programm passiert - und dann kann man es mit verhältnismäßig wenig Aufwand auch gleich in SCL neu schreiben.
Und die Performance einer nach neuen "Regeln" programmierten 1500er übertrifft eine gleichwertige 300er locker.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke dir,
das muss ich mir mal genauer überlegen wie du das meinst mit der Schleife, es soll alles in FUP bleiben, würde das gehen?
AWL wäre auch noch okay..
Wenn ihr mir da weiter helfen, würde ich euch danken ;)

leider soll das ganze im März noch fertig sein, deshalb wollte und kann ich nur das nötigste anpassen..
Die Chefs dachten ja eher so:
altes projekt > umwandeln -> reinladen - läuft.. :rolleyes:
 
Danke dir,
das muss ich mir mal genauer überlegen wie du das meinst mit der Schleife, es soll alles in FUP bleiben, würde das gehen?
AWL wäre auch noch okay..
Wenn ihr mir da weiter helfen, würde ich euch danken ;)

leider soll das ganze im März noch fertig sein, deshalb wollte und kann ich nur das nötigste anpassen..
Die Chefs dachten ja eher so:
altes projekt > umwandeln -> reinladen - läuft.. :rolleyes:
Schleife wäre SCL - geht aber prinzipiell auch in FUP (würde ich aber nicht empfehlen). Dann schnapp dir mal den Gather-Baustein aus den Vorlagen (Anweisungen -> einfache Anweisungen -> Verschieben). Der kann dir aus einem Bit-Array ein Word oder DWord machen. Das kannst du dann wieder auf <> 0 prüfen.
 
danke
den Gather Baustein hab ich eben gefunden..
brauch ich den Gather normal oder den Gather BLK?

Hättest mal nen screenshot wie das aussehen würde am Ende?
 
Zuletzt bearbeitet:
danke
das war ich eben am lesen ;)

Bin leider noch nicht so fit in TIA,
hab die Hilfe gesehen..
wie lege ich denn in TIA den array of bool für meine DB8.dbd0 und db8.dbd4 an?

Wahrscheinlich dämliche Fragen.. :cry:

hab das jetzt so gemacht im DB8

meldungen_array.JPG
aber ist wohl auch falsch?

wenn ich aber dann Meldungen_1 bei IN eingebe, wird ein Fehler von TIA angezeigt.


und wenn ich es so mache kommt auch Fehler:

melde-arry2.JPG
wobei ich hier nicht weiss wie ich dann die Einzelbits von DB8.DBD0 usw zuweisen soll
 
Zuletzt bearbeitet:
Eine Möglichkeit (je nachdem, wie auf die einzelnen Bits zugegriffen werden soll und ob "sprechende" Namen gewünscht sind) wäre auch ein Doppelwort anzulegen und auf die einzelnen Bits via Slice-Zugriff zuzugreifen.
Also:
MeinDoppelwort.X0 - X31
 
Zuviel Werbung?
-> Hier kostenlos registrieren
also hier in Rot:
Bit-Array.JPG
sind deine Meldungen doch schon in einem Array - oder nicht???
Du musst bei den ??? im Gather mal Word auswählen, dann sollte er den In so schlucken.
 
Zurück
Oben