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

Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 30 von 34

Thema: Migration von Funktionsbausteinen (STEP 7 V5.5 >> STEP 7 V13 Professional)

  1. #21
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Rudelz Beitrag anzeigen
    Also warum der Aufwand?
    Um nun endlich die S7-Programmierer zu sauberem Programmierstil zu erziehen (das lesen der OUT war auch vorher schon pfui) und um den Programm-Quelltext unabhängig vom Einsatz in FB oder FC zu machen - in FC ist das Lesen der OUT sogar richtig falsch, wie wir hier kürzlich über einen Optimierungs-Bug des SCL-Compilers lesen konnten.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  2. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Rudelz (20.11.2015)

  3. #22
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.337
    Danke
    448
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Zitat Zitat von Rudelz Beitrag anzeigen
    muss ich meine Bausteine umprogrammieren
    Technisch gesehen...
    Nein.
    Solange nicht jemand, von der Extern (Visu) oder aus einem Interrupt heraus, den OUT-Bereich der FB-Instanz liest, bist du eigentlich immer konsistent.
    Aber die Varianten sind beide unglaublich pfui.
    Stil-technisch gesehen...
    JA.

    Wo du allerdings schon ein Problem hast ist beim IN/OUT.
    Bei der 1200/1500 liest die Visu nicht mehr zwischen Zyklusende und Zyklusanfang, sondern irgendwo mittendrin.
    Kann auf sein das die Visu mitten in der Abarbeitung des Bausteins liest und schreibt.

    Das solltest du unbedingt bei der Konzeption betrachten.
    Umstieg auf S7-1500
    Geändert von RONIN (19.11.2015 um 16:23 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  4. Folgende 2 Benutzer sagen Danke zu RONIN für den nützlichen Beitrag:

    Kai Schulz (20.11.2015),Rudelz (20.11.2015)

  5. #23
    Registriert seit
    06.06.2012
    Ort
    51597 Morsbach, NRW
    Beiträge
    73
    Danke
    10
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Hallo RONIN.

    Zitat Zitat von RONIN Beitrag anzeigen
    Bei der 1200/1500 liest die Visu nicht mehr zwischen Zyklusende und Zyklusanfang, sondern irgendwo mittendrin.
    Kann auf sein das die Visu mitten in der Abarbeitung des Bausteins liest und schreibt.
    Danke für diese wichtige Information!

    Man sollte eventuell die gesamte HMI-Kommunikation zwischenspeichern und besser mit dem Zwischengespeicherten arbeiten, dass man dann, am Anfang des OB1-Zyklus einliest und erst am Ende schreibt. >> Das sollte vor "Gulasch" schützen!

    Gruß Kai

  6. #24
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.337
    Danke
    448
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Zitat Zitat von Kai Schulz Beitrag anzeigen
    Man sollte eventuell die gesamte HMI-Kommunikation zwischenspeichern und besser mit dem Zwischengespeicherten arbeiten, dass man dann, am Anfang des OB1-Zyklus einliest und erst am Ende schreibt.

    >> Das sollte vor "Gulasch" schützen!
    Wen's interessiert. Das Verhalten kann man schnell nachstellen.
    • PLCSIM mit der 1500er
    • im OB1 in NW1 einen Datenpunkt auf 1 setzen
    • in NW2 2 Wait-Bausteine mit 2x32000 (64ms) einfügen
    • in NW3 den Datenpunkt wieder auf 0 setzen
    • in NW4 wieder 2 Waitbausteine mit 64ms.

    Danach ne Visu projektieren mit ner Animation auf diesen Datenpunkt. In ner 300er sieht man nix. Mit der 1500er blinkt die Animation schön dahin.

    Auch wenn es bei der 400er auch schon so war, finde ich die Vorgehensweise nicht wirklich gut. Man muss da so sehr aufpassen das man nicht in einem
    von einer Million Fälle einen Fehler produziert. Ja, ich bin auch schon gespannt wie viele Probleme mit sowas (vor allem von Neulingen) hier im Forum auflaufen werden.
    Wozu machen wir dann eigentlich noch ein Prozessabbild der Ein/Ausgänge? Soll die CPU doch auf gleich mitten im Zyklus die E/As schreiben.

    Der einzige weg drum herum im Moment wäre sein Hauptprogramm mittels Interrupt und SRT_DINT mit einer Prioritätsstufe > 15 aufzurufen.
    Die Stufe wird nicht durch HMI-Kommunikation unterbrochen. Ist aber auch nur ne Notlösung wenn man z.b. ein 300er Programm konvertiert das mit dem neuen HMI-Zugriff nicht klar kommt.

    Eigentlich sollte nicht viel migrieren sondern eher seine Bausteine neu schreiben. Leider
    Geändert von RONIN (20.11.2015 um 10:27 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  7. #25
    Registriert seit
    06.10.2003
    Beiträge
    3.408
    Danke
    449
    Erhielt 502 Danke für 406 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    .. Mit der 1500er blinkt die Animation schön dahin...
    Für lesende Zugriffe ist das ja auch ganz ok, finde ich. Hat jemand eine Idee, wie man so etwas für Schreibzugriffe testen kann?
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  8. #26
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    775
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Code:
          U     "Boolmerker"      
    SPBN  up
          L     "zählvar"
          L     1
          +I
          T     "zählvar"
    up:   NOP 0
    
    
          CALL  WAIT
             WT :=32767
    
    
          CALL  WAIT
             WT :=32767
    
    
          U     "Boolmerker"
          SPBN  up1
          L     "zählvar_2"
          L     1
          +I
          T     "zählvar_2"
          R     "Boolmerker"
    up1:  NOP 0
    in der 300er würden die zählvars gleichmässig hochzählen.
    bei der 1500er gibts dann verschiebungen wenn man innerhalb des Zyklus reinschreibt (boolmerker setzen).


    Allerdings Hab ich mir das schon länger angewohnt so zu programmieren als kämen und gingen die Daten irgendwo im Zyklus (weil oft 400er habe). Will heissen Austauschbereiche.
    Geändert von vollmi (20.11.2015 um 11:07 Uhr)

  9. #27
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.337
    Danke
    448
    Erhielt 688 Danke für 513 Beiträge

    Standard

    @Onkle, HMI-Kommunikation bedeutet natürlich auch Schreibzugriff.

    Zitat Zitat von vollmi Beitrag anzeigen
    Allerdings Hab ich mir das schon länger angewohnt so zu programmieren als kämen und gingen die Daten irgendwo im Zyklus (weil oft 400er habe). Will heissen Austauschbereiche.
    Ja leider, wir haben ausschließlich 300er und daher hab ich meine Probleme damit.

    Die Austausch-Bereiche sind mehr Arbeit und mehr Speicher, daher hab ich bis jetzt nicht so programmiert.
    Die ganzen Fbs übernehmen eine Datenstruktur via SFC20 in dem Temp, bearbeiten die, und kopieren Sie am Ende wieder raus.
    Auf der 300 ist das wesentlich schneller und weniger Speicherintensiv als INOUT.

    Das geht jetzt natürlich nicht mehr und somit hab m(k)eine Freude damit....
    Also, alles neu.
    Geändert von RONIN (20.11.2015 um 11:18 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  10. #28
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    775
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    Die Austausch-Bereiche sind mehr Arbeit und mehr Speicher, daher hab ich bis jetzt nicht so programmiert.
    Die ganzen Fbs übernehmen eine Datenstruktur via SFC20 in dem Temp, bearbeiten die, und kopieren Sie am Ende wieder raus.
    Auf der 300 ist das wesentlich schneller und weniger Speicherintensiv als INOUT.
    Das braucht überhaupt nicht mehr Speicher, auch wenn ich eher selten in Engpässe kommen würde schau ich schon auch auf den Speicher. Man muss nur davon weg den OB als Manager zu verwenden. Für mich ist der OB nur der Taskoperator. Der ruft meine Hauptfunktion auf (z.B. FC_Anlagensteuerung) Die Daten für Visu, Peripherie werden per SFC20 in diesem Baustein in den Tempbereich kopiert und am Ende des FC wieder zurückgeholt. Nur INOUT und Temp.
    Wenn man die Austauschbereiche möglichst strukturiert (UDTs etc) aufbaut, muss man ihn auch wenig von Hand Pflegen, sondern passt die UDTs an und schon sind sowohl HMI DB wie auch Temp Bereich wieder gleich.

    Was mich viel eher stört dass das mit den unterschiedlichen UDT für HMI und SPS immer schlimmer wird. Jetzt werden die UDT im HMI sogar noch zwischen 1500er und 300/400 unterschiedlich aufbereitet.
    Ich brauch also für meine Datenhaltung ein Exportmacro für die UDT im SPS Programm, ein weiteres Macro für die HMI und dieses dann noch umschaltbar Classic und 1500er. Da kriegt ich Krämpfe (aber erst so richtig wenn HMI import für UDTs funktioniert).

    mfG René
    Geändert von vollmi (20.11.2015 um 11:38 Uhr)

  11. #29
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.337
    Danke
    448
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Zitat Zitat von vollmi Beitrag anzeigen
    Das braucht überhaupt nicht mehr Speicher,
    Beim Aufrufer-FB macht das keinen Unterschied, bei dem aufgerufenen FB selber ist es schon ein gewaltiger Unterschied ob du einen UDT oder INOUT oder ANY/SFC20 übergibst.
    Habs jetzt nur an nem alten Mini-FB der eine kleine 30Byte Struktur übernimmt probiert.
    UDT mit INOUT übergben - 2844Byte
    UDT mit ANY/SFC20 übergeben - 1124Byte (Sonst nix geändert)
    Ist ja auch klar, auf die INOUT wird ja ständig mittels Pointer rangiert.

    Bei ein paar 100 Instanzen und auf ner ET200S-CPU macht sich dass dann schon schnell bemerkbar.
    Einerseits bringst du fast nix mehr drauf weil die Bausteine soviel Speicher brauchen, andererseits geht die Zykluszeit auch nach oben.

    Zitat Zitat von vollmi Beitrag anzeigen
    Man muss nur davon weg den OB als Manager zu verwenden. Für mich ist der OB nur der Taskoperator.
    Hab ich nicht ganz verstanden.


    Zitat Zitat von vollmi Beitrag anzeigen
    Die Daten für Visu, Peripherie werden per SFC20 in diesem Baustein in den Tempbereich kopiert und am Ende des FC wieder zurückgeholt.
    Hast du da nicht das selbe Problem. Wenn die die Visu in dem Moment in den Visudatenbereich schreibt während die Kopie gerade im Temp ist.?
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  12. #30
    Registriert seit
    06.06.2012
    Ort
    51597 Morsbach, NRW
    Beiträge
    73
    Danke
    10
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von RONIN Beitrag anzeigen
    Hab ich nicht ganz verstanden.
    Er ruft im OB1 nur einen FC auf, den er quasi als "Ersatz"-OB1 benutzt. Die HMI Daten kopiert er, vor der FC-Bearbeitung, mit "Blockmove" in den FC-Tempbereich und am Ende wieder zurück, er erzeugt quasi ein künstliches Prozessabbild der HMI-E/A-Daten.

    Gruß Kai
    Geändert von Kai Schulz (23.11.2015 um 08:36 Uhr)

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 11.04.2012, 07:21
  2. Step 7 Professional für Windows 7?
    Von egger im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 21.12.2010, 22:23
  3. Antworten: 10
    Letzter Beitrag: 29.10.2010, 17:06
  4. Step 7 Professional 2006
    Von Simaticfuzzy im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 21.12.2009, 11:23
  5. Fehlermeldung bei Step 7 Professional
    Von bwink68 im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 14.11.2007, 14:58

Stichworte

Lesezeichen

Berechtigungen

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