"Saubere" Programme

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

da muss ich doch auch mal was zu sagen.

1. Was mir viel mehr auf den Sack geht, ist dass Programme nur halb-fertig abgeliefert werden. Tritt ein Fehler beim Ablauf auf heisst es:" Tja, da muss man dann halt alle Teile entnehmen und von vorne anfangen". Das gilt sogar manchmal für das öffnen von Schutztüren.
Bei manchen Anlagen ist das jedes mal ein grosser Aufwand alle Teile zu entnehmen und komplett bei 0 anzufangen.
Ja, es kostet Zeit auch mal 3 Züge im voraus zu denken...


2. Mindestens für alle Sensoren hat es Fehlermeldungen zu geben, damit der Bediener auch erkennen kann warum jetzt nix mehr geht.

3. Es müssen Verrigelungen gegen Bedienfehler programmiert sein. D.h. es darf auch (oder gerade da) im Handbetrieb nicht möglich sein etwas kaputt zu fahren.

Das meiste andere wurde ja schon geschrieben. Was ich aber nicht nachvollziehen kann, ist die Abneigung von aussen auf Instanz-DBs zuzugreifen.
Ich arbeite z.B. mit einem Schrittketten-Baustein. Es ist für mich unsinnig, z.B. die Info welcher Schritt gerade aktiv ist, über out auf Merker oder sowas zu legen. Wenn ich von Aussen schreibe:

u #Kette.schrittaktiv[1]

ist das für mich eindeutig und 1000 mal besser als nochmal Merker zu verbraten, die dann an den Ausgang des FB gepackt werden, und die ja auch erstmal alle beschriftet werden müssen.
Solange das ganze symbolisch angezeigt wird ist doch alles OK. Blöd ist nur wenn man z.B. als Bool deklarierte Variablen als word oder so anspricht.
Und leider hab ich gerade so einen Fall, weil Wincc-Flexible bei den Meldungen nur Word-Variablen haben will. Bei Pro-Tool hab ich nen DB aus Bool-Arrays gehabt, die schon "richtig" gedreht waren. So konnte man die Meldungen symbolisch adressieren, und konnte ohne nachdenken sehen, dass das Bit "Meldungen.Meldung1_8[3]" eben die Meldung 3 in Pro-Tool ist. Ablsolute Programmierung ist nunmal doof für die Lesbarkeit. Mal gucken was man da noch machen kann...

Ansonsten versuche ich Bausteine zu erstellen, die ich immer wieder verwenden kann, und arbeite dann mit Multiinstanzen. Das nervt manchmal beim programmieren, wegen "Zugriffe aktualisieren", aber wenn die Abläufe mal drin sind...
1 Baustein für Schrittketten
1 Baustein für Aktoren (für 5/2-,5/3 Wege oder Achsen natürlich andere)
, die alles enthalten was Freigaben, Störungen, Hand und Automatikbetrieb betreffen, und das ganze ggf. als Multiinstanz in den Baustein der entspechenden Station.
Schon ist so ein Station mit wenigen Mausklicks und Copy&Paste programmiert.
Servos usw haben natürlich ihren eigenen Baustein, an den die Variablen (Freigaben, Positionen, Geschwindigkeiten usw) übergeben werden.


Auch für mich ist das Umladen von Ein- und Ausgängen No-Go. Seh ich gar keinen Sinn drin, und verursacht nur noch mehr Tipp-Arbeit beim Beschriften von Variablen. Nach meiner Erfahrung lassen aber Leute die so programmieren eh die Hälfte der Symbolik weg.

So...

nun mal gucken ob ich auch mit Wincc Flex noch das symbolische programmieren der Fehlermeldungen hin bekomme.

Torsten
 
Torsten05 schrieb:
...
Was ich aber nicht nachvollziehen kann, ist die Abneigung von aussen auf Instanz-DBs zuzugreifen.
...
Zum Vergrößern anklicken....

Das Stichwort heißt Kapselung.

Ein Instanz-DB enthält Lokaldaten einer Funktion. Und die Datenübergabe erfolgt auf dem Dienstweg an der Schnittstelle der Funktion.

Dass es bei S7 möglich ist, diesen Dienstweg zu umgehen, mag wohl einen positiven Einfluß auf die Programmlaufzeit haben und wohl auch sonst Ressourcen sparen.

Aber: wenn sich die Maschine in Module zerlegen lässt, so kann das Programm mittels Kapselung so gestaltet werden, dass man erkennen kann, welches Modul mit welchem Modul welche Signale austauscht. Das erleichtert dann das Erweitern oder den Rückbau von Modulen der Maschine. Und auch die Fehlersuche könnte einfacher sein ...

Und der absolute Killer: ändere die Instanz - und alle Querzugriffe müssen aktualisiert werden :twisted:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Perfektionist schrieb:
Und der absolute Killer: ändere die Instanz - und alle Querzugriffe müssen aktualisiert werden :twisted:
Zum Vergrößern anklicken....

Stimmt nicht ganz ...
Greifst du auf die Instanz-Daten mit einer projektierten Visu zu (Beispiel von Torsten05), dann werden alle Variablen mit aktualisiert. Du musst die Visu nur neu generieren ...

Gruß
LL
 
Hi,


Perfektionist schrieb:
Das Stichwort heißt Kapselung.

Ein Instanz-DB enthält Lokaldaten einer Funktion. Und die Datenübergabe erfolgt auf dem Dienstweg an der Schnittstelle der Funktion.

Dass es bei S7 möglich ist, diesen Dienstweg zu umgehen, mag wohl einen positiven Einfluß auf die Programmlaufzeit haben und wohl auch sonst Ressourcen sparen.

Aber: wenn sich die Maschine in Module zerlegen lässt, so kann das Programm mittels Kapselung so gestaltet werden, dass man erkennen kann, welches Modul mit welchem Modul welche Signale austauscht. Das erleichtert dann das Erweitern oder den Rückbau von Modulen der Maschine. Und auch die Fehlersuche könnte einfacher sein ...

Und der absolute Killer: ändere die Instanz - und alle Querzugriffe müssen aktualisiert werden :twisted:
Zum Vergrößern anklicken....

Funktionen haben keine Instanz(Daten -> Zugriff von Aussen Sinnlos), und bei Funktionsbausteinen die Instanzdaten haben, liegen die Ein-Ausgabedaten nicht in den Lokaldaten, sondern der Temp-Bereich. Auf den von Aussen zuzugreifen macht eh keinen Sinn, da die Daten dann schon nicht mehr gültig sind. Wir sind ja noch bei einer SPS, und nicht bei Hochsprachen.
Solange du bei der symbolischen programmierung bleibst, ist das alles kein Problem.
Ja, du kannst beim ändern Probleme verursachen. Das gilt aber für alle Variablen.
Kapselung: Wie gesagt: SPS. Ich greife auch nicht grundsätzlich auf Instanzdaten zu, aber es bietet sich in diesem Fall einfach an. Ausser dem teilen sich der aufrufende und der aufgerufene FB ja den gleichen DB...Multiinstanz.

Schlimmer kann der Zugriff auf globale Daten in einem FC sein, denn man als "abgeschlossen" betrachtet. Dort darf man natürlich nur mit "Lokaldaten" arbeiten. Versteht sich aber von selbst, da die Bausteine sonst nicht universell nutzbar sind.

Sehr schön ist auch indirekte Adressierung in Multiinstanzen, wenn man das AR2 nicht beachtet.:D

Aber es ist beruhigend zu wissen, das es Leute gibt die beim SPS-Programmieren noch strengere Maßstäbe bei der Programmstruktur anlegen, als ich das tue.

Torsten

Edit: Der letzte Satz ist mein Ernst, und gar nicht böse gemeint. Könnte aber so rüberkommen, deshalb: Bitte nicht falsch verstehen. Ich ärgere mich deshalb so über fehlende Strukturen weil ich offensichtlich zu doof bin, nach dem 8 mal "Gehe zu Verwendungstelle" noch zu wissen, was ich eigentlich machen wollte...
Dazu fällt mir ein Spruch ein, der mein Ausbilder hin und wieder mal gebracht hat:" Nur ein Genie kann im Chaos arbeiten. Du willst Dich doch nicht mit Albert Einstein vergleichen, ODER!?!" :)
 
Zuletzt bearbeitet:
Hallo Torsten,

im Prinzip hat Perfektionist schon alles gesagt,
aber was meinst du mit:

Torsten05 schrieb:
Hallo,

Ich arbeite z.B. mit einem Schrittketten-Baustein. Es ist für mich unsinnig, z.B. die Info welcher Schritt gerade aktiv ist, über out auf Merker oder sowas zu legen. Wenn ich von Aussen schreibe:

u #Kette.schrittaktiv[1]

ist das für mich eindeutig und 1000 mal besser als nochmal Merker zu verbraten, die dann an den Ausgang des FB gepackt werden, und die ja auch erstmal alle beschriftet werden müssen.
Torsten
Zum Vergrößern anklicken....

Der Zugriff mit "#" ist doch kein Zugriff von "aussen", oder wie verstehst du das?

Wenn du nicht alle Bausteine als Quellen vorliegen hast, krachts doch mit hoher Wahrscheinlichkeit, sobald die Instanzdaten einmal geändert werden.
Braucht nur mal einer auf "Absolut-Adressen" eingestellt haben.

Und bei einem "Fremd-SPS-Programmierer" als Qualitätskriterium würd ich mich auf sowas nicht einlassen. Da ist der spätere Ärger vorprogrammiert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das hier gepostete Codeschnipsel kann man vermutlich als Grenzfall für den Zugriff auf die Instanz sehen.

Hier mal die (vermutlich) im Hintergrund stehende Struktur:

OB1:
Call FB10, DB10 //SK Verwaltung

FB10:
Stat:
- Kette Typ: Schritt_FB(FB100)

Call #Kette
In .. Out

U #Kette.Schritt[1]

Mfg
Manuel
 
kiestumpe schrieb:
Hallo Torsten,

im Prinzip hat Perfektionist schon alles gesagt,
aber was meinst du mit:



Der Zugriff mit "#" ist doch kein Zugriff von "aussen", oder wie verstehst du das?
Zum Vergrößern anklicken....

Nun wie ich schon sagte: Multiinstanz. Beispiel:
Station 1 ist ein Teil der Maschine. Wird programmiert im FB10.
Alles was mit der Station zu tun hat kommt in die Instanzdaten des FB10(DB10...).
Nun benötige ich eine Schrittkette.
Dafür gibt es den Baustein FB5. Dieser FB5 hat nun keinen eigenen DB, sondern ist im Kopf des FB10 deklariert, als Type "FB5".
Der Name der Multiinstanz ist Kette. In dem Baustein (FB5) gibts halt eine Schrittkette, bei dem die Eingangssignale (IN-Variablen des FB 5,Kette) wie z.B. wann ein Schritt erfüllt ist, Reset, Freigabe usw. ausgewertet werden.

Nun KÖNNTE ich die Ausgänge des FB5 als Out deklarieren (mache ich bei einigen Variablen auch, aber nicht bei den Schritt-"Merkern"), oder aber direkt auf die Instanzdaten von "Kette" zugreifen.
Sonst müsste ich im FB5 als Out 16X SchrittAktiv ... deklarieren. An diesen Ausgang wiederum müsste ich 16 bool anschalten, die ich auch erstmal deklarieren und beschriften muss, die ich aber sowieso nur im FB10 benutze.

Wenn du nun auf z.B. SchrittAktiv[3] zugreifen willst, schreibst du (geht nur im FB10!)

u #Kette.Schrittaktiv[3]

Möchtest du dagegen auch im FB20 darauf zugreifen müsstest du schreiben.
db10.Kette.Schrittaktiv[3] (Wenn db10 der iDB von FB10 ist)

Das mache ich aber nicht, da ja die Station nur im FB10 behandelt wird. Was ich dann Global brauche, mache ich nicht mehr so, sondern über Global-DB oder Merker.
Das funktioniert ohne Probleme, auch wenn du was im Kopf änderst. Die Änderung wird sofort übernommen, überall wo du das symbolisch im FB10 programmiert hast. Da du dich ja im FB10 befindest, arbeitest du ja eigentlich immer noch "lokal", wegen gleichem iDB. Du musst dann allerdings mit dem Punktoperator arbeiten, da "Kette" ja Daten des Typs FB5 sind.
Das ist genau so, als wenn du im DB10 eine Structur "Kette" oder einen UDT"Kette" im Bausteinkopf hast...

Torsten


Edit: MSB hats genau erfasst.
 
kiestumpe schrieb:
...
Der Zugriff mit "#" ist doch kein Zugriff von "aussen", oder wie verstehst du das?
...
Zum Vergrößern anklicken....

Huch - das Detail ist mir entgangen - Zugriff von aussen, da hatte ich automatisch
u "Kette".schrittaktiv[1]
Zum Vergrößern anklicken....
gelesen ...

@Torsten: ich meinte http://de.wikipedia.org/wiki/Funktion_(Programmierung)
ich programmiere fast ausschließlich Funktionsbausteine ... und ebenfalls ok: mit dem #-Zugriff kann ich auch schon eher leben - mit Zugriff von aussen - da verstehe ich (s.o.) was anderes drunter ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Damit es auch allen klar wird, und jeder begreift das ich ein Klugscheisser bin hier ein Beispiel mit dem SFB4. Einmal mit M40.0, und einmal ohne das ich den M40.0 brauche. Hier ist es natürlich egal, bei meinen Sks sinds aber 16 Bit, und das beschreiben spare ich mir. Ausserdem kann mans so wunderbar lesen.

Torsten
 

Anhänge

  • Beispiel.JPG
    Beispiel.JPG
    79,9 KB · Aufrufe: 131
Na, da bist du ja auf dem richtigen Weg. Das was wir mit Zugriff von "aussen" allgemeinverstanden haben, ist der Querzugriff innerhalb FBx,DBx auf den FBy,DBy. Also zum Beispiel: (db20,DB30 als Instanz-DB zu verstehen)
im FB10,db10
Code: 
   U DB20.dbx1.0
   =blabla
   =DB30.dbx2.0
Wenn der FB ohne Schnittstellen nur einmal aufgerufen wird, geht's noch. Tödlich wird's wenn es ein FB mit Schnittstellenparameter wird.
Entsprechend siehts mit den Merkerzuweisungen aus, natürlich nicht innerhalb des FB, sondern bei der jeweiligen Instanzierung "von aussen".
Beim Aktualisieren bzw. beim Schnittstellen-ändern bringt dies Vorteile, da der Merker dann auf dem gleichnahmigen Eingang/Ausgang bleibt.

Der Ansatz, Aktoren und Schrittketten getrennt zu behandeln, ist gängige Praxis (so wie oben beschrieben).
 
Hi,

kiestumpe schrieb:
Der Ansatz, Aktoren und Schrittketten getrennt zu behandeln, ist gängige Praxis (so wie oben beschrieben).
Zum Vergrößern anklicken....

Sowas wie "gängige Praxis" ist mir eigentlich noch nie untergekommen. Jeder macht es anders. Selbst Leute aus einer Firma, die in der gleichen Abteilung sitzen haben da so ihre Eigenarten. Einigermassen gleich ist es nur wenn einer mal einen Stil begonnen hat, und die anderen ohne Vorerfahrung von diesem gelernt haben.

Manche laden Ein-Ausgänge um, entweder in Merkerbereiche, oder in DBs, die dann nach Hand/Automatik unterteilt werden. Manche machen extra Bausteine für Hand/Automatik, manche machens in einem, und überspringen den entsprechenen Teil. Für viele ist das Mehrfachzuweisen eines Ausgangs nicht zulässig, andere laden um oder springen. Einige weisen grundsätzlich nur zu, dann wenn benötigt halt mit Selbsthaltung, wie man es von Schützsteuerungen kennt.
Manche arbeiten bei Schrittketten mit Merkern, andere mit Bausteinen, wieder andere mit Sprungleisten, und dann gibts da noch die, die ein Byte auf 0,1,2,3 usw abfragen und dann um eins incrementieren.
Manche setzen Ausgänge direkt in Sprungleisten, andere mit dem Umweg über Merker...
Und dann gibts noch Leute, bei denen bei Schrittketten nicht nur ein Schritt an ist, sondern erst 1, dann 1 und 2, dann 1,2 und 3 usw... totaler Müll, IMO.

Alles schon gesehen, und einiges selbst früher so gemacht. Viele der älteren Methoden sind einfach dadurch entstanden das es bei älteren SPS, oder anderen Herstellern gar nicht anders ging. Manches wird dann halt beibehalten. Meine Vorliebe für AWL kommt noch aus Eberle-Zeiten.
Da gab es je nach CPU gar kein setzen von Bits, oder gar Zeiten. Da durfte dann der Taktmerker gezählt werden, und das dann noch kaskadiert, wenn die Zeit mal länger sein musste. Es gabe auch keinen Ein-Aus-Merkerbereiche. Hing nur davon ab was man für ne Karte auf welchen Steckplatz steckte...
Heute mache ich Bit-Zeuchs in FUP. Wort-Zeuchs und Sprünge in AWL.
Selbst für jemanden der AWL kann (behaupte ich mal von mir) ist das übergeben von Parametern an Bausteine in FUP oder KOP übersichtlicher. Ist einfach besser zu lesen.
Ich mag einfach den Objektorientieren Ansatz, weil dadurch automatisch Struktur ins Programm kommt. Probleme werden an einer Stelle im Programm gelöst, und nicht verteilt auf verschiedene Bausteine. Ist aber wie bei allem was neu ist: Man muss sich erst dran gewöhnen.

