Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 8 von 8

Thema: DB Bereichsabfrage

  1. #1
    Registriert seit
    28.10.2010
    Ort
    36205 Sontra
    Beiträge
    111
    Danke
    14
    Erhielt 5 Danke für 5 Beiträge

    Standard


    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.
    Zitieren Zitieren DB Bereichsabfrage  

  2. #2
    Registriert seit
    26.05.2009
    Beiträge
    541
    Danke
    35
    Erhielt 78 Danke für 69 Beiträge

    Standard

    Zitat Zitat von kliebisch.m Beitrag anzeigen
    ...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
    Wenn du denkst du denkst, dann denkst du nur, dass du denkst, denn beim Denken der Gedanken, kommt dir der Gedanke, dass das Denken der Gedanken ein gedankenloses Denken ist

  3. #3
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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

  4. #4
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.713
    Danke
    443
    Erhielt 914 Danke für 739 Beiträge

    Standard

    Da stellt sich mir die Frage, wie es sich da mit der AT-Sicht in SCL verhält?

  5. #5
    Registriert seit
    05.04.2012
    Beiträge
    949
    Danke
    94
    Erhielt 215 Danke für 190 Beiträge

    Standard

    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.

  6. #6
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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/autom...4sentation.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.

    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
    Geändert von HelleBarde (29.10.2013 um 23:13 Uhr)

  7. #7
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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
    Geändert von HelleBarde (29.10.2013 um 23:15 Uhr)

  8. Folgender Benutzer sagt Danke zu HelleBarde für den nützlichen Beitrag:

    kliebisch.m (30.10.2013)

  9. #8
    kliebisch.m ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    28.10.2010
    Ort
    36205 Sontra
    Beiträge
    111
    Danke
    14
    Erhielt 5 Danke für 5 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •