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

Seite 6 von 10 ErsteErste ... 45678 ... LetzteLetzte
Ergebnis 51 bis 60 von 97

Thema: Programmstruktur Step7

  1. #51
    Registriert seit
    13.10.2007
    Beiträge
    12.063
    Danke
    2.793
    Erhielt 3.288 Danke für 2.168 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ich geb jetzt auch zu, dass ein Baustein, der einen FB als Multiinstanz verwendet, nicht gekapselt ist. Falls Du das überhaupt bemerkt hättest
    ich glaube das ist das zauberwort, "FB nicht gekapselt".
    Der FB wird nur mit Instanzdaten erzeugt um aus den Daten des Lokaldatenbereiches einen DB
    zu erstellen. Das ist in diesen fall halt der Instanzdatenbaustein. Im Programm wird er quasi als
    Globaldatenbaustein verwendet bzw. Missbraucht.

    Ziel kann es z.b. sein das bei verwendung von IEC Timern nicht für jeden Timer ein eigener Daten-
    baustein erzeugt werden muß, diese stehen dann als Multiinstanz im Lokalbereich des FB's, das
    ganze hilft bei der Strukturrierung des Programmes.
    Geändert von rostiger Nagel (24.08.2010 um 21:40 Uhr)
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  2. #52
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.311
    Danke
    932
    Erhielt 3.321 Danke für 2.683 Beiträge

    Standard

    Hallo Perfektionist,

    Danke für Deine ausführlichen Statements zu meinem Beitrag. Ich möchte aber nicht jedes Einzelne beantworten, dann würde diese Antwort auch für meine Begriffe viel zu lang werden. Ich werde mir aber ein paar Deiner Aussagen herauspicken.

    Nach mehrmaligem Durchlesen meine ich, daß Deine und meine Meinung zu dem Thema eigentlich gar nicht soweit auseinander liegen. Auch Du hast viele Wahrheiten geschrieben. Auch Dir sind die meisten möglichen Probleme beim Zusammenspiel Steuerungsprogramm und HMI bekannt und bewußt. Und doch sind Deine Schlußfolgerungen auf die Erkenntnisse andere als meine. Du willst durch besonders cleveres Vorgehen beweisen, daß Du die Probleme innerhalb der Siemens-Welt vollkommen im Griff hast. Ich will die Probleme lieber umgehen bzw. von vornherein vermeiden, und das auf eine Weise, die auch bei Steuerungen und HMI anderer Fabrikate funktioniert. (zugegeben: auch da, wo im speziellen Fall vielleicht gar kein Problem wäre - doch wie ich schon schrieb, ich halte mich immer an die angeführten Prinzipien, egal ob speziell nötig oder nicht. Ich will das nicht jedes Mal neu entscheiden.)

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert.
    Ich bin davon ausgegangen, dass keiner so arbeiten will. Wenn es so ist, dass jemand die Möglichkeiten, die seit Protool 6.0 zuverlässig funktionieren, nicht nutzen will, dann kann ich nachvollziehen, dass jemand nicht nur rangieren will, sondern sogar dazu weitgehend gezwungen ist.
    Man muß mal über den Tellerrand schauen. Die Steuerungswelt besteht nicht nur aus total integrierten Siemens-Komponenten. Da gibt es auch andere HMI-Fabrikate, z.B. Exor/UniOp, Beijer, InTouch ... oder gar komplett selbstprogrammierte PC-Visu ohne jeglichen Quelltext. Die Generiersoftware dieser Fremd-Fabrikate kann garnicht in Step7 integriert werden. Ich kann mich auch nicht erinnern, jemals das richtige Siemens-WinCC komplett in ein Step7-Projekt integriert gesehen zu haben. Die Steuerung muß ebenfalls keine Siemens S7 sein.

    Spätestens, wenn man keine Lizenz für die spezielle HMI-Generiersoftware hat oder das aktuelle HMI-Quellprojekt einfach nicht vorhanden ist, dann ist die HMI eine Blackbox und hat sich gefälligst an dokumentierte Schnittstellen zum Steuerungsprogramm zu halten.

    Meine strikte Abneigung gegen Zugriffe der HMI direkt auf Objekte außerhalb der Schnittstellen-DB (z.B. Instanz-DB, globale Merker, Timer, ...) begründet sich daher, daß diese Zugriffe nur im HMI-Projekt dokumentiert sind und im Steuerungsprojekt nur in Form der Schnittstellen-DB sichtbar sind. Jegliche Zugriffe der HMI außerhalb der Schnittstellen-DB sind im Steuerungsprojekt ohne HMI-Projekt nur dann bekannt, wenn der Programmierer dies in einer extra erstellten Dokumentation erwähnt, die vorhanden und ohne das HMI-Projekt lesbar sein muß.

    Alle mir bekannten Reengineering-Methoden können die HMI-Zugriffs-Dokumentation nur unvollständig rekonstruieren und nicht beweisen, daß die HMI nicht auf bestimmte Objekte zugreift. Zusätzlich ist eine solche Rekonstruktion arbeitsaufwändig, ist aber oft notwendig, nur weil der original-Programmierer das Rangieren und das Dokumentieren als lästige und unnötige Zusatz-Arbeit empfand.

    Ohne die HMI-Zugriffs-Dokumentation ist jedes Ändern von Variablen-Adressen im Steuerungsprogramm und selbst die Nutzung vermeintlich ungenutzter Variablen ein Glücksspiel. Deshalb meine Meinung, HMI-Zugriffe generell nur über Schnittstellen-DB abzuwickeln.

    Zitat Zitat von PN/DP Beitrag anzeigen
    Warum soll man nicht in der Elektrik bewährte Prinzipien auch für die Programmierung anwenden, auch wenn man nicht
    weiß, warum etwas heute so-und-so gemacht wird?
    Ich hoffe, Du fühltest Dich nicht persönlich angegriffen (Du hast es gleich zweimal zitiert).

    Das mit dem nicht-Wissen war nicht speziell auf Dich gemünzt. Ich meinte damit einfach nur Regeln, die man irgendwann gelernt hat und anwendet, ohne den genauen ursächlichen Grund dafür (noch) zu wissen. Solche Regeln gibt es mehr als man denkt.

    Wer kann schon genau erklären, wie und warum sich die heute üblichen Taster- und Leuchtenfarben entwickelt haben, hält sich aber daran, weil es so üblich und teilweise sogar vorgeschrieben ist? Warum darf man auf der Autobahn nicht rechts überholen? Warum haben wir überhaupt Rechtsverkehr, wo doch der Linksverkehr viel früher üblich war, weil das die "natürliche" Variante ist?
    Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet
    Zitieren Zitieren Dokumentation HMI-Zugriffe  

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

    Perfektionist (30.08.2010)

  4. #53
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.311
    Danke
    932
    Erhielt 3.321 Danke für 2.683 Beiträge

    Standard

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Im Schrank nennt sich dieses Vorgehen "Rangieren". […]
    Probleme, die dieses Vorgehen nicht löst: die Datenrichtung ist festgelegt. Eine Eingabe ist eine Eingabe, eine Ausgabe eine Ausgabe.
    Eine HMI-Variable im Schnittstellen-DB (als Kopie einer Prozeß-Variable) kann auch als IN/OUT-Variable von der HMI benutzt werden. Das muß man nur zusätzlich programmieren. Es kann sogar festgestellt werden, wann sich die HMI-Variable durch einen Zugriff von außen ändert und ggf. eine BeiÄnderung-Ereignisroutine aufgerufen werden.


    Zitat Zitat von Perfektionist Beitrag anzeigen
    Eingabewerte von der HMI lasse ich nicht ungeprüft auf Steuerungsvariablen schreiben. Ich möchte nicht, daß meine CPU in Stop geht oder das Steuerungsprogramm ins schleudern gerät, nur weil die HMI oder ein anderer vernetzter Teilnehmer einen ungeeigneten Wert oder im ungünstigen Moment in eine Variable schreibt.
    Du schreibst hier zwar viele Wahrheiten - nur hat das mit der Rangiererei auch in diesem Fall hier überhaupt nichts zu tun. Der ungünstige Moment hat was mit Datenkonsistenz zu tun, Wertebereiche kann das Programm prüfen, rangiert oder auch nicht rangiert. Und Wertebereichsgrenzen kann man sogar bereits in der Visu parametrieren. Zumindest bei Flex.
    Mit “ungünstiger Moment“ meine ich nicht Übertragungs-Konsistenz-Probleme, sondern wenn z.B. der Bediener ein Rezept in die Steuerung überträgt, die Bearbeitung des aktuellen Produkts aber noch nicht beendet ist oder wenn er Drehzahlen von Antrieben ändert, die nur gleichzeitig oder nur im Stillstand geändert werden sollen.
    Gut, man kann das auch einfach als Bediener-Fehler abtun. Ich versuche solche Bediener-Fehler abzufangen.

    Wertebereiche prüfen:
    In Zeiten von Vernetzung, HMI, Visu, MES, ERP, LibNodave, Fernwartung ... verlasse ich mich nicht darauf, daß nur zulässige Werte in der Steuerung ankommen. Selbst dann nicht, wenn ich die Wertebereichsprüfung an allen Datenquellen durchführen könnte. Nur die Prüfung im Steuerungsprogramm vor der Verwendung garantiert mir zulässige Werte. Und nur, wenn die vernetzte Anwendung nicht auf die original-Zielvariable schreibt sondern auf eine Zwischenvariable. Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt.


    Zitat Zitat von Perfektionist Beitrag anzeigen
    Bei mir erhält die HMI fast nie Zugriff auf die original-Steuerungsvariablen, sondern regelmäßig nur auf Kopien oder Zwischenvariablen in den Schnittstellen-DB. So ist es unerheblich, wenn die HMI durch Projektierungsfehler oder Compilierfehler auf diese Variablen schreibt.
    Sorry - also, wenn die HMI auf die falsche Variable zugreift, spielt es dann noch eine Rolle, ob rangiert oder nicht? Aber der Prozess flippt trotzdem aus, das falsche Ventil reagiert auf den Tastendruck oder gar auf eine Sollwertänderung. Da ist die Rangiererei nur eine zusätzliche Fehlerquelle. Projektierungsfehler kann ich mit Rangiererei nicht abfangen. Compilerfehler auch nicht.
    Da muß ich Dir 100% Recht geben. Da war meine Begründung allerdings zu einseitig.

    Die Benutzung von Variablen-Kopien hat bei mir noch weitere Gründe, was ich in meinem Beitrag wohl nicht ausführlich genug erwähnt habe:
    * Überprüfung/Ablehnung der Eingabewerte durch das Steuerungsprogramm
    * Übernahme der Eingabewerte zu einem der Steuerung angenehmen Zeitpunkt (z.B. bei Rezepturen)
    * Daten-Konsistenz im OB1-Zyklus trotz asynchroner HMI-Zugriffe


    Zitat Zitat von Perfektionist Beitrag anzeigen
    Da ich mir aber nicht sicher bin, ob die Daten wirklich am Zykluskontrollpunkt von der Visu in die SPS geschrieben werden
    Ich bin mir auch nicht ganz sicher, meine aber, daß die S7-400 schon immer B&B-Empfangsdaten nicht nur im Zykluskontrollpunkt in CPU-Variablen schreibt. Und ab der nächsten S7-300-Firmware-Generation V3.2 plant Siemens zur Erhöhung der Kommunikationsperformance (B&B) dies auch für S7-300 zu realisieren (projektierbares “Zeitscheibenverfahren“).
    Siemens: Neues von der Hannover Messe 2010 (pdf) (Seite 7, Danke an IBFS für den Link)

    Wenn man nun für den ganzen OB1-Zyklus gleichbleibende HMI-Variablen braucht und vor allem garantieren will, daß sich eine HMI-Variable zwischen der Prüfung und der Verwendung nicht ändert, dann muß man quasi ein eigenes Prozeßabbild der HMI-Eingabevariablen erstellen. Das geht nur, wenn die HMI nicht direkt auf die Prozeßvariable schreibt, sondern auf eine Zwischenvariable (und die hat sich in einem Schnittstellen-DB zu befinden ).

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet
    Zitieren Zitieren asynchrone HMI-Zugriffe, Daten-Konsistenz im Zyklus  

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

    Perfektionist (30.08.2010)

  6. #54
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.311
    Danke
    932
    Erhielt 3.321 Danke für 2.683 Beiträge

    Standard

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ach ja:
    Die HMI und die HMI-Animationen sind viel leichter testbar, wenn sie nicht auf die original-Variablen zugreifen, sondern auf Variablen-Kopien im Schnittstellen-DB, besonders im laufenden Betrieb. Die Variablen-Kopie im Schnittstellen-DB läßt sich ohne Auswirkungen auf das Steuerungsprogramm gut manipulieren.
    Du wiederholst Dich. Das hatten wir weiter oben schonmal. Diesmal klingt es ein wenig so, als ob Du zunächst den FB entwickelst (oder was auch immer bei Dir das Programm ist) und dann danach die Visu machst.
    Am Anfang meines Beitrages hatte ich meine Prinzipien stichpunktartig aufgelistet und dann im Verlauf des Beitrags versucht, die einzelnen Punkte ausführlich zu erläutern. Die Erläuterung für den Punkt mit der Testbarkeit ist da wirklich zu kurz geraten. Hier also ein Beispiel:

    Ich habe oft mit Siloanlagen und Verteilung von Produkten über verschiedene Wege zu tun. Die Rohrleitungs/Wege-Animation mache ich meistens erst zum Schluß, damit sie perfekt wird. Erst wenn die Aufteilung des Anlagenbildes fertig ist. Fast immer läuft die Anlage dann schon und ich kann dann nicht mehr alle Wege in echt einstellen, um die Animation zu testen. Nicht alle HMI kann man simulieren und außerdem will ich die Animation pixelgenau auf dem echten Panel oder Visu-PC sehen.

    Dadurch, daß meine HMI-Variablen nur Kopien der Prozess-Variablen sind, kann ich sehr einfach die Verbindung der HMI-Variable zur Prozess-Variable im Schnittstellen-DB unterbrechen und statt dessen beliebige Werte in die HMI-Variable schreiben, ohne den laufenden Prozess zu beeinflussen und ohne das HMI-Projekt zu ändern.

    Zitat Zitat von Perfektionist Beitrag anzeigen
    ich behaupte jetzt ganz frech das Gegenteil: ich kann einen FB mitsamt seinem IDB und der für ihn erstellten Visu-Seite völlig losgelöst von irgendwelcher Rangiererei testen.
    Kannst Du das auch im laufenden Betrieb, wenn Du das, was Du in der Visu testen willst, an der Anlage nicht schalten darfst?

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet
    Zitieren Zitieren Visu manipuliert testen im laufenden Betrieb  

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

    Perfektionist (30.08.2010)

  8. #55
    Registriert seit
    11.05.2005
    Ort
    Baden-Württemberg
    Beiträge
    673
    Danke
    113
    Erhielt 153 Danke für 124 Beiträge

    Standard

    Moin,

    meiner Meinung nach ist es selbstverständlich, dass die Siemens Visu auf die Siemens FB-Instanzen zugreift.

    Das ist Siemens Philosophie!

    WinCC und auch PCS7 sind auf der Visualisierung von Instanzen aufgebaut.
    Siemens unterstützt das durch zahlreiche Funktionen innerhalb der S7 und WinCC.

    Ich würde mal gerne so nen "von Hand angelegten Koppel-DB" sehen, der 30000 Variablen enthält und noch irgendwie übersichtlich ist...
    Das geht doch gar nicht.

    Ebenso die Animationen im Visualisierungssystem.
    Wer verknüpft 30000 Variablen von Hand???
    Das ist doch die Konsequenz von so nem Koppel-DB, oder habe ich das falsch verstanden?

    Micha
    "arbeite klug, nicht hart" - deutsches Sprichwort

  9. #56
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    meiner Meinung nach ist es selbstverständlich, dass die Siemens Visu auf die Siemens FB-Instanzen zugreift.

    Das ist Siemens Philosophie!

    WinCC und auch PCS7 sind auf der Visualisierung von Instanzen aufgebaut.
    Siemens unterstützt das durch zahlreiche Funktionen innerhalb der S7 und WinCC.

    Ich würde mal gerne so nen "von Hand angelegten Koppel-DB" sehen, der 30000 Variablen
    enthält und noch irgendwie übersichtlich ist...
    Das geht doch gar nicht.

    Ebenso die Animationen im Visualisierungssystem.
    Wer verknüpft 30000 Variablen von Hand???
    Das ist doch die Konsequenz von so nem Koppel-DB, oder habe ich das falsch verstanden?
    Leider wurde bisher zu wenig auf den Unterschied zwischen

    händisch angelegten VISU-Kopplungen (STEP7-ProTool-Flex)

    und

    mittels wizzards angelegten VISU-Kopplungen (PCS7)

    eingegangen.



    Alles, was per Hand angelegt und modifiziert wird und es keine Synchronisation
    in PCS7 Manier gibt sollten schon ordentlich dokumentiert sein.
    Da gibt es im S7-Projekt in den FC/FBs oder im Quellordner genug Kommentarfelder.
    Nur die muss man auch nutzen.

    Sobald man mit WinCC arbeitet (noch nicht ganz PCS7) dann hat man zumindest,
    wenn man AS-OS-Transfer nutzt, die schönen "grünen Wimpel" .
    Daran erkennt man, ob eine VISU-Anbindung einer Variablen vorhanden ist.

    Beim "richtigen" PCS7 ist dann alles automatisert, und da ist der
    Zugriff - z.B. auf Instanzen eines Motorbausteins ein normaler Weg.
    Da sit man dann den PCS7-Mechanismen "ausgeliefert"

    .

    Das schöne an STEP7 ist, es gibt mind. 1000 verschiedene Programmierstile.

    zwischen unnntöig aufwändig und genial einfach bis schwachsinnig ist alles dabei.

    Dadurch wird es einfach nicht langweilig

    Frank
    Grüße Frank

  10. #57
    mariob ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    23.03.2006
    Ort
    Thüringen
    Beiträge
    2.005
    Danke
    162
    Erhielt 278 Danke für 199 Beiträge

    Daumen hoch

    Öhm,
    ich lese immer noch mit, obwohl nicht ganz einfach für mich, da ich die Siemens eigenen Visualisierungen nicht kenne. Ich hätte gern soetwas, stattdessen habe ich zum Beispiel hier eine Siclimat ZLT stehen, man stößt dort sehr schnell an unüberwindbare Grenzen, wo wahrscheinlich ein Wincc gerade erst mal warmläuft.
    Wie schon beschrieben, werde ich ein Proface zur Visualisierung einsetzen, von daher ist es für mich übersichtlicher einen eigenen DB einzusetzen. Auch die Synchronisation im OB1 ist ein sehr wichtiger Aspekt, von daher gehöre ich momentan der Fraktion der GetrenntDBler an.
    Für den Fall das ich irgendwas nicht mitgekriegt haben sollte, ob nun IDB mit seinen Besonderheiten oder einem DB, der diese nicht hat, es ist für mich eigentlich nur Speicherplatz. Aus dieser Sicht ist es doch zumindest erst einmal für die Symbolik der Variable im Programm gleichgültig wo diese steht. Ich muß doch nur wissen wie ich die Speicherstelle finde, wenn ich keine Symbolik zur Verfügung habe und dann halt auch noch richtig darauf zugreifen (z.B. mit dem Proface).
    Von daher erstmal danke an alle diskutierenden, war bis hierher sehr lehrreich.

    Gruß
    Mario

  11. #58
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von mariob Beitrag anzeigen
    ....Aus dieser Sicht ist es doch zumindest erst einmal für die Symbolik der Variable im Programm gleichgültig wo diese steht.
    Ich muß doch nur wissen wie ich die Speicherstelle finde, wenn ich keine Symbolik zur Verfügung habe und
    dann halt auch noch richtig darauf zugreifen (z.B. mit dem Proface).
    ...
    Das Problem speziell bei IDBs ist ja gerade foglendes:

    Wenn es eine Adressenverbindung von der VISU zu einem IDB gibt und
    irgend eine Schnachnase den zugehörigen FB des IDBs ändert, dann
    verschieben sich innerhalb des IDB alle Adressen. Das wird u.U. bei
    WinCC und PCS7 abgefangen aber nicht bei "handgemachten" VISU-
    Anbindungen. Das ist der oben ofter zitierte Totalschaden.

    Frank
    Grüße Frank

  12. #59
    Registriert seit
    03.04.2008
    Beiträge
    6.205
    Danke
    237
    Erhielt 817 Danke für 691 Beiträge

    Standard

    Zitat Zitat von IBFS Beitrag anzeigen
    Das Problem speziell bei IDBs ist ja gerade foglendes:

    Wenn es eine Adressenverbindung von der VISU zu einem IDB gibt und
    irgend eine Schnachnase den zugehörigen FB des IDBs ändert, dann
    verschieben sich innerhalb des IDB alle Adressen. Das wird u.U. bei
    WinCC und PCS7 abgefangen aber nicht bei "handgemachten" VISU-
    Anbindungen. Das ist der oben ofter zitierte Totalschaden.

    Frank
    Das ist die eine Seite, doch die zweite ist, dass ich in der PLC prüfen will und muss, dass kein Mist von der VISU kommt.
    Es werden die Werte von der VISU gelesen und geprüft, dann ggF skaliert und dann im Programm weiter verarbeitet.
    Dann kann auch eine externe Datenbank oder Überwachungssystem oder das PLC Programm mit den Daten etwas sinnvolles anfangen.
    Das ist etwas mehr Aufwand, aber der rechnet sich.


    bike

  13. #60
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von PN/DP Beitrag anzeigen
    ... auch wenn man nicht
    weiß, warum etwas heute so-und-so gemacht wird?
    Ich hoffe, Du fühltest Dich nicht persönlich angegriffen (Du hast es gleich zweimal zitiert).

    Das mit dem nicht-Wissen war nicht speziell auf Dich gemünzt. Ich meinte damit einfach nur Regeln, die man irgendwann gelernt hat und anwendet, ohne den genauen ursächlichen Grund dafür (noch) zu wissen. Solche Regeln gibt es mehr als man denkt.

    Wer kann schon genau erklären, wie und warum sich die heute üblichen Taster- und Leuchtenfarben entwickelt haben, hält sich aber daran, weil es so üblich und teilweise sogar vorgeschrieben ist? Warum darf man auf der Autobahn nicht rechts überholen? Warum haben wir überhaupt Rechtsverkehr, wo doch der Linksverkehr viel früher üblich war, weil das die "natürliche" Variante ist?
    Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.

    Gruß
    Harald
    Da fühle ich mich nicht persönlich angegriffen, das empfinde ich als Angriff auf die gesamte Menschheit. Allerdings muss ich eingestehen, dass etwa 99% aller Menschen besser sich nach Deiner Leitlinie "tu es so, wie man es schon immer gemacht hat" richten sollten. Vielleicht sind es sogar 99,99%. Manchmal kommt es mir so vor.

    Wie ich schonmal in diesem Forum erwähnte (das ist aber - glaube ich - in den Giftschrank gewandert), wie ich also schonmal erwähnte, gehöre ich zu den Menschen, die ziemlich alles kritisch unter die Lupe nehmen und hinterfragen. Und eben davon überzeugt sind, dass es nicht nur einen Weg nach Rom gibt. Sondern derer bewährte, aber auch neuere existieren. Oder sich sogar noch neuere finden lassen. Da tue ich mir naturgemäß mit
    Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.
    sehr, sehr schwer.

    Wenn jemand also sagt: auf der Autobahn überholt man nicht rechts, so ist das Eine Regel mit Ausnahmen. Geltungsbereich: z.B. Deutschland. Nicht generell in den USA gültig (wo? keine Ahnung - die Rechtsüberholbefürworter behaupten, dass es Länder gibt, in denen auf der Autobahn rechts überholt werden darf). Ausnahme in Deutschland? Ja, gibt es: auf Autobahnen in Deutschland darf auf einer separaten Fahrspur (abgetrennt durch die dicken Fahrbahnmarkierungen) rechts überholt werden. Wobei: ob das eine Ausnahme ist, empfindet jeder anders. Wer diese Ausnahmeregel kennt, wird es nicht als Ausnahme empfinden.

    Auch den Rechtsverkehr kann oder sollte man sogar hinterfragen. Falls mal jemand auf die Idee kommt, die Verkehrsregeln weltweit zu harmonisieren. Da ist es vielleicht ganz hilfreich zu wissen, dass der Einbauort des Lenkrades (mein Großvater legte viel Wert darauf, dass das Ding nicht als Steuer bezeichnet wurde) mit einer sachlichen Begründung überhaupt nichts zu tun hat. Sondern damit, wo die Herrschaften sitzen. Wer also mit der Heuristik "der, der den Lenker links eingebaut hat, wird sich dabei schon was gedacht haben" zu Werke geht, begeht in meinen Augen ein Verbrechen.

    Zur Sache: mein Horizont ist ganz klar auf Protool, Flexible und 300er beschränkt. In dieser kleinen, feinen Welt erlaube ich mir (kann ich mir erlauben?) ohne zu rangieren direkt mit der HMI in Instanzen zuzugreifen. Ausnahmen bestätigen auch hier die Regel: selbstverständlich muss auch ich mir Gedanken über Datenkonsistenz machen, also ggf. mal eine Visu-Variable zwischenparken, bevor ich sie im Programm weiterverwende. Allerdings muss die dann (bei mir) nicht extra in einem Global-DB stehen. Eine Welt, so wie Du sie schilderst, wo nichts festgelegt ist, nichtmal, dass mit S7 gearbeitet wird, verlangt wie selbstverständlich nach bestens dokumentierten Schnittstellen, nicht nur zwischen HMI und Steuerung.

Ähnliche Themen

  1. Antworten: 4
    Letzter Beitrag: 21.09.2011, 13:45
  2. Problem mit Verständniss für Programmstruktur
    Von Peter_AUT im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 05.08.2011, 19:15
  3. Generelle Frage Programmstruktur OB's
    Von hank12 im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 29.06.2009, 11:47
  4. Struktur aus DB in Programmstruktur kopieren
    Von gnikre im Forum Programmierstrategien
    Antworten: 4
    Letzter Beitrag: 05.06.2007, 09:56
  5. Antworten: 5
    Letzter Beitrag: 02.03.2005, 11:02

Lesezeichen

Berechtigungen

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