Torsten
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Torsten05 schrieb:
Hi,

Und dann gibts noch Leute, bei denen bei Schrittketten nicht nur ein Schritt an ist, sondern erst 1, dann 1 und 2, dann 1,2 und 3 usw... totaler Müll, IMO.

Torsten
Zum Vergrößern anklicken....

Und dann gibt Leute, da beginnt die Schrittkette mit FUP/KOP
mit dem letzten Schritt im NW1 und geht zum 1. Schritt im NW xxx

Hiiilfe!
 
Hi IBFS,

das hat aber einen Grund:

Wenn du eine Schrittkette mit Merkern einfach so runterschreibst:

u #bedingung
u schritt0
s schritt1
r schritt0

u #bedingung
u schritt1
s schritt2
r schritt1

...

dann kann es passieren das die Schrittkette durch einzelne Schritte einfach durchrauscht. D.h. der Rest des Programms bekommt gar nicht mit das auch der Schritt XX mal an war, was auch zu Problemen führen kann.
Deshalb machen die das anders herum, damit mindestens für 1 Zyklus der Schritt aktiv ist. Mein ehemaliger Chef hat das so gemacht.

Torsten
 
Torsten05 schrieb:
Hi IBFS,

das hat aber einen Grund:

Wenn du eine Schrittkette mit Merkern einfach so runterschreibst:

u #bedingung
u schritt0
s schritt1
r schritt0

u #bedingung
u schritt1
s schritt2
r schritt1

...

dann kann es passieren das die Schrittkette durch einzelne Schritte einfach durchrauscht. D.h. der Rest des Programms bekommt gar nicht mit das auch der Schritt XX mal an war, was auch zu Problemen führen kann.
Deshalb machen die das anders herum, damit mindestens für 1 Zyklus der Schritt aktiv ist. Mein ehemaliger Chef hat das so gemacht.

Torsten
Zum Vergrößern anklicken....



NW1:
SET
S "Schrittfreigabe"



NW2:
u #bedingung
u "Schrittfreigabe"
u schritt0
s schritt1
r schritt0
r "Schrittfreigabe"


NW3:
u #bedingung
u "Schrittfreigabe"
u schritt1
s schritt2
r schritt1
r "Schrittfreigabe"



...
 
Torsten05 schrieb:
Klar gibts immer auch andere Lösungen. Ich sach ja nur warum die Leute das so machen :) Aber ich mach das schon ewig nicht mehr mit Merkern bei der S7...

Torsten
Zum Vergrößern anklicken....

*ACK* , da stimme ich dir zu.

@IBFS
Was ist daran besser, als die Schrittkette "rückwärts" zu programmieren? Hat dich das etwa überfordert? Ich kenne beide Varianten, es gibt keinen wirklichen Grund, die eine oder andere vorzuziehen, außer, daß man einige Befehle, Tipparbeit und Fehlerquellen einspart. Gibt auch ganze Völker, die schreiben von rechts nach links und fangen ihre Bücher hinten an zu lesen.
 
Ralle schrieb:
@IBFS
Was ist daran besser, als die Schrittkette "rückwärts" zu programmieren? Hat dich das etwa überfordert? Ich kenne beide Varianten, es gibt keinen wirklichen Grund, die eine oder andere vorzuziehen, außer, daß man einige Befehle, Tipparbeit und Fehlerquellen einspart. Gibt auch ganze Völker, die schreiben von rechts nach links und fangen ihre Bücher hinten an zu lesen.
Zum Vergrößern anklicken....


.schreiben zu rückwärts Kommentare die wie ,Sinn soviel macht Programmieren zu rückwärts Schrittketten
 
Zuletzt bearbeitet:
Stimmt!
Aber ändern macht keinen Sinn mehr, der Kollege Ralle hat mich bereits Zitiert. Jede Veränderung würde somit auffallen.

Eigentlich sollte das Kommentar auch mit einem "." Beginnen ;o)
 
Zurück
Oben