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

Seite 3 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 21 bis 30 von 47

Thema: Programming Guidelines and Programming Styleguide for SIMATIC S7-1200 and S7-1500

  1. #21
    Registriert seit
    29.03.2004
    Beiträge
    5.739
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Falsch ist z.B. Kapitel 2.13 mit der Referenz ID. Denn die ID verändert sich nicht nur durch das Umbenennen einer Variable sondern bleibt in dem Fall gleich.
    Darum würde ich auch anderen Aussagen über Verhaltensweisen der 1200/1500 nicht unbedingt blind vertrauen. Der Verfasser hat wohl nur eingeschränkten Zugriff auf die Siemens-Internas.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  2. #22
    Registriert seit
    08.04.2016
    Ort
    4040 Linz, Österreich
    Beiträge
    191
    Danke
    17
    Erhielt 61 Danke für 50 Beiträge

    Standard

    Zitat Zitat von maxder2te Beitrag anzeigen
    Der deutschsprachige Styleguide liegt übrigens hier:
    https://support.industry.siemens.com...dti=0&lc=de-WW

    Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.
    Ok, da ich den Beitrag gestern offenbar zu leichtfertig abgesetzt habe, ein paar Details dazu:
    Die "Standardisierungsrunde" besteht aus den Leuten, die Vorlagen, Treiber und Bibliotheken erzeugen, und den Entscheidungsträgern, die das Zeug dann ihren Leuten (Programmierer, Inbetriebnehmer, >80) weitergeben. Die Runde erstellt keine strikte Norm, sondern Leitlinien, die wir selbst im Bibliotheksbau umsetzen und dann zur Anwendung kommen, wenn der Kunde keine expliziten Vorschriften setzt.
    Das was Siemens als "Programmierleitfaden" (ich beziehe mich auf 1.5) bezeichnet, ist für Leute mit mittelmäßiger S7 Classic Erfahrung eine einigermaßen brauchbare Einführung in die S7-1200/1500-Welt. Zum Erstellen von Leitlinien ist es nur eine Entscheidungshilfe, aber sicherlich keine Vorgabe - schließlich sind am Ende nur ca. 20-30% der Informationen relevant. Was sich aus dem Leitfaden ableiten lässt sind, aber folgende Vorgaben:
    1. Ausnahmslos optimierte Bausteine und Autonummerierung
    2. Programmierung ausschließlich in FBs, Programmaufbau hierarchisch in Multiinstanzen
    3. Programmierung in FUP/KOP und SCL, kein Graph, kein AWL
    4. keine Berücksichtigung der S7-1200
    5. striktes Trennen von Persistenten Daten, Aktualdaten und Instanzdaten, konsequentes Information-Hiding


    Vorgabe 1 ist eine Frage der Konsistenz - in der C#-Applikations- oder C-Embedded-Entwicklung stellt sich diese Frage ohnehin nicht. Auch stellt sich so die Frage, ob INOUT-Parameter byref oder byval übergeben werden, nicht. Dass speziell die Abhandlung von Schnittstellen auf diese Art und Weise in ziemlicher Arbeit ausarten kann, nehmen wir teils hin.
    Vorgabe 2 sorgt für übersichtliche Programme - vor allem wenn man eine hierarchische Vererbung von gewissen Informationen konsequent durchzieht.
    Vorgabe 3 Graph nur auf ausdrücklichen Kundenwunsch und erst nach einem direkten Gespräch mit den technischen Entscheidungsträgern - ausschließlich für Bewegungsabläufe.
    Vorgabe 4 die 200-300 EUR Preisunterschied zu den kleinen 1500er Steuerungen sind bei den meisten Maschinen vernachlässigbar - zentrale IOs gibts ohnehin nie
    Vorgabe 5 bedarf noch eines gewissen Lerneffekts, vor allem in Bezug auf die Speicherreserve.


    Viel wichtiger als der Leitfaden ist der Styleguide mit seinen Regeln, wobei natürlich Regeln aufgeweicht werden, z.B.
    4.1.3 Quellen - lassen sich teils nicht vermeiden
    4.1.3 nur Lokale Variablen - lässt sich teils nicht einhalten da Schnittstellen zu sehr aufgebläht würden
    4.1.5 Struct - nur in globalen DBs (Persistent oder Aktual)
    ...

    Fragen?

  3. #23
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von maxder2te Beitrag anzeigen
    1. .
    2. Programmierung ausschließlich in FBs, Programmaufbau hierarchisch in Multiinstanzen
    Dann erfordert fast jede Änderung an den Lokaldaten (!) oder der Schnittstelle der beteiligten FB einen CPU-STOP zum laden. Nein, danke.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  4. #24
    Registriert seit
    08.04.2016
    Ort
    4040 Linz, Österreich
    Beiträge
    191
    Danke
    17
    Erhielt 61 Danke für 50 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Dann erfordert fast jede Änderung an den Lokaldaten (!) oder der Schnittstelle der beteiligten FB einen CPU-STOP zum laden. Nein, danke.
    Harald
    Das stimmt so nicht. Passt man nicht auf, ist das Reinitialisieren nötig - zum CPU stoppen gehört aber schon einiges dazu.

  5. #25
    Registriert seit
    13.10.2007
    Beiträge
    12.036
    Danke
    2.789
    Erhielt 3.269 Danke für 2.157 Beiträge

    Standard

    Ich würde den "Style-Guide" nicht überbewerten, das Wort gibt nichts anderes wieder wie Gestaltungrichtlinie
    und nicht Programmiergesetz oder Verordnung zur Verwendung von Bits und Bytes. Es ist eine Hilfe, mehr nicht.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  6. #26
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von maxder2te Beitrag anzeigen
    Das stimmt so nicht. Passt man nicht auf, ist das Reinitialisieren nötig - zum CPU stoppen gehört aber schon einiges dazu.
    OK, stimmt, das war falsch so. Der STOP wird nicht nötig wegen der Multiinstanz, sondern schon wegen Änderung der Instanzdaten - eventuell kann TIA den STOP ja noch teilweise mit der Speicherreserve abfangen, doch wenn TIA den STOP verlangt, dann habe ich wegen den Multiinstanzen nur noch unter sehr hohem Aufwand eine Chance, das TIA zu umgehen und meine eigene "intelligentere" Ladestrategie ohne CPU-STOP durchzuführen.

    Macht die S7-1500 eigentlich bei jedem Programm laden ein Defrag des "optimierten"-Arbeitsspeichers oder wird das Programm nach jeder Änderung in RUN ein kleines bisschen langsamer?
    Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  7. #27
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.351
    Danke
    452
    Erhielt 692 Danke für 517 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?
    Da geht die CPU in STOP.
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  8. #28
    Registriert seit
    08.04.2016
    Ort
    4040 Linz, Österreich
    Beiträge
    191
    Danke
    17
    Erhielt 61 Danke für 50 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    OK, stimmt, das war falsch so. Der STOP wird nicht nötig wegen der Multiinstanz, sondern schon wegen Änderung der Instanzdaten - eventuell kann TIA den STOP ja noch teilweise mit der Speicherreserve abfangen, doch wenn TIA den STOP verlangt, dann habe ich wegen den Multiinstanzen nur noch unter sehr hohem Aufwand eine Chance, das TIA zu umgehen und meine eigene "intelligentere" Ladestrategie ohne CPU-STOP durchzuführen.
    Sorry, aber das kann ich so nicht nachvollziehen. Solange man mit dem Speicher nicht aus dem letzten Loch pfeift, kann man auch grobe Änderungen in die 1500er ohne STOP laden - auch wenn man an den Instanzen herumbastelt. Reinitialisieren ja - stoppen: nein. Muss aber auch sagen, dass ich noch nichts kleineres als eine 1515er an meinem Rechner hatte.


    Zitat Zitat von PN/DP Beitrag anzeigen
    Macht die S7-1500 eigentlich bei jedem Programm laden ein Defrag des "optimierten"-Arbeitsspeichers oder wird das Programm nach jeder Änderung in RUN ein kleines bisschen langsamer?
    Was soll das eine mit dem anderen zu tun haben? Warum soll ein Programm langsamer werden, nur weil was im Speicher woanders liegt, ist der Zugriff nicht automatisch langsamer. Und sowas wie das Fragmentieren von Dateien sollte es nicht geben.
    Zitat Zitat von PN/DP Beitrag anzeigen
    Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?
    Ist die Frage ernst gemeint? Es ist heutzutage wohl zumutbar, dass man Arraygrenzen selber überwacht (weil man ohnehin nicht mit Zeigern, sondern mit Array-Indizes drauf zugreift).
    Spannenderweise zeigt die S7-1500 (zumindest mit Firmware 1. das gleiche Verhalten wie die 300er. Wenn beim Array-Überlauf in dem betroffenen Baustein hinterher noch Daten deklariert sind, dann wird schnell mal Müll aus dem Nirvana gelesen. Rockwell ist da von jeher viel rigoroser!

  9. #29
    Registriert seit
    16.10.2012
    Beiträge
    743
    Danke
    51
    Erhielt 36 Danke für 29 Beiträge

    Standard

    Zitat Zitat von maxder2te Beitrag anzeigen
    [*]Programmierung in FUP/KOP und SCL, kein Graph, kein AWL Vorgabe 3 Graph nur auf ausdrücklichen Kundenwunsch und erst nach einem direkten Gespräch mit den technischen Entscheidungsträgern - ausschließlich für Bewegungsabläufe. Fragen?
    Ja, eigentlich nur eine. Ich weiß nicht, was für Anlagen ihr da programmiert - aber das was Du hier schreibst, klingt nach einem schweren Dachschaden (ja, ist genau so wenig schmeichelhaft gemeint wie es geschrieben ist).

    Wenn ich ein externer Einkäufer wär - und zu mir jemand käme, der mir anbieten würde, eine Anlage mit Bewegungsabläufen (ja überhaupt mit irgendwelchen diskreten schrittweisen Abläufen, es sei denn, es handelt sich um eine prozesstechnische Anlage nach PCS7) ohne Graph, ohne PDIAG/PRODIAG und nur mit SCL zu programmieren - dann würde ich ihm sagen, daß ich als Kunde als Ziel-Senke für seine unbefriedigten Hochsprachen-Lustträume und die dazugehörigen Bemühungen, noch zum Jahresende irgendwo schnell 2000-3000 Programmierstunden zu verbauen, die bei sachgerechter Vorgehensweise erst gar nicht anfallen würden, nicht in Frage komme. Und die Kompetenz des Anbietenden aufgrund seiner sektenhaft-antiquirten Programmiervorstellungen stark in Zweifel ziehen würde.

    Die Vorgehensweise ohne Graph würde ich allenfalls bei reinem Prozess noch irgendwie nachvollziehen können, aber auch da nicht wirklich. Meine sehr bedauernswerte aber trotzdem fast ausnahmslos zutreffende Feststellung bezüglich abgeschlossener Programmierergesellschaften in mittelständischen Firmen indes lautet, daß diese Biotope ab einer bestimmten Größe der Programmierabteilung, Vorliegen entsprechender hierarhischer Strukturen, Konzentrierung der Entwicklungskompetenzen in wenigen "erfahrenen Händen" und zunehmender Entkoppelung von der großen Außenwelt in einer sehr sektenähnlichen Dynamik ausarten. Das passiet in der Regel dann, wenn zwar hochintelligente aber eigensinnige und in die Jahre gekommene Herren im kleinen Kreis Standardisierungsfragen für die gesamte Firma auf eigene Faust entscheiden dürfen. Die Kollegen unter ihnen dürfen ihnen nichts sagen, die Chefs darüber haben von der Materie kaum Ahnung, da es für sie sehr abstrakt ist. Und als externer hat man da in der Regel sowieso nichts zu melden. Im Ergebnis entwickelt sich da desöfteren eine ganz eigene Flora und Fauna, ja ein ganz eigener Biotop, wo irgendwelche Phoenix "Kliki-Bunti Sinus Plus allways minus kosinus"-Panels und Verzicht auf "Global Tags" noch die harmlosesten Entwicklungen darstellen.
    Geändert von Draco Malfoy (07.12.2017 um 20:09 Uhr)

  10. #30
    Registriert seit
    08.04.2016
    Ort
    4040 Linz, Österreich
    Beiträge
    191
    Danke
    17
    Erhielt 61 Danke für 50 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    Ja, eigentlich nur eine. Ich weiß nicht, was für Anlagen ihr da programmiert - aber das was Du hier schreibst, klingt nach einem schweren Dachschaden (ja, ist genau so wenig schmeichelhaft gemeint wie es geschrieben ist).

    Wenn ich ein externer Einkäufer wär - und zu mir jemand käme, der mir anbieten würde, eine Anlage mit Bewegungsabläufen (ja überhaupt mit irgendwelchen diskreten schrittweisen Abläufen, es sei denn, es handelt sich um eine prozesstechnische Anlage nach PCS7) ohne Graph, ohne PDIAG/PRODIAG und nur mit SCL zu programmieren - dann würde ich ihm sagen, daß ich als Kunde als Ziel-Senke für seine unbefriedigten Hochsprachen-Lustträume und die dazugehörigen Bemühungen, noch zum Jahresende irgendwo schnell 2000-3000 Programmierstunden zu verbauen, die bei sachgerechter Vorgehensweise erst gar nicht anfallen würden, nicht in Frage komme. Und die Kompetenz des Anbietenden aufgrund seiner sektenhaft-antiquirten Programmiervorstellungen stark in Zweifel ziehen würde.

    Die Vorgehensweise ohne Graph würde ich allenfalls bei reinem Prozess noch irgendwie nachvollziehen können, aber auch da nicht wirklich. Meine sehr bedauernswerte aber trotzdem fast ausnahmslos zutreffende Feststellung bezüglich abgeschlossener Programmierergesellschaften in mittelständischen Firmen indes lautet, daß diese Biotope ab einer bestimmten Größe der Programmierabteilung, Vorliegen entsprechender hierarhischer Strukturen, Konzentrierung der Entwicklungskompetenzen in wenigen "erfahrenen Händen" und zunehmender Entkoppelung von der großen Außenwelt in einer sehr sektenähnlichen Dynamik ausarten. Das passiet in der Regel dann, wenn zwar hochintelligente aber eigensinnige und in die Jahre gekommene Herren im kleinen Kreis Standardisierungsfragen für die gesamte Firma auf eigene Faust entscheiden dürfen. Die Kollegen unter ihnen dürfen ihnen nichts sagen, die Chefs darüber haben von der Materie kaum Ahnung, da es für sie sehr abstrakt ist. Im Ergebnis entwickelt sich da eine eigene Flora und Fauna, ja ganz eigener Biotop, wo irgendwelche Phoenix "Kliki-Bunti Sinus Plus allways minus kosinus"-Panels und Verzicht auf "Global Tags" noch die harmlosesten Entwicklungen darstellen.
    Und wie lautet die angekündigte Frage?

  11. Folgender Benutzer sagt Danke zu maxder2te für den nützlichen Beitrag:

    DeltaMikeAir (07.12.2017)

Ähnliche Themen

  1. Sonstiges Simatic S7 300-F/ 1200-F / 1500-F / ET200SP-F
    Von xbit im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 16.11.2017, 14:12
  2. Ein Panel von INSEVIS an eine Simatic 300/400/1200/1500 warum nicht ?
    Von INSEVIS-Service im Forum Werbung und Produktneuheiten
    Antworten: 3
    Letzter Beitrag: 24.07.2017, 10:05
  3. B&R Automation Studio Loadcell programming in C
    Von resmimurali im Forum Sonstige Steuerungen
    Antworten: 1
    Letzter Beitrag: 22.05.2017, 11:22
  4. Programming of a packaging line
    Von denhondt im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 19.12.2012, 04:48
  5. "Power Programming"
    Von Oberchefe im Forum Programmierstrategien
    Antworten: 18
    Letzter Beitrag: 14.11.2006, 22:17

Lesezeichen

Berechtigungen

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