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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 19 von 19

Thema: Array füllen

  1. #11
    Registriert seit
    10.04.2005
    Beiträge
    77
    Danke
    55
    Erhielt 7 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hab ich auch schon gelesen. Das würde ja heißen ich muss je Temperatur mit zwei verschiedenen DBs arbeiten!? Mittlerweile hab ich das so umgesetzt wie PN/DP geschrieben hat (mit einem DB) und kurz angetestet. Fehlermeldung gabs keine und rein optisch sieht es auch so aus als ob es geht. Hat jemand andere Erfahrungswerte?
    rot ist blau und plus ist minus

  2. #12
    Registriert seit
    16.12.2008
    Ort
    Fürth
    Beiträge
    146
    Danke
    32
    Erhielt 21 Danke für 19 Beiträge

    Standard

    warum 2 DB's?

    du verschiebst einfach innerhalb eines DB's um eine Zeile

    Also z.B: dein DB 1 hat Array 1..100 of INT

    auf die Adresse DB1.DBW0 soll der "neue" Eintrag, dann musst du vorher die Alten Daten um ein INT nach unten verschieben...

    also 99 -> 100; 98 -> 99; 97 -> 98 usw.

    statt jetzt ne Schleife zu nehmen und das indirekt zu proggen verschiebst du via Blockmove (der Baustein, nicht unser Blockmove ) den ganzen DB um eine Zeile. Also wird DB1.DBW0 zu DB1.DBW2; DB1.DBW2 zu DB1.DBW4 usw..
    -A+B=15=21 Klingt komisch - ist aber so!
    -It's not a bug, it's a feature!
    -Es gibt nur 3 Feinde im Leben eines Programmierers: Sonnenlicht, Frischluft und das unerträgliche Gebrüll der Vögel ...!

  3. Folgender Benutzer sagt Danke zu Befree für den nützlichen Beitrag:

    elmoklemme (24.08.2010)

  4. #13
    Registriert seit
    10.04.2005
    Beiträge
    77
    Danke
    55
    Erhielt 7 Danke für 6 Beiträge

    Standard

    Ja so hab ich das auch gemacht (wie von PN/DP beschrieben) und wie gesagt funktioniert es. Es ging ja um die Aussage, dass sich Quell und Zeilbereich nicht überlappen dürfen (was ja der Fall ist wenn ich in einem DB umkopier!?). Ist da jetzt was dran oder kann ich das schnell wieder vergessen?
    rot ist blau und plus ist minus

  5. #14
    Registriert seit
    16.12.2008
    Ort
    Fürth
    Beiträge
    146
    Danke
    32
    Erhielt 21 Danke für 19 Beiträge

    Standard

    Wenn sich Quelle und Ziel nicht überlappen geht es ja nicht.
    Warum das in der Siemens hilfe steht weiß ich auch nich..
    -A+B=15=21 Klingt komisch - ist aber so!
    -It's not a bug, it's a feature!
    -Es gibt nur 3 Feinde im Leben eines Programmierers: Sonnenlicht, Frischluft und das unerträgliche Gebrüll der Vögel ...!

  6. #15
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Also ich hatt's auch schon mal an einer CPU probiert und da hat es nicht funktioniert! Weiss aber auch nicht mehr was das für eine war!

    Ich denke halt wenn man es macht, kann man sich nicht sicher sein, das es mit einer neuen CPU auch noch funktioniert!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    Zitieren Zitieren so...  

  7. #16
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.190
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von Befree Beitrag anzeigen
    dann musst du vorher die Alten Daten um ein INT nach unten verschieben...

    also 99 -> 100; 98 -> 99; 97 -> 98 usw.

    statt jetzt ne Schleife zu nehmen und das indirekt zu proggen verschiebst du via Blockmove [...]
    Also wird DB1.DBW0 zu DB1.DBW2; DB1.DBW2 zu DB1.DBW4 usw..
    Genau dieses NACH HINTEN verschieben funktioniert NICHT mit dem SFC20 "BLKMOV", deshalb schreibt
    wohl Siemens abschreckend, daß sich Quell- und Zielfeld (generell) nicht überlappen dürften.

    Da der SFC20 auf allen mir bekannten S7-CPU immer aufsteigend kopiert (steht auch so in der SFC20-
    Beschreibung) und ich davon ausgehe, daß er höchstens 32 Bit (= 4 Byte) auf einmal transferiert,
    sehe ich keine Probleme darin, den SFC20 auch für überlappende Speicherbereiche einzusetzen, wenn
    die Zieladresse mindestens 4 Byte VOR der Quelladresse ist.
    (man könnte dazu ja ein schönes Bildchen mit Pfeilen und vorher/nachher malen)
    Wahrscheinlich spielt der Abstand gar keine Rolle, hauptsache die Zieladresse ist nicht hinter der
    Quelladresse (könnte man ja mal testen).

    Jedenfalls funktioniert dieses überlappende nach-Vorn-Kopieren bisher auf allen S7-300/400-CPU, wo
    ich es so eingesetzt habe. Der SFC20 führt den überlappenden Kopierauftrag ohne Fehlerstatus aus.
    Der SFC20 führt vor dem Kopieren so viele Parameterprüfungen aus, wieso lehnt er das überlappende
    Kopieren aber nicht ab?!

    Es kann bei neuen CPU oder beim nächsten Firmware-Update natürlich sein, daß das überlappende
    Kopieren nicht mehr wie erwartet funktioniert. Siemens hat ja ohne Einschränkung geschrieben:
    "Quell- und Zielfeld dürfen sich nicht überlappen".
    Das wird man dann aber sehr schnell mitbekommen und muß sich eben was anderes "schnelles" einfallen
    lassen. Doch wenn es auf einer CPU einmal funktioniert, dann wird es ohne Firmware-Update auch immer
    funktionieren.

    Ich könnte mir vorstellen, daß die Längenangabe des Any-Pointers sogar bestimmt, wie der SFC20 kopiert
    - P#DB1.DBX0.0 BYTE 12 -> byte-weise
    - P#DB1.DBX0.0 WORD 6 -> word-weise
    - P#DB1.DBX0.0 DWORD 3 -> doppelword-weise
    weiß aber im Moment nicht, wie ich das testen/nachweisen kann.

    Im übrigen ist es gerade bei Produkten für Siemens-PLC gang und gäbe, von Siemens nicht dokumentierte
    und nicht garantierte Funktionen angstfrei zu nutzen und auch unwissenden Anwendern als "funktionierend"
    anzubieten. Außer Chemie-Katastrophen und Tod von Menschen kann ja nichts schlimmeres dabei passieren.

    Mein überlappendes Kopieren mit dem SFC20 ist wenigstens von mir getestet und ich gehe davon aus, wer
    das nachmacht, wird sich auch mindestens einmal von der korrekten Funktion überzeugen.

    Wer sich nun nicht mehr traut, mit dem SFC20 überlappend zu kopieren, der kann ja auch zweimal kopieren,
    wie hier von vierlagig vorgeschlagen: http://www.sps-forum.de/showthread.php?p=222991
    Das sollte immer noch schneller als eine indirekte Kopierschleife sein.

    Gruß
    Harald

  8. Folgende 2 Benutzer sagen Danke zu PN/DP für den nützlichen Beitrag:

    elmoklemme (24.08.2010),Jochen Kühner (24.08.2010)

  9. #17
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Danke, man lernt nie aus...

    Ist das auch in PLCSim getestet?

    Läuft das so auch auf Vipa CPUs?
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  10. #18
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.190
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von Jochen Kühner Beitrag anzeigen
    Ist das auch in PLCSim getestet?
    Ja, selbstverständlich. Und funktioniert auch korrekt.

    Zitat Zitat von Jochen Kühner Beitrag anzeigen
    Läuft das so auch auf Vipa CPUs?
    Habe ich nicht getestet, ich habe erst einmal mit VIPA-CPU gearbeitet.
    Ich meine aber, daß das überlappende Kopieren auch da funktionieren wird, wenn der SFC20 auch da immer aufsteigend arbeitet.
    Wenn VIPA kompatibel zu Siemens sein will, dann muß es da auch funktionieren.

    Was dokumentiert Siemens zum SFC20 "BLKMOV" ?

    System- und Standardfunktionen für S7-300/400 Band 1 und Band 2 (05/2010)
    Seite 97, Kapitel 3.1 Speicherbereich kopieren mit der SFC 20 "BLKMOV"

    3 Aussagen:
    1. Quell- und Zielfeld dürfen sich nicht überlappen. (ohne weitere Erläuterungen oder Einschränkungen)
    2. Das Kopieren erfolgt in Richtung aufsteigender Adressen
    3. Beachten Sie, dass während der Bearbeitung der SFC 20 "BLKMOV" die Quelldaten unverändert bleiben.
      Andernfalls ist die Konsistenz der Zieldaten nicht gewährleistet.


    zu 3.) Diese Aussage betrifft eigentlich die Unterbrechbarkeit des SFC20 durch OB. Der Quellbereich wird also nicht
    gesperrt oder gesichert. Schreiben in den Quellbereich während der SFC20-Bearbeitung ist eindeutig möglich.

    zu 1.) Die erste Aussage halte ich einfach für ungenau. Vielleicht hat der Dokumentationsschreiber einfach keine Lust
    gehabt zu beschreiben, unter welchen speziellen Bedingungen diese Aussage gilt und welche Ausnahmen zulässig sind.
    Der SFC20 läßt jedenfalls das "verbotene" überlappende Kopieren ohne Fehlerstatus zu und führt es korrekt aus.

    zu 2.) Die zweite Aussage dagegen lege ich nun streng aus:
    Das Kopieren erfolgt strikt in Richtung aufsteigender Adressen.
    Nach dem Kopieren eines Elements egal welcher Zugriffsbreite wird ein Element von einer höheren Adresse kopiert, niemals
    ein Element von einer niedrigeren Adresse als ein vorheriger Kopiervorgang. Damit nun garantiert jedes Element immer in
    aufsteigender Folge kopiert wird, muß nach dem Kopieren eines Elements genau das nächste Element kopiert werden. Würde
    dabei eine Lücke gelassen, müßte irgendwann auch diese Lücke kopiert werden, was aber der Aussage mit der aufsteigenden
    Arbeitsweise widerspricht. Wenn ich nun noch unterstelle, daß sinnvollerweise kein Byte zweimal kopiert wird, dann muß
    der SFC20 in etwa so arbeiten:

    for i=1 to elementanzahl ; ziel[i] = quelle[i] ; i=i+1 ; next

    (das kann auch ein einzelner komplexer Prozessorbefehl sein wie REP MOVSB bei 80x86)

    Der ganze Vorgang ist so auch logisch und entspricht allen meinen Erfahrungen mit verschiedenen Programmiersprachen und
    Prozessoren. Ich kann mir nicht vorstellen, was für einen völlig anderen Algorithmus die CPU-Firmware-Programmierer da
    angewendet haben könnten, der überlappende Bereiche tatsächlich generell verbieten würde.

    Wenn aber - wie gezeigt - der SFC20 in einer Schleife die einzelnen Elemente eines Quellbereichs in einen Zielbereich
    umkopiert (ohne Lücken und ohne mehrfach kopieren), dann finde ich keinen Grund dafür, daß die Bereiche sich nicht
    überlappen dürfen, solange die Zieladresse kleiner oder gleich der Quelladresse ist. Es muß ja nur sichergestellt sein,
    daß kein Element überschrieben wird, was noch nicht kopiert wurde. Und das ist der Grund, weshalb ein aufsteigendes
    Kopieren mit Zieladresse größer Quelladresse ("nach hinten") bei überlappenden Bereichen nicht korrekt funktioniert.
    Und wegen dieser speziellen Einschränkung schreibt Siemens halt einfach, daß die Bereiche sich nicht überlappen dürfen...

    Interessanterweise erwähnt Siemens bei den vergleichbaren Bereichs-Übertragungsbefehlen der S7-200 (BMB/BMW/BMD/BLKMOVE)
    nicht diese speziellen Bedingungen für überlappende Bereiche. Es gibt gar keine Einschränkungen. Jeder Programmierer muß
    selbst drauf kommen, was geht und was geht (logischerweise) nicht.

    Ich behaupte, daß der SFC20 immer erfolgreich kopiert, wenn diese Bedingungen eingehalten werden:
    1. der Zielbereich muß größer oder gleich groß wie der Quellbereich sein
    2. und beide Bereiche müssen physikalisch komplett vorhanden und für den SFC20 zulässig sein
    und
    3a. die Zielbereichsadresse ist kleiner oder gleich Quellbereichsadresse
    3b. oder Zielbereichsadresse ist größer Quellbereichs-Endadresse
    3c. oder der zielbereich ist ein völlig anderer Speicherbereich als der Quellbereich (anderer DB oder TEMP oder Merker ...)
    und
    4. spezielle Bedingungen für BOOL und STRING siehe SFC20-Beschreibung

    Ich bin sehr zuversichtlich, daß das von mir verwendete überlappende Kopieren mit dem SFC20 auch in Zukunft immer korrekt
    funktionieren wird, solange Siemens die Zusage der aufsteigenden Arbeitsweise einhält.

    Gruß
    Harald

  11. #19
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Nur zur Info:

    Habs auf einer Vipa Speed 7 getestet, läuft dort auch!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    Zitieren Zitieren Vipa...  

  12. Folgender Benutzer sagt Danke zu Jochen Kühner für den nützlichen Beitrag:

    PN/DP (31.08.2010)

Ähnliche Themen

  1. Mit Schleife DB füllen
    Von htw im Forum Simatic
    Antworten: 59
    Letzter Beitrag: 23.05.2011, 18:29
  2. DB Füllen
    Von SPS_NEU im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 16.08.2010, 16:25
  3. Array mit berechneten Werten füllen
    Von Yogixxx im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 12.05.2010, 13:35
  4. Kreis füllen
    Von doretan im Forum HMI
    Antworten: 1
    Letzter Beitrag: 21.06.2009, 23:51
  5. Array indirekt füllen
    Von Woto im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 11.05.2009, 19:40

Lesezeichen

Berechtigungen

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