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

Seite 5 von 10 ErsteErste ... 34567 ... LetzteLetzte
Ergebnis 41 bis 50 von 97

Thema: Programmstruktur Step7

  1. #41
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Du differenzierst nichtmal danach, ob der Zugriff quer oder per Visu verachtenswert ist. Stelle bitte dar, warum nicht nur der Querzugriff Scheisse ist, sondern auch der Visu-Zugriff.
    Das habe ich doch schon getan:
    Zitat Zitat von Paule Beitrag anzeigen
    Lesen aus der Instanz, klar warum nicht.
    Schreiben absolutes "no go", da die Daten nicht richtig gesichert werden können.
    Sprich wird der Instanzdatenbaustein frisch generiert, da der FB erweitert wurde, müssen am Panel die Daten neu eingegeben werden.
    Das geht ja wohl überhaupt nicht.
    Hallo Perfektionist, das was du hier schreibst macht deinem Namen nicht alle Ehre.
    Mit so einem Namen erwartet jeder absolut perfekte unantastbare Programmierung.
    Zitat Zitat von Helmut_von_der_Reparatur Beitrag anzeigen
    Sind eigentlich immer an jeder Anlage zig Programmierer mit allen erdenk-
    lichen Schnittstellen nach außen oder gibt es den Fall auch das nur einer
    daran Arbeitet, ohne Schnittstellen. Ich denke da so an überschauliche
    Maschinen, nicht immer Atomkraftwerke.
    Sollte an dieser Stelle nicht kommen: "Auch die Instandhalter müssen mit der Anlage klar kommen."
    OK, als nicht genanntes Argument lasse ich gelten das nicht gleich jeder Instandhalter FB's erweitert.
    Aber gut das wir mal darüber gesprochen haben.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

  2. #42
    Registriert seit
    13.10.2007
    Beiträge
    12.038
    Danke
    2.789
    Erhielt 3.273 Danke für 2.159 Beiträge

    Lächeln

    Zitat Zitat von Paule Beitrag anzeigen

    Sollte an dieser Stelle nicht kommen: "Auch die Instandhalter müssen mit der Anlage klar kommen."
    OK, als nicht genanntes Argument lasse ich gelten das nicht gleich jeder Instandhalter FB's erweitert.
    Aber gut das wir mal darüber gesprochen haben.
    aber instandhalter können doch erweitern bzw
    warten. Irgendwann kommst du auch dahin,
    ich habe auf jeden Fall Geduld mit dir
    Geändert von rostiger Nagel (23.08.2010 um 00:24 Uhr)
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  3. #43
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.192
    Danke
    925
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ja, ich greife zu. Ich greife in einer Instanz mit der HMI so ungeniert zu, wie in einer SPS im Merkerbereich.
    Das überrascht mich dann doch gehörig, wo Du doch so oft von Kapselung schreibst und Querzugriffe auch ablehnst.
    Fast möchte ich Dir vorschlagen, unsere Nicknames zu tauschen. Mir deucht, Deiner passt besser zu mir

    Schließt man das Kabel vom Start/Stop-Taster samt Leuchtmelder direkt am Hauptschütz des Antriebs an oder benutzt
    man Hilfskontakte und setzt im Schaltschrank eine extra Klemmleiste?
    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?

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.
    Ich finde Zugriffe der HMI auf Instanz-DB als absolutes No-Go, und zwar aus praktischen Erfahrungen.
    Ich hatte in meinem Programmiererleben auch mal die Phase, wo ich HMI-Zugriffe auf IDB in Ordnung fand (ist doch
    so quick und easy), doch spätestens bei nachträglichen Änderungen an diesen Programmen wurde ich dafür mit teils
    erheblicher Mehrarbeit bestraft.

    Gründe für meine Meinung:
    * die Problematik der Initialisierung von IDB bei deren Neu-Generierung wurde schon von Paule genannt
    * manchmal kann das HMI-Projekt nicht geändert werden oder die Änderung ist sehr aufwendig
    * ich möchte bei Programmänderungen nur eine (zusammenhängende) Schnittstelle zur HMI beachten müssen
    * mein Steuerungsprogramm soll Vorrang vor Eingriffen der HMI haben
    * keine Eingaben/Bedienungen der HMI werden ungeprüft oder unverknüpft im Steurungsprogramm verarbeitet
    * die HMI und die HMI-Animationen sind leichter testbar, wenn sie nicht auf die original-Variablen zugreifen

    Es kommt öfter vor als gedacht, daß Hersteller einer Anlage wegen schlechtem Projektmanagement nicht mehr wissen,
    welche HMI-Projektversion aktuell in der Anlage ist oder das aktuelle HMI-Projekt garnicht mehr besitzen. Und noch
    öfter, daß sie für ein paar simple Adress-Anpassungen exorbitante Preise verlangen.
    In diesen Fällen dürfen also Programmänderungen auf keinen Fall Einflüsse auf die HMI haben.
    Wenn ich dann IDB nicht ändern darf, weil die HMI wahrscheinlich direkt darauf zugreift, dann möchte ich regelmäßig
    jemanden würgen ...

    Doch auch wenn das HMI-Projekt vorhanden ist, kann eine notwendige Änderung an IDB (besonders bei Multi-Instanzen)
    erhebliche Arbeit am HMI-Projekt nach sich ziehen. Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert.
    Dann müssen alle nötigen Adressänderungen per Hand ausgeführt werden. Und nicht jede HMI-Software ist so einfach
    aufgebaut wie ProTool.
    Immer ist aber zumindest eine Neu-Generierung des HMI-Projektes nötig und es muß (meist im laufenden Betrieb) auf
    alle betroffenen Panele und Visualisierungen aufgespielt werden. Das können auch mal 10 OP7 sein, wo man mit dem
    Notebook zu jedem einzelnen OP hinlaufen muß, um das Projekt aufzuspielen. Dazu kommt der Organisationsaufwand,
    weil die noch nicht upgedateten Panele auf keinen Fall benutzt werden dürfen oder die Panele müssen gar vorab alle
    ausgeschaltet werden.

    Diese viele Arbeit ist nicht nötig, wenn die HMI ausschließlich über wenige Schnittstellen-DB auf die Steuerung
    zugreift und niemals über IDB. Ich betrachte die HMI-Schnittstellen-DB als Rangier-Klemmleiste zur HMI.

    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. In den meisten HMI-ES die ich kenne, kann man Prozessvariablen
    nicht als read-only deklarieren. Nur in Wonderware Intouch kann man ein entsprechendes Häkchen setzen, doch auch
    da wird dieses Feature sogut wie nie von anderen Programmierern genutzt, weil das zusätzliche Arbeit macht.

    (Hier muß ich allerdings erwähnen, daß man bei Simatic-CPU alle Variablen generell nicht vor Schreibzugriffen von
    außen schützen kann. Einziger sicherer Schutz: nicht vernetzen!)

    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.

    Auch Rezepturen lasse ich nicht direkt in die Zielvariablen schreiben, sondern immer nur in einen Datensatz-Puffer.
    Bei mir bestimmt das Steuerungsprogramm, ob und wann es die neuen Rezepturwerte übernimmt.

    Tastenbits von der HMI werden immer wie normale Hardware-Taster im Programm verknüpft und zusätzlich zu Beginn des
    ersten OB1-Zyklus und am Ende des OB1 gelöscht, weil nicht sicher ist, daß auch der Tasten-Release-Code von der HMI
    in der Steuerung ankommt.

    Ausnahmen von diesen Prinzipien kommen vor, haben dann spezielle Gründe, bestätigen aber die Regel.

    Weil ich nicht bei jedem Projekt von vornherein sagen kann, ob die Einhaltung meiner Prinzipien nun für dieses
    spezielle Projekt essentiell ist und was später noch draus wird, halte ich es eben immer so.
    Ich sehe diese Prinzipien als einen wesentlichen Baustein dafür, daß die von mir programmierten Anlagen in aller
    Regel jahrelang ohne Steuerungsprobleme und immer berechenbar funktionieren.

    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.

    Gruß
    Harald

  4. Folgende 11 Benutzer sagen Danke zu PN/DP für den nützlichen Beitrag:

    bike (23.08.2010),crash (23.08.2010),geza (15.09.2010),IBFS (23.08.2010),mariob (24.08.2010),marlob (30.08.2010),Paule (23.08.2010),RGerlach (23.08.2010),rostiger Nagel (23.08.2010),Shiva (30.09.2010),SinusQuadrat (24.09.2010)

  5. #44
    Registriert seit
    13.10.2007
    Beiträge
    12.038
    Danke
    2.789
    Erhielt 3.273 Danke für 2.159 Beiträge

    Standard

    Harald, ist mal wieder der einzigste der es so erklären kann, das ich es einsehen
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  6. #45
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    Der Erklärung von Harald ist nichts mehr hinzu zufügen.
    Es ist nicht hoch genug anzurechnen, dass sich jemand soviel Zeit nimmt, um dies so ausführlich zu erklären.




    bike

  7. #46
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard

    Zitat Zitat von Helmut_von_der_Reparatur Beitrag anzeigen
    Harald, ist mal wieder der einzigste der es so erklären kann, das ich es einsehen
    Ja, mir hast es ja wieder mal nicht geglaubt.
    Aber wie bike auch schon sagt, Harald hat es auch echt ausführlich erläutert.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

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

    Standard

    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?
    Erstensmal sollte man jederzeit wissen was man tut. Und Prinzipien aus dem Bereich der Elektrik müssen nicht zwangsläufig auf den Bereich Programmierung übertragbar sein.

    Nun steht die These im Raum, man müsse (bzw. solle besser) die Ein- und Ausgaben der HMI über definierte Schnittstellen abwickeln. D.h., die Visu-Daten eines IDB müssen an dessen Bausteinschnittstelle als IN- und OUT-Parameter gelegt werden (da Siemens dafür keinen eigenen Bereich dediziert). Im Schrank nennt sich dieses Vorgehen "Rangieren". In der SPS stehen für diesen Zweck Merker und/oder Global-DB zur Verfügung. Die HMI soll demnach mit diesen Global-Daten kommunizieren und diese Globaldaten werden an die Bausteinschnittstellen verschaltet. Man korrigiere mich, falls diese Darstellung unzutreffend sein sollte.

    Vorteil: es ist absolute (was auch immer nun "absolut" heissen soll) - also, es ist absolute Kapselung gegeben.

    Das bringt mit sich: man ist nicht festgelegt auf eine bestimmte Visu, die symbolische Verbindung zum IDB fällt weg, die Methode ist das, was sie sein soll: eine BlackBox, die von ihren inneren Abläufen/Strukturen nichts preis gibt (bzw. nichts preis zu geben braucht).

    Probleme, die dieses Vorgehen nicht löst: die Datenrichtung ist festgelegt. Eine Eingabe ist eine Eingabe, eine Ausgabe eine Ausgabe. Die Änderung an einem IN/OUT-Parameter kann zu unerwarteten Ergebnissen führen, wenn der Visu-Zugriff nicht am Zykluskontrollpunkt stattfindet. Ich kann es zur Zeit nicht belegen,bin jedoch der Meinung, dass der Zugriff der Visu vollständig asynchron zum SPS-Zyklus abläuft (mal s7-300 und ein WinCE5-Panel mit DP-Kommunikation vorausgesetzt).

    Ein weiterer Nachteil ist, dass nicht auf den ersten Blick erkennbar ist, welche Koppelvariable zu welcher Methode gehört. Das Symbol in der (Flex-)Visu lautet dann nicht "Anlage_Instanz".Klappe_Instanz.Umschaltparameter, sondern eben nur "MW200". Oder "A_Kl_UmschP". Oder "KoppelDB".Anlage_Instanz.Klappe_Instanz.Umschaltparameter. Inclusive Datenverlust, wenn ich den Koppel-DB umstrukturiere.

    Ich möchte mal Haralds Text nun durchgehen:
    ...
    * manchmal kann das HMI-Projekt nicht geändert werden oder die Änderung ist sehr aufwendig
    ...
    Es kommt öfter vor als gedacht, daß Hersteller einer Anlage wegen schlechtem Projektmanagement nicht mehr wissen, welche HMI-Projektversion aktuell in der Anlage ist oder das aktuelle HMI-Projekt garnicht mehr besitzen. ... In diesen Fällen dürfen also Programmänderungen auf keinen Fall Einflüsse auf die HMI haben.
    Wenn ich dann IDB nicht ändern darf, weil die HMI wahrscheinlich direkt darauf zugreift, dann möchte ich regelmäßig jemanden würgen ...
    Mein lieber Harald, da ist ja die Ursache für Deinen Würgereiz ja nicht schlechter Programmierstil. Aber wer schlechtes Projektmanagement pflegt wird wohl auch eher zufällig seine Anlage zum Laufen gebracht haben. Oder mit voller Absicht dieses Zustand herbeigeführt haben, um dann bei einer Pipifax-Änderung reichlich zulangen zu könen.

    * ich möchte bei Programmänderungen nur eine (zusammenhängende) Schnittstelle zur HMI beachten müssen
    Meinst Du einen Programmbaustein oder ein Gesamtprogramm (also den gesamten Ablauf in einer SPS)?

    * mein Steuerungsprogramm soll Vorrang vor Eingriffen der HMI haben
    * keine Eingaben/Bedienungen der HMI werden ungeprüft oder unverknüpft im Steurungsprogramm verarbeitet
    Dazu ist keine Schnittstelle nötig. bestenfalls hilfreich.

    * die HMI und die HMI-Animationen sind leichter testbar, wenn sie nicht auf die original-Variablen zugreifen
    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.

    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.

    Immer ist aber zumindest eine Neu-Generierung des HMI-Projektes nötig und es muß (meist im laufenden Betrieb) auf alle betroffenen Panele und Visualisierungen aufgespielt werden. Das können auch mal 10 OP7 sein, wo man mit dem Notebook zu jedem einzelnen OP hinlaufen muß, um das Projekt aufzuspielen. Dazu kommt der Organisationsaufwand, weil die noch nicht upgedateten Panele auf keinen Fall benutzt werden dürfen oder die Panele müssen gar vorab alle ausgeschaltet werden.
    Auch das ist kein spezifisches Problem, das durch den direkten Zugriff auf Instanzdaten entsteht. Erstens ist mal nach Änderung einer Instanz grundsätzlich ein CPU-Stopp (oder mindestens mal ein Neuanlauf des betroffenen Prozesses) notwendig, da S7 nicht in der Lage ist, die aktuellen Werte einer Instanz in die geänderte Instanz zu übernehmen. Wäre S7 in der Lage, so wären auch entsprechende Mechanismen denkbar, die die Visu nutzen könnte, sich auf sich verändernde Adresslisten einzustellen. Die zehn OP7 sind wohl heute kein stichhaltiger Grund mehr. Ein einziges TP277, das temporär nicht korrekt arbeitet, jedoch schon.

    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.

    Nur in Wonderware Intouch kann man ein entsprechendes Häkchen setzen,
    Zugegeben: mein Erfahrungshorizont ist Protool V2 bis V6 und Flexible. Und bei Flex funktionierte die Symbolanbindung zugegebenermaßen auch nicht vom ersten Tag an so, wie es zuletzt in PT funktionierte.

    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.

    Auch Rezepturen lasse ich nicht direkt in die Zielvariablen schreiben, sondern immer nur in einen Datensatz-Puffer. Bei mir bestimmt das Steuerungsprogramm, ob und wann es die neuen Rezepturwerte übernimmt.
    Ich hatte bis jetzt noch nicht den Fall, dass ich sämtliche Parameter auf einmal in die Steuerung, sprich: "konsistent", laden musste. Das kann notwendig sein. Ist es jedoch (bei mir) in aller Regel nicht. Da meine Maschinen in der Rüstphase stehen, könnte genausogut jemand einen Zettel mit den neuen Parametern nehmen und diesen in die Steuerung (Visu) reinhacken.

    Tastenbits von der HMI werden immer wie normale Hardware-Taster im Programm verknüpft und zusätzlich zu Beginn des ersten OB1-Zyklus und am Ende des OB1 gelöscht, weil nicht sicher ist, daß auch der Tasten-Release-Code von der HMI in der Steuerung ankommt.
    Ich verwende hierzu vorzugsweise Merker, da diese die meiste Ähnlichkeit zum PAE besitzen. Da ich mir aber nicht sicher bin, ob die Daten wirklich am Zykluskontrollpunkt von der Visu in die SPS geschrieben werden, verwende ich gerne eine Flankenauswertung. Ganz sicher ist jedoch, dass der Release-Code nie ankommt, wenn man während des Tastendrucks einen Stecker vom Panel abzieht. Aber auch hierfür brauche ich nicht zu rangieren. Wenn ich den Befehlsmerker jedoch an den Eingang eines FB parametriere, so kann ich wenigstens für die Instanz sicher sein, dass sich der Befehl während der Abarbeitung des FB nicht ändert.

  9. Folgende 3 Benutzer sagen Danke zu Perfektionist für den nützlichen Beitrag:

    Jochen Kühner (24.08.2010),PN/DP (30.08.2010),rostiger Nagel (23.08.2010)

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

    Standard

    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. Bei mir geht das mehr Hand in Hand. Als Beispiel mag da mal ein Kartonierer dienen: der zerfällt z.B. in einen FB Einleger, der in drei Instanzen aufgerufen wird, in einen FB Produktabruf und -verfolgung, in einen FB Leimung, der auch zwei bis vier Instanzen hat. Jede der drei Instanzen der Einleger hat eine Gruppe von Bildern, die diese visualisieren. Die Produktverfolgung ebenso, und jede Leimdüse auch. Die Programmentwicklung erfolgt also: FB schreiben, Instanzen festlegen, Visubilder machen. Nächsten FB schreiben, IDB machen und Visu dazu. uswusf.

    Noch ein weiterer Einleger gefällig?
    geht so: Projekt kopieren. IDB auf freie Nummer schieben. Visu mit den/der verschobenen DB-Adressen/-Nr. generieren. Der Instanz einen weiteren (neuen) Namen geben. Jetzt die Visu nochmals neu generieren. Dann die geschobenen Objekte ins Ursprungsprojekt reinkopieren. Rangieren ist da nur lästig. Und wenn es unbedingt sein muss, dann kann man ja doch noch die Visu in den IN/OUT-Bereich legen.

    Ich sehe diese Prinzipien als einen wesentlichen Baustein dafür, daß die von mir programmierten Anlagen in aller Regel jahrelang ohne Steuerungsprobleme und immer berechenbar funktionieren.
    Dann geb ich halt meinem Erfolg auch noch recht: gerade erst habe ich eine zehn Jahre alte Steuerung (von mir) umgeändert. Mit so ekelhaften Dingern wie zwei OP7 drin. Ich musste doch tatsächlich zu jedem persönlich hinlaufen und hatte schon einen Riesenschreck bekommen, ob ich denn überhaupt diese RS232-Datenleitung dafür dabei hätte. Protool6 hat erstmal eine neue Firmware übertragen. Bei einem zwei Jahre alten Flex-Projekt hätte mir das Schweissperlen in die Stirn getrieben. Aber die Hochrüstung von PT5 auf PT6 war schon immer problemlos. Ich hab nichtmal zuvor Prosave angeworfen (Rückbau wäre eh nicht möglich gewesen). Damals vor zehn Jahren hab ich auch noch ein wenig anders programmiert. Da gab es tatsächlich noch einen Globaldatenbaustein für die Servicebedienung, die vom OP7 ausgeht. Das war damals gut ausgedacht - in Anlehnung an S5-Zeiten. Ist heute besser ausgedacht. Will sagen: auch ich kann auf Erfolge zurückblicken. Allerdings: wenn ich lese:
    ... auch wenn man nicht weiß, warum etwas heute so-und-so gemacht wird?
    dann muss ich sagen: man sollte wissen, warum man gestern etwas so und heute anders macht. Und wer eine Sache schon immer soundso gemacht hat sollte dennoch andere Möglichkeiten gelten lassen. denn:
    Ausnahmen von diesen Prinzipien kommen vor, haben dann spezielle Gründe, bestätigen aber die Regel.
    Und
    Weil ich nicht bei jedem Projekt von vornherein sagen kann, ob die Einhaltung meiner Prinzipien nun für dieses spezielle Projekt essentiell ist und was später noch draus wird, halte ich es eben immer so.
    So, ich machs halt anders. Jeder kann es für seinen Teil rechtfertigen. Dem TE wird es nicht viel nutzen.
    Zitieren Zitieren Fortsetzung  

  11. Folgende 2 Benutzer sagen Danke zu Perfektionist für den nützlichen Beitrag:

    PN/DP (30.08.2010),rostiger Nagel (23.08.2010)

  12. #49
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard

    Da ich der erste war der für die andere Fraktion eintrat, möchte ich mich kurz zur Sache melden
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Ein weiterer Nachteil ist, dass nicht auf den ersten Blick erkennbar ist, welche Koppelvariable zu welcher Methode gehört.
    Warum denn das? Auch in einem Global DB kann man Strukturieren.
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Das Symbol in der (Flex-)Visu lautet dann nicht "Anlage_Instanz".Klappe_Instanz.Umschaltparameter, sondern eben nur "MW200".
    Das macht ja hoffentlich niemand, macht ja auch keinen Sinn.
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Oder "A_Kl_UmschP". Oder "KoppelDB".Anlage_Instanz.Klappe_Instanz.Umschaltparameter. Inclusive Datenverlust, wenn ich den Koppel-DB umstrukturiere.
    Datenverlust durch Umstrukturierung, in Zeiten der symbolischen Programmierung und der Verwendung von UDT's?
    Wohl kaum!
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Erstens ist mal nach Änderung einer Instanz grundsätzlich ein CPU-Stopp (oder mindestens mal ein Neuanlauf des betroffenen Prozesses) notwendig
    Falsch, wenn du die Reihenfolge einhältst ist es im laufenden Prozess möglich.
    Instanz-DB > FB > aufrufender Baustein.
    In dieser Reihenfolge markieren und übertragen.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

  13. #50
    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 Paule Beitrag anzeigen
    Datenverlust durch Umstrukturierung, in Zeiten der symbolischen Programmierung und der Verwendung von UDT's?
    Wohl kaum!
    Ändere Deinen UDT und schau mal, was mit den Aktualdaten in Deinem DB passiert.

    Zitat Zitat von Paule Beitrag anzeigen
    Falsch, wenn du die Reihenfolge einhältst ist es im laufenden Prozess möglich.
    Instanz-DB > FB > aufrufender Baustein.
    In dieser Reihenfolge markieren und übertragen.
    Ändere in Deinen Deklarationen einen Datentyp und es hat sich ausgereihenfolgt. Füge einen IN-Parameter hinzu und es hat sich ausgereihenfolgt. Ändre die Deklaration eines FB, den Du im FB als Multiinstanz aufrufst und es hat sich ausgereihenfolgt.

    Tu bitte nicht so, als ob etwas, was gelegentlich funktioniert, immer funktionieren würde. Ich geb jetzt auch zu, dass ein Baustein, der einen FB als Multiinstanz verwendet, nicht gekapselt ist. Falls Du das überhaupt bemerkt hättest

Ä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
  •