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

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

Thema: Komplizierte Frage zu BLKMOV oder wie oft darf ich den pro Zyklus aufrufen

  1. #1
    Registriert seit
    05.11.2004
    Ort
    Schweiz
    Beiträge
    1.138
    Danke
    225
    Erhielt 127 Danke für 85 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo....

    Ich hab hier ein Phänomen, das ich irgendwie nicht mir erklären kann.
    Kurze Info:

    Anlage hat 19 Stationen. In jeder Station soll ein Arbeitsschritt jeweils zum Typ abgearbietet werden. Der Typ wird in der 1. Station festgelegt.
    Jeder Typ hat aber nochmal 2-3 Untertypen.

    Damit ich in jeder Station weiß, was ich machen muss, hab ich mir einen UDT erstellt, der alle Informationen beinhaltet und ihn in einem DB 19 mal programmiert.

    Nun kann ich ja in dem DB von UDT 1 sozusagen (also Speicherplatz der 1. Station mit den Informationen von allen Stationen, was in welcher gemacht wird) nach UDT 2 (2. Station) schieben.
    Sagen wir UDT 1 im DB fängt bei P#DB20.DBX0.0 Byte 76 an und UDT 2 bei P#DB20.DBX80.0 Byte 76 (1 DW reserve).

    Damit ich beim transverieren der Daten zwischen den Stationen keinen Verlust habe, habe ich eine exakte Kopie des DBs in einen Transport-DB kopiert. Die Struktur ist somit die gleiche.

    Also beim Starten vom Transfer Station 1 zu 2 wird erstmal von DB20(Bearbeitungs-DB) in DB25(Transfer-DB) kopiert. Ist das Teil bei ST2 abgekommen, wird von DB25 wieder in DB20 kopiert, aber eine Station weiter.

    Soviel erstmal dazu

    Jetzt kommen wir zu dem Problem.

    Frage Nummer 1:
    Wir oft kann ich den SFC20 in EINEM SPS-Zyklus aufrufen?
    Der Schiebe-FC beinhaltet imo 180 Mal diesen SFC.

    Frage/Problem Nummer 2:
    Manchmal verliert das System die Daten von der vorherigen Station, dh. das nach dem Transfer die Station keine Daten hat, was sie nun machen soll, weil die DB an der Stelle leer ist. Somit hat der BLKMOV nicht funktioniert, aber die Ansteuerung war def. ok. (hab ich 10 Mal schon überprüft )
    Gibt es ein Phänomen, das der BLKMOV 20 Mal sauber arbeitet und dann auf einmal nicht mehr?!

    Letzte Frage:
    Da ich ja nur einen DB für alle Stationen habe und einen DB für alle Transferdaten, stellt sich mir die Frage, ob das Möglich ist?!
    Ein Überlappen der Daten ist 100% ausgeschlossen, aber kann ich pro Zyklus mit sagen wir mal 15 BLKMOV-Aufrufen alle auf den selben DB zugreifen, oder gib es da Einschränkungen?

    Ich sage schonmal vielen Dank, wenn da jemand eine Idee hat

    Gruß
    Kommt Zeit.... Kommt Rat.... In der Tat.
    Gartenlampe mit Windenergie anstelle von Solar? Bei Interesse -> PN
    Zitieren Zitieren Komplizierte Frage zu BLKMOV oder wie oft darf ich den pro Zyklus aufrufen  

  2. #2
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Ich kenne keine Einschränkungen. Der BLKMOV kopiert die Daten in einem Zyklus um. Die Zykluszeit der SPS kann natürlich enorm ansteigen, bei schnellen SPS (VIPA Speed7, oder S7-319) hab ich damit allerdings noch nie Probleme gehabt. Die Speed7 braucht bei ihrem BLKMOV rel. viel lokalen Stackspeicher. Bei einem Baustein, der damit arg an der Grenze war hatte ich schon einmal sehr eigenartige Ergebnisse, allerdings kann man in der Hardwarekonfig der entsprechenden Ebene mehr lokalen Speicher zuteilen und schon geht es. (Retval beachten!) Für den leeren Speicher vermute ich eher, daß du 2 oder mehrere Male z.Bsp. aus dem Transport-DB in den Bearbeitungs-DB kopierst. Beim ersten regulären Mal die Daten, beim 2. Mal, dann natürlich lauter Nullen, da du die Daten aus dem Transport-DB ja sicher gelöscht hast. Nur eine Vermutung, aber prüf mal, wann genau du die Daten umkopierst.

    Wenn du Probleme mit der Zykluszeit bekommst, würde es noch einen gänzlich anderen Weg geben. Du richtest für die Bearbeitung feste Fächer ein und gibst an die Stationen nicht die kompletten Daten, sondern nur einen Zeiger in Form einer Int weiter. Die Int ist 15, also greift die Station nun auch Fach 15 zu und verwendet diese Daten. Zum Zugriff auf die Daten kann man sich wiederum Funktionen zum Schreiben und Lesen bauen, die dann mit Hilfe dieses Zeigers, die benötigten Daten manipulieren.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  3. #3
    Krumnix ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    05.11.2004
    Ort
    Schweiz
    Beiträge
    1.138
    Danke
    225
    Erhielt 127 Danke für 85 Beiträge

    Standard

    CPU ist eine 319. Zykluszeit liegt also imo bei 12ms als Max.
    Das Kopieren wird mit Flanken, die einen zuvor gespeicherte Situation (starten des Transport) festhalten und erst rückgesetzt werden, wenn der Transport fertig ist. Der Flankenmerker wird auch nirgends ein 2. Mal verwendet.
    Das Problem taucht auch nicht immer bei der gleichen Station auf. Mal bei der 3->4, mal bei 8->9 z.b.

    Ich kann mich daran mal erinnern, das ich irgendwo gelesen habe, das ein DB pro Zyklus nur eine bestimmte Anzahl Aufrufe verträgt.
    Ich weiß aber nicht mehr ob das noch zu S5-Zeiten gehörte....

    Deine Vermutung bezüglich des Löschens des Transport-Registers ist korrekt. Aber manchmal hab ich auch das Phänomen, das die Daten der Station davor plötzlich in der nachkommenden drin stehen.
    Also der Transfer garnicht gelöscht wurde....

    Hier mal der Code zur Übersicht. Ist aber bissel kompliziert, wenn man sich net so gut auskennt, was die Anlage macht. Aber vielleicht ist ja noch ein Irrer hier, der das so lesen kann

    NW1:
    Code:
          U(    
          U(    
          U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
          U     "101-2M1_FrVor"
          U     "=A+101-ST4"
          S     "DB_FIFO".FLAG_101_01
          U(    
          U     "102-2M1-InPos"
          UN    "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
          O     
          U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
          U     "101-2M1_FrRue"
          )     
          R     "DB_FIFO".FLAG_101_01
          U     "DB_FIFO".FLAG_101_01
          )     
          FP    "DB_FIFO".FLAG_101_02
          SPBNB _001
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".FIFO_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
    _001: U     BIE
          )     
          SPBNB _002
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".TYP_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
    _002: U     BIE
          =     #CLEAR_OLD_TYP
    NW2:
    Code:
          
          U(    
          U(    
          U     #CLEAR_OLD_TYP
          SPBNB _003
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".FIFO_NULL
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".FIFO_STATION_101
    _003: U     BIE
          )     
          SPBNB _004
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".TYP_NULL
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".TYP_STATION_101
    _004: U     BIE
          )     
          SPBNB _005
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".TYP_NULL
           RET_VAL:=#RETVAL
           DSTBLK :="101_VISU".FIFO_IST_STATION
    _005: NOP   0
    NW3:
    Code:
          U(    
          U(    
          U     "101-2K25"
          U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
          U     "101-2M1_FrRue"
          S     "DB_FIFO".FLAG_101_03
          U(    
          U     "101-2M1-InPos"
          UN    "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
          O     "101-2M1_FrVor"
          )     
          R     "DB_FIFO".FLAG_101_03
          U     "DB_FIFO".FLAG_101_03
          )     
          FP    "DB_FIFO".FLAG_101_04
          SPBNB _006
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".FIFO_STATION_101
    _006: U     BIE
          )     
          SPBNB _007
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".TYP_STATION_101
    _007: NOP   0
    NW4:
    Code:
          U(    
          U(    
          U     "102-2M1-InPos"
          UN    "102_FU_DAT".PD_102M1.STATUSWORT_1.MOTOR_DREHT
          S     "DB_FIFO".FLAG_101_05
          U     "102-2M1_VA"
          U     "=A+102-ST4"
          U     "102_FU_DAT".PD_102M1.STATUSWORT_1.MOTOR_DREHT
          R     "DB_FIFO".FLAG_101_05
          U     "DB_FIFO".FLAG_101_05
          )     
          FP    "DB_FIFO".FLAG_101_06
          SPBNB _008
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".FIFO_STATION_102
    _008: U     BIE
          )     
          SPBNB _009
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO".TYP_STATION_102
    _009: U     BIE
          =     #CLEAR_OLD_TYP
    NW6:
    Code:
          U(    
          U     #CLEAR_OLD_TYP
          SPBNB _00a
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".FIFO_NULL
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
    _00a: U     BIE
          )     
          SPBNB _00b
          CALL  "BLKMOV"
           SRCBLK :="DB_FIFO".TYP_NULL
           RET_VAL:=#RETVAL
           DSTBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
    _00b: NOP   0
    Kommt Zeit.... Kommt Rat.... In der Tat.
    Gartenlampe mit Windenergie anstelle von Solar? Bei Interesse -> PN

  4. #4
    Registriert seit
    01.11.2007
    Beiträge
    1.239
    Danke
    91
    Erhielt 407 Danke für 368 Beiträge

    Standard

    Nur so´ne Idee:
    Du benutzt InPos- und Motor_dreht-Signale. Könnte es sein, dass diese Signale vielleicht ab und zu mal einen zusätzlichen "Wischer" reinstreuen, weil evtl. mal ein Überschwingen auftritt ?

    Grüße von HaDi

  5. Folgender Benutzer sagt Danke zu HaDi für den nützlichen Beitrag:

    Krumnix (26.05.2009)

  6. #5
    Registriert seit
    08.12.2008
    Beiträge
    159
    Danke
    1
    Erhielt 19 Danke für 18 Beiträge

    Standard

    Hallo Krumnix,

    ich denke Du bist aufm richtigen Pfad wenn Du bedenken hast, dass ein DB nicht so oft benutzt werden darf pro SPS-Zyklus.
    Ich hatte auch schon bemerkt, dass man sehr vorsichtig mit den DBs umgehen muss, wenn man viele Zugriffe oder über Instanzen arbeitet.
    Der DB wird meiner Meinung nach nicht richtig geöffnet, geschrieben und dann geschlossen wenn Du in einem FC Netzwerkweise auf diesen zugreiffst.

    In Deinem Programm finde ich keinen Fehler. Deswegen würde ich Dir wie Ralle einen anderen Weg vorschlagen:
    Ich habe bei solchen Anlagen mit mehreren Station immer pro Station einen Arbeits-DB (z.B. DB101= Station1; DB102=Station2,...) genommen. Für die Transferstrecke habe ich einen DB (z.B. 100) genommen.
    Wenn dann der WT aus der Station läufst, machst Du nen Blockmove vom DB101 nach DB100. Dabei würde ich an Deiner Stelle die Werte "FIFO_Station" und "TYP_Station" zusammenfassen. Dann benötigst Du nur die Hälfte der Kopierfunktionen. Das wird sich direkt auf die Zykluszeit der SPS aus. (Und man hat weniger Fehlerquellen )
    Wenn der WT dann in die nächste Station einläuft, kopierst Du aus dem DB100 nach DB102.
    Für diese Funktion habe ich pro Station auch immer einen extra FC geschrieben. Dann bleibt es übersichtlicher (nur ca. 5 Netzwerke und nicht 100 wie in Deiner Version ) und die verwendeten DBs werden sicher geschlossen nachdem Du den FC verlassen hast.
    Egal was passiert: Nur nicht den Sand in den Kopf stecken!

  7. #6
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Zitat Zitat von o_prang Beitrag anzeigen
    Hallo Krumnix,

    ich denke Du bist aufm richtigen Pfad wenn Du bedenken hast, dass ein DB nicht so oft benutzt werden darf pro SPS-Zyklus.
    Ich hatte auch schon bemerkt, dass man sehr vorsichtig mit den DBs umgehen muss, wenn man viele Zugriffe oder über Instanzen arbeitet.
    Der DB wird meiner Meinung nach nicht richtig geöffnet, geschrieben und dann geschlossen wenn Du in einem FC Netzwerkweise auf diesen zugreiffst.
    Davon habe ich noch nie gehört und das halte ich auch ehrlich gesagt eher für eine Legende. Ein Step7-Programm wird ja zyklisch als ein "Thread" abgearbeitet. Da spielt es keine Rolle, wie oft ich auf einen DB zugreife und wie oft ich innerhalb eines Zyklus seine Daten ändere. Wenn man auf solche Dinge Rücksicht nehmen müßte, könnte man das Ganze sofort vergessen, da man dann ja keinerlei Angaben zur Zuverlässigkeit eines Programmes machen kann. Wenn mehrere Prozesse mit den selben Daten parallel arbeiten würden, sähe das schon anders aus. Dann müßte man sehr darauf achten, wer, was, wann schreibt!

    PS: Instanzen muß man m.E. ohnehin speziell behandeln, das hat aber nur etwas mit dem Programmierstil zu tun. Das was du beschreibst hat eindeutig mit Fehlern beim Programmieren zu tun, was aber, zugegebener Maßen, bei Step7 schnell passieren kann und manchmal auch extrem schwierig zu finden ist!
    Geändert von Ralle (24.05.2009 um 10:03 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  8. #7
    Registriert seit
    08.12.2008
    Beiträge
    159
    Danke
    1
    Erhielt 19 Danke für 18 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    Davon habe ich noch nie gehört und das halte ich auch ehrlich gesagt eher für eine Legende. Ein Step7-Programm wird ja zyklisch als ein "Thread" abgearbeitet. Da spielt es keine Rolle, wie oft ich auf einen DB zugreife und wie oft ich innerhalb eines Zyklus seine Daten ändere. Wenn man auf solche Dinge Rücksicht nehmen müßte, könnte man das Ganze sofort vergessen, da man dann ja keinerlei Angaben zur Zuverlässigkeit eines Programmes machen kann.
    Na eine Legende sieht anders aus. Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun. Deswegen würde ich es nicht pauschalieren, sondern nur zum Nachdenken anregen!

    Natürlich kann ich alle Umwegsamkeiten bzw. Probleme damit beheben, den Programmierstil zu ändern.
    Aber für den Fehler den Krumnix beschreibt sehe ich keine logischen Fehler in dem Programm. Und da keine logischen Fehler drin sind, muss es automatisch mit dem Abarbeiten der S7 zu haben, oder?!?
    Wenn Krumnix jetzt hingeht und sein Programm abändert, muss er das nicht aufgrund eines offensichtlichen Fehlers in seinem Programm machen, sondern weil die S7 die Abarbeitung nicht so macht wie macht es vorstellt.
    Egal was passiert: Nur nicht den Sand in den Kopf stecken!

  9. #8
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Zuallererst sollten mal die RetVal ausgewertet werden. Das mach ich im Normalfalle bei BlkMov eigentlich auch nicht, aber hier scheint ja kein Normalfall vorzuliegen.
    Des Weiteren würde ich auf jeden Fall Code einbauen, der dafür sorgt, daß es nicht möglich ist, "leere", somit ungültige Daten in die Station bzw. den Transport-DB zu kopieren, weil eine Flanke nochmals ausgelöst wird. Dafür könnte man eine Zählvariable hernehmen, die 0 oder 1 sein muß. Bool geht auch, aber mit der Zählvariablen >1 oder <0 kann man gleich noch solchen "unerwünschten" Flanken auf die Spur kommen. Ohnehin finde ich die Verkettung der Logic über SPBNB und das BIE zwar platzsparend, aber eher aus "FUP-like Programing" geboren und in AWL absolut nicht die Übersicht fördernd. Dann lieber ein paar Bitabfragen doppelt, dafür aber die Übersicht gewahrt.

    Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun.
    Au weia, wenn das stimmt, sollen die ihre Bude lieber dichtmachen, ehe irgendwelche Dampferzeuger oder Generatoren in die Luft fliegen, weil man 2 mal zuviel ein Datenwort mir der Temperatur ausgelesen und angezeigt hat!
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  10. #9
    Registriert seit
    04.02.2007
    Beiträge
    2.544
    Danke
    167
    Erhielt 731 Danke für 528 Beiträge

    Standard

    Ich setze den Blockmove seit jahren oft ein. Genau wie in diesem fall bei Schieberegistern und Auftragsverwaltungen usw. Wenn ich dabei einen Fehler hatte, lag der bisher immer an mir. Beim Blockmove habe ich noch keinen gefunden, auch wenn ich manchmal die Vermutung hatte.

    Der Code war meist auch richtig, aber das timing war halt machmal falsch.

    Man muss auf jeden fall verhindern das zur falschen Zeit und nicht zu oft geschoben wird. Dies kann z.B. durch einen prellenden Endschalter/Lichtschranke kommen, oder z.B. eine falsche Flankenbildung z.B. Verknüpfen von Bereit oder Steuerung mit der Auslösenden Funktion.

    Zur eigentlichen Anlage ist ja nicht viel erklärt. Was passiert bei einem NIO Bauteil, fährt das eventuell direkt durch und schiebt dadurch die Daten weiter bevor die nächste palette in der Station dahinter ankommt?

    Nur so als Denkansatz, kenn da Anlage ja nicht, aber auf solche Sachen muss man genau achten. Diese passieren im normalen Ablauf halt nicht, aber hin und wieder.

  11. #10
    Registriert seit
    04.02.2007
    Beiträge
    2.544
    Danke
    167
    Erhielt 731 Danke für 528 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von o_prang Beitrag anzeigen
    .... Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun. Deswegen würde ich es nicht pauschalieren, sondern nur zum Nachdenken anregen!
    ...
    Das sind die Antworten von den Herstellern wenn denen nix mehr einfällt.
    Wahrscheinlich hast Due damals gefragt , "kann es sein..." , dann kommt immer so eine Antwort.

    Ich kann die Temporären Variablen überschreiten, oder zuviel Trafic auf dem Bus erzeugen, aber wenn ich auf einen DB im normalen OB1 (also ohne OB35 usw) zugreife da draf nix passieren. Un wenn ich 1000 Blockmove ausführe, darf die Zykluszeit in die Höhe gehen und sonst nix.

Ähnliche Themen

  1. Profinet FB oder FC aufrufen im OB86
    Von epy im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 17.11.2010, 22:14
  2. Antworten: 50
    Letzter Beitrag: 12.11.2008, 23:13
  3. AB erster Zyklus, oder erster Aufruf des Task nach RUN
    Von MSB im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 22.02.2008, 10:09
  4. Antworten: 9
    Letzter Beitrag: 13.02.2006, 16:12
  5. Frage zu SFC20 BLKMOV
    Von chivas im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 24.02.2005, 14:47

Lesezeichen

Berechtigungen

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