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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: BLKMOV mit großen Datenmengen

  1. #1
    Registriert seit
    01.12.2004
    Beiträge
    18
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo NG!


    Ich habe da mal eine Frage zu BLKMOV bezüglich der maximalen Datenmenge die sich kopieren lässt.


    Wenn ich BLKMOV beispielsweise mit P#DB110.DBX0.0 BYTE 2 als Quelle und P#DB120.DBX0.0 BYTE 2 als Ziel angebe sollte dies Problemlos möglich sein.
    CALL "BLKMOV"
    SRCBLK :=P#DB110.DBX 0.0 BYTE 2
    RET_VAL:=#iReturn
    DSTBLK :=P#DB120.DBX 0.0 BYTE 2
    Was aber passiert, wenn ich wirklich viel Daten kopiere. Beispielsweise etwas wie: P#DB110.DBX0.0 BYTE 200 als Quelle und P#DB120.DBX0.0 BYTE 200 als Ziel.
    CALL "BLKMOV"
    SRCBLK :=P#DB110.DBX 0.0 BYTE 200
    RET_VAL:=#iReturn
    DSTBLK :=P#DB120.DBX 0.0 BYTE 200
    Die Funktion ist meines Wissens nach nicht asynchron, oder? In dem Cycle wo ich einen großen Kopiervorgang anstoße blockiere ich dann u.U. die CPU bzw. es führt dazu, dass sie sogar ganz aussteigt, oder? Gibt es eine asynchrone Möglichkeit größere Datenmenge von Baustein A zu Baustein B zu kopiere ohne die Daten zu zerlegen und in einer Schleife beispielsweise immer nur 4 BYTE zu kopieren?


    Fragend und Danken für eure Hilfe,
    Thommy
    Geändert von thommymalta (31.08.2006 um 01:49 Uhr)
    Zitieren Zitieren BLKMOV mit großen Datenmengen  

  2. #2
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard

    Hallo thommymalta,

    synchron oder asynchron ist doch hier nicht die Frage, oder? Von Interesse ist doch nur, ob die Funktion BlockMove z.B. durch einen Interrupt unterbrechbar ist...
    Und wenn Du meinst, 200 Bytes (wie in Deinem Beispiel angegeben) wären eine grosse Datenmenge, naja

    Vielleicht einfach mal ausprobieren, das klappt schon

    Gruss

    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren Datenschubsen  

  3. #3
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard

    Hallo,

    Zitat Zitat von thommymalta
    In dem Cycle wo ich einen großen Kopiervorgang anstoße blockiere ich dann u.U. die CPU bzw. es führt dazu, dass sie sogar ganz aussteigt, oder?
    Nur wenn die max. Zykluszeit überschritten wird. Ansonsten denke mal über die Arbeitsweise einer SPS nach ...

    Gruss

    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)

  4. #4
    Registriert seit
    24.09.2003
    Beiträge
    122
    Danke
    0
    Erhielt 8 Danke für 7 Beiträge

    Standard

    Hallo Thommy,
    da die Bytes ja innerhalb des Arbeitsspeichers kopiert
    werden, geht das ziemlich schnell:

    CPU312: 90 micro + 2 micro / byte

    CPU31x: 75 micro + 1,6micro / byte

    CPU317: 16 micro + 0,05 micro / byte !

    Wenn man also selbst mit der kleinen 312 tausend Byte kopiert,
    dauert das 2090 microsec. oder knapp 2,1 ms.

    Die 317 braucht für 16000 Byte 816 micro / 0,8 ms.
    Im 'Normalfall' wirst du deine CPU mit BLKMOV nicht blockieren.

    mfg.
    Rolf

  5. #5
    thommymalta ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    01.12.2004
    Beiträge
    18
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo Question_mark!
    Zitat Zitat von Question_mark Beitrag anzeigen
    synchron oder asynchron ist doch hier nicht die Frage, oder?
    Doch, oder habe ich etwas falsch verstanden? Wenn ich z.B. mit SFC 83 "READ_DBL" Daten aus dem [load memory (Micro Memory Card)] lese, bekomme ich am [BUSY OUTPUT] mitgeteilt, ob der Lesevorgang abgeschlossen ist. Nun habe ich mich halt gefragt, was passiert wenn man etwas meeehr Daten mit BLKMOV ließt und ob es da ein Limit gibt.

    Die Funktion ist wohl synchron denke ich. Die CPU geht also in STOP wenn meine vordefinierte maximale [Scan Cycle Monitoring Time] überschritten wird oder ich habe beim sporadischen Lesen größerer Datenmenge sprunghaft ansteigende Zykluszeiten. Bei Zeit sensitiven Applikationen kann das doch zu unerwünschten Effekten führen, oder?

    Zitat Zitat von Question_mark Beitrag anzeigen
    ... die Funktion BlockMove z.B. durch einen Interrupt unterbrechbar ist...
    Wie genau muss ich mir das vorstellen? Du meinst wenn die CPU auf Grund einer Zykluszeitüberschreitung in STOP geht? Bin mir nicht sicher was du hier meinst.

    Dank schon einmal für die schnelle Antwort!

  6. #6
    Registriert seit
    25.01.2012
    Ort
    Schwarzwald
    Beiträge
    9
    Danke
    2
    Erhielt 3 Danke für 3 Beiträge

    Standard

    Hallo thommymalta

    ich habe mit BLK_MOV schon 8000 DW verschoben und hab dann eben in diesem einen Zyklus eine kurze Zykluszeiterhöhung, was sich aber auf die allgemeine Bearbeitung meines SPS-Programmes nicht wirklich auswirkt. Da gibt es bei Schleifen schon mal mehr Zykluszeit zusammen.
    Wie schnell muss denn dein Zyklus sein? <10ms, <1ms?

    Grüße Billhearts
    Kaum macht man's richtig - schon geht's!

    www.sommerzeitende.de

  7. #7
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.186
    Danke
    923
    Erhielt 3.291 Danke für 2.660 Beiträge

    Standard

    Hallo Billhearts,

    8000 DW auf einer 31x kopieren war vor 9 Jahren durchaus ein Problem, da war man schon froh, wenn man mit der Zykluszeit unter 50ms blieb...

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  8. #8
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard

    Hat wer eine Idee wie lange es ungefähr dauert 2160 Real Zahlen, also 8640 Bytes zu kopieren?
    CPU ist eine 416-3.

    Die zweite, für mich wichtigere Frage ist, wieviele Bytes kopiert der BLKMOVE pro Zyklus.
    Hintergrund der Frage: der Baustein wird im PCS7 eingebaut. Alle, sagen wir mal 10s kommt ein neuer Wert, dann sollte der BLKMOVE fertig sein. Wenn der Baustein nun alle 1s aufgerufen wird bleiben 10 Zyklen für die Abarbeitung.

    PS: klar, ich probier es eh aus. Es macht mich stutzig, dass der UBLKMOVE nur 512 Byte kann. Wann das auch die Kachelgröße des BLKMOVE ist, geht sich das NICHT aus.

    Gruß
    Karl

  9. #9
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    776
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Bei der 416 dürfte das kopieren von 10000 Bytes maximal 2ms dauern.
    Ich kopier in den 400ern soviel mit Blkmove das sind nicht die Zykluszeiterhöher


    mfG René

  10. Folgender Benutzer sagt Danke zu vollmi für den nützlichen Beitrag:

    borromeus (30.11.2015)

  11. #10
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Und hast Du eine Ahnung wieviele Zyklen der braucht?

Ähnliche Themen

  1. Größere Datenmengen aufzeichnen?
    Von logo78 im Forum Hochsprachen - OPC
    Antworten: 6
    Letzter Beitrag: 11.02.2010, 11:04
  2. Ich hab vom großen S die schnauze voll
    Von stift im Forum Stammtisch
    Antworten: 38
    Letzter Beitrag: 07.02.2010, 20:05
  3. Multiplexen von Datenmengen
    Von Riba im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 21.10.2008, 10:20
  4. Großen FB in 2 Teile splitten - knifflig.
    Von rs-plc-aa im Forum Simatic
    Antworten: 51
    Letzter Beitrag: 11.11.2007, 21:26
  5. Große Datenmengen nach WinCC flexible
    Von Markus im Forum HMI
    Antworten: 2
    Letzter Beitrag: 18.01.2007, 10:46

Lesezeichen

Berechtigungen

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