# "Saubere" Programme



## Ralf1969 (2 März 2008)

Nachdem ich längere Zeit selbst programmiert habe wechselte ich vor einiger Zeit zu einem Unternehmen, dass die gesamte Elektrotechnik und Steuerungsprogrammierung fremdvergibt (mir wurde seinerzeit beim Wechsel mal was versprochen, das leider nicht eingehalten wurde). Nunja, was mir da an Programmen insbesonder hinsichtlich Strukturiertheit  / mieser Symbolik etc. entgegenschlägt zieht einem die Schuhe aus. Es böte sich hier ja zunächst an aus 'Softwarerichtlinien' eine art Werksvorschrift für uns zusammenzustellen, ich denke aber daß dies nicht so sehr doll ist, da ich aus eigener Erfahrung heraus weiß daß Softwarerichtlinien Programmierer zu recht großen Verrenkungen bringen, eine eigene Softwarerichtlinie in etwas moderaterer Form zu erstellen ist recht hoher Aufwand.

Gibt es irgendwo allgemeinverbindliche Richtlinien für 'saubere Programmierung'?


----------



## Larry Laffer (2 März 2008)

Ich glaube nicht, dass es zu dem Thema eine Spielregel gibt.
Es bleibt also bei dir zu entscheiden, ob und wo es hin gehen soll.

Das von dir hier angestossene Thema wird auf jeden Fall wieder viele kontroverse Meinungen ans Tageslicht bringen.

Ich würde an deiner Stelle gewisse Programmier-Spielregeln vorgeben. Wie weit das geht bleibt dir dabei überlassen. In meinem Betrieb wäre ich da sehr rigoros. Das liegt aber vielleicht auch daran, das ich schon eine Menge Mist gesehen habe und nicht jeder, der sich Profi nennt ist auch letzlich einer. Ich habe bisher feststellen müssen, dass die Werke der meissten externen Programmierer nicht im entferntesten so schön lesbar sind wie das, was du hier im Forum als Vorschläge auf Probleme erhälst.

Fazit: siehe oben ...

Gruß
LL


----------



## Rudi (2 März 2008)

Das ist ja wieder ein heißes Thema.
Jeder hält seine Programme für die genialsten.


----------



## Ralf1969 (2 März 2008)

Nun, um 'Am genialsten' geht es mir eher weniger. Es geht mir im wesentlichen natürlich um einige "No-Go" Dinge (wie zum Beispiel das Adressieren von Ein und Ausgängen mitten innerhalb von FCs (die dann möglichst, wenn es mehrfach genutzte Funktionen innerhalb einer Anlage sind mit kopiert und auf andere EA Adressen umgeschrieben wurden) Um ein Schludern bei der Symbolik und ähnlichem. Viele programme sehen mir übel nach altem s5 Code aus obwohl sie neu erstellt wurden, das muß m.E. nun wirklich nicht sein (man kann natürlich da auch unterschiedlicher Meinung sein, jedoch ist das weitgehende Ignorieren von modernen Strukturen  UDTs / Instanzierbarkeit von Bausteinen und auch das Ausufernde Benutzen von Merkern schlechte Stil, m.E. auch das nicht-Nutzen IEC Timern).


----------



## Rudi (2 März 2008)

Meiner Meinung nach ist die Hauptursache von "unsauberen Programmen" die Tatsache das der Programmierer sobald die Anlage läuft keine Zeit (Geld) mehr bekommt das Programm "aufzuräumen".


----------



## Ralf1969 (2 März 2008)

Rudi schrieb:


> Meiner Meinung nach ist die Hauptursache von "unsauberen Programmen" die Tatsache das der Programmierer sobald die Anlage läuft keine Zeit (Geld) mehr bekommt das Programm "aufzuräumen".



Hmmm ... das mag durchaus sein, allerdings wenn die Struktur von vornherein nicht da ist bestehen nur geringe chancen, durch 'aufräumen' Struktur hereinzubringen.


----------



## himbeergeist (2 März 2008)

Rudi schrieb:


> Das ist ja wieder ein heißes Thema.
> Jeder hält seine Programme für die genialsten.


 
ich nicht  ich finde immer was zu verbessern an meinen Programmen. Naja, die Maschinen sind hier in der Firma und ausser Arbeitszeit kostet es nix.  

Grüße vom KYF

Frank


----------



## Ralle (2 März 2008)

Ralf1969 schrieb:


> Nun, um 'Am genialsten' geht es mir eher weniger. Es geht mir im wesentlichen natürlich um einige "No-Go" Dinge (wie zum Beispiel das Adressieren von Ein und Ausgängen mitten innerhalb von FCs (die dann möglichst, wenn es mehrfach genutzte Funktionen innerhalb einer Anlage sind mit kopiert und auf andere EA Adressen umgeschrieben wurden) Um ein Schludern bei der Symbolik und ähnlichem. Viele programme sehen mir übel nach altem s5 Code aus obwohl sie neu erstellt wurden, das muß m.E. nun wirklich nicht sein (man kann natürlich da auch unterschiedlicher Meinung sein, jedoch ist das weitgehende Ignorieren von modernen Strukturen  UDTs / Instanzierbarkeit von Bausteinen und auch das Ausufernde Benutzen von Merkern schlechte Stil, m.E. auch das nicht-Nutzen IEC Timern).



Ich kann dich schon verstehen, aber natürlich ist gerade das Thema NOGO auch extrem kontrovers, was der eine als modern und super empfindet ist für den anderen absolut abartiger Programmierstil. Insofern bleibt dir nur übrig, deine Wünsche zu formulieren, das von den Verantwortlichen zu einer Richtlinie absegnen zu lassen und diese dann mit in die Verträge einzubringen. Bei der Abnahme wird dann auch der Programmiercode mit abgenommen. Dabei muß man dann sicher immer mal Kompromisse eingehen, aber eine Grundlage ist vorhanden. Ich geb zu, ich mag das nicht besonders als Programmierer, weil meine Angebote und Zeitabschätzungen natürlich auf meinen Programmierstil beruhen und es mitunter viel Zeit kostet, den manchmal wirklich kruden Wünschen von Verantwortlichen nachzukommen, die meinen, den Stein der Weisen zu besitzen. Ich fang auch gar nicht erst an, meine Meinung zu Gut und Schlecht beim Programmieren komplett kund zu tun, UDT, nutze ich auch, aber ich verfluche sie auch oft genug und nicht nur ich  !

PS: Und denk auch mal daran, modern ist nicht immer gleich bedeutend mit gut. Ich hab schon Graph7 -Programme eleminieren dürfen, die zwar wirklich bewundernswert modern waren, inkl. UDT, umkopieren von und in  Instanz-DB usw. aber so buggy und unwartbar, daß der Betreiber der Anlagen aus Sicherheitsgründen viel Geld in die Hand genommen hat, um neue Programme schreiben zu lassen. Die sind aus deiner Sicht vielleicht konservativ, laufen aber bestens uns wurden vom Wartungspersonal gerne angenommen, weil wenig zu warten  und auch recht gut zu überblicken. (denke ich dich mal  ) Das beste Programm ist immer noch das, wo kein Instandhalter jemals reinschauen muß. Ich weiß das ist fast unmöglich zu leisten, aber so ein Programm ist auch selten in wirklich schlechtem Programmierstil erstellt!!!


----------



## vladi (2 März 2008)

*Programme*

Hi,
bezüglich GRAPH: wo ich mich frage, wenn es um Prozesse/Sequenzen geht, die mittels Schrittketten gut auflösbar sind, was kann da besser und übersichtlicher sein als GRAPH SKs? Gibt es nicht.
Wenn ich das Programm aufmache, und mein Prozess in Form einer SK sehe, wie so alles abläuft, und welche Aggregate/Aktoren in dem entspr. Schritt aktiv sind, und das noch online verfolgen kann... Das ist das Beste für mich. 
Voraussetzung: man *kann GRAPH programmieren* und/oder lesen.

Vladi


----------



## Ralle (2 März 2008)

vladi schrieb:


> Hi,
> bezüglich GRAPH: wo ich mich frage, wenn es um Prozesse/Sequenzen geht, die mittels Schrittketten gut auflösbar sind, was kann da besser und übersichtlicher sein als GRAPH SKs? Gibt es nicht.
> Wenn ich das Programm aufmache, und mein Prozess in Form einer SK sehe, wie so alles abläuft, und welche Aggregate/Aktoren in dem entspr. Schritt aktiv sind, und das noch online verfolgen kann... Das ist das Beste für mich.
> Voraussetzung: man *kann GRAPH programmieren* und/oder lesen.
> ...



Du hast natürlich Recht, aber nicht alles ist so gut auflösbar (Servo der erst verfährt und dann in Momentenregelung geht und eine bestimmte Zeit lang mit 30t zu drücken. Das lief nicht wirklich gut, besonders, bei irregulären Abbrüchen (Stop, Reset, Not-Aus, Stop an ganz bestimmten Stellen etc.). Zudem war auf Grund der fortschrittlichen Programmierung vieles einfach nicht nachzuvollziehen (Mal wurde hier was in den Instanz-DB eines anderen FB kopiert, mal dort) Es war Einfacher, alles neu zu machen, der Kunde hatte natürlich die Nase voll von Graph. Ausßerdem hatten die das Garph-Paket zuerst nicht mal auf ihrem PG und die Instandhalter konnten damit nicht umgehen, kein Wunder, die hatten das vorher noch nie gesehen. Selbst wenn, aus o.g.G. war das Programm nicht wartbar.

PS. Entschuldige Ralf, wollte deinen Thread nicht okkupieren!


----------



## Approx (3 März 2008)

Ralf1969 schrieb:


> Gibt es irgendwo allgemeinverbindliche Richtlinien für 'saubere Programmierung'?


 
Verbindliche Richtlinien kenne ich auch nicht. Ich bin zwar selber ein Proggi, aber wenn wir mal eine Anlage Fremdvergeben, dann halte ich schon in der Pflichtenheftphase für den Auftragnehmer einige Programmier-Regeln fest, an die sich die Firma zu halten hat.
Um nur einige zu nennen:

Programm in deutscher Sprache
Netzwerke nur mit Überschrift
Gut kommentierte Symboltabelle
Keine Merkerschnittstellen (Eingänge auf Merker rangieren, dann verarbeiten, anschliessend Merker auf Ausgänge rangieren)
Möglichst in FUP (jaja, daran scheiden sich die Geister...)
keine Netzwerke mit "auskommentiertem" Code, der dann in FUP verschwindet
Referenzliste "Operanden ohne Symbol" muss leer sein.
FUP-Netzwerke nicht größer als ein Bildschirminhalt (normale Auflösung)
Damit sind wir bisher ganz gut gefahren. Ich hab zwar noch etwas meine Instandhalterbrille auf (10 Jahre Instandhaltung liegen hinter mir), aber man findet Fehler einfach schneller, wenn nach den obigen Kriterien programmiert wurde. 

Gruß Approx


----------



## kiestumpe (3 März 2008)

Und hier noch ein paar Ergänzungen:

1. Kein Zugriff auf Instanzdaten ausserhalb des Funktionsbausteins
2. Keine Sammelsurium-Datenbausteine, Trennung nach Anlagenteil, oder Trennung nach Parameter und Istwerte. 
3. Die Nummernbereich würde ich nicht zwangsläufig vorschreiben, mir sie aber vom Programmierer vorlegen lassen und somit prüfen, ob eine Struktur vorhanden ist.
4. Nachweis bei Programm-Abnahme, wie Programm ohne "rote LED's" auf PLCSim laufen kann
5. Nachweis über Test's der verwendeten selbstgeschriebenen (gekapselten) Bausteine (FC/FB).
6. Nachweis, dass S7 keine Inkosistenzen mehr anmeckert.
7. Recovery-Strategie Beschreibung (Bei Defekter CPU).


----------



## vierlagig (3 März 2008)

Approx schrieb:


> Keine Merkerschnittstellen (Eingänge auf Merker rangieren, dann verarbeiten, anschliessend Merker auf Ausgänge rangieren)



warum? ... ein kurzer erfahrungsbericht und ein quasi-pro für merkerschnittstellen:

einer unserer anlagenlieferant hat seine programme nach folgender struktur aufgebaut

1. INPUT-Scan (Eingänge auf Merkerbereiche rangieren für die einzelnen Anlagengruppen)
2. MAIN-Funktionen für die einzelnen Anlagengruppen
3. STEUER und REGEL-Funktionen für die einzelnen Anlagengruppen
4. DRIVE-Funktionen für die einzelnen Anlagengruppen
5. OUTPUT-Scan (Merkerbereiche auf Ausgänge rangieren für die einzelnen Anlagengruppen)

...wobei die anlagengruppe der in der hardwareumsetzung  definierten entspricht...

daraus ergibt sich für den inbetriebnehmer folgender vorteil:

- seine funktionen MAIN, STEUER, DRIVE sind in baugleichen anlagen immer gleich, IBN-service zeit verkürzt sich und man brauch auch keine schmiermerker 

für den instandhalter bedeutet diese gliederung:

- bei einem defekten eingang, muß keine lange querverweisliste abgearbeitet werden. einfach umverdrahten, im INPUT-Scan ändern ... fertig .. ähnlich für ausgänge (aber die sollten sowieso nur einmal beschrieben werden  ... aber bei S/R sinds schon mal zwei ...)


----------



## kiestumpe (3 März 2008)

An diesem Punkt habe ich auch gestutzt, aber vielleicht soll und approx erklären was er damit genau meint.
Bezieht das vielleicht auf IN-Parameter von FC/FBs? Hier wäre es natürlich Quatsch sie auf Schmiermerker zu legen.


----------



## Ludewig (3 März 2008)

Ich denke , das Rangieren von Merkerbereichen kommt noch aus der Zeit vor einer komplett symbolischen Programmierung, wie sie in einer IEC-Umgebung standardisiert ist.


----------



## Approx (3 März 2008)

Zu den Merkerschnittstellen kann ich nur sagen, dass es aus Programmierersicht einfacher ist, weil man sein Programm bequem im Büro schreiben kann und vor Ort nur noch die Schnittstelle beschalten muss. *ABER: *Wenn man fix einen Fehler suchen muss, dann sind mit Merkerschnittstelle immer noch ein paar Steps mehr nötig, um z.B. einen fehlenen Eingang zu lokalisieren. In meinem Fall hatte der "Gute Mann" in der betreffenden Anlage seine Merker nicht mal gut kommentiert. Ich hab dann kurzerhand das komplette Programm umverdrahtet (kurz ist gut - es hat ca. ne Woche gedauert). Aus solchen Dingen hab ich halt gelernt und mein Cheffe pflichtet mir bei.  

P.S. Ist ja wie beschrieben auch nur *meine* Meinung zu "sauberer" Programmierung.  

Gruß Approx


----------



## vierlagig (3 März 2008)

Approx schrieb:


> In meinem Fall hatte der "Gute Mann" in der betreffenden Anlage seine Merker nicht mal gut kommentiert.



solltest aus den erfahrungen aber keine allgemein gültigen regeln aufstellen, denn wie du schon erwähntest:



Approx schrieb:


> Gut kommentierte Symboltabelle



der zwischenschritt über den fehlenden eingang ist ein berechtigter einwand, allerdings kann man das durch gute störauswertung und damit verbundener visualisierung kompensieren, so dass man den eingang und in meinem fall, ich den INPUT-scan, wirklich nur anzufassen brauche, wenn ich darin eine änderung/erweiterung vornehmen muß/möchte...


----------



## OHGN (4 März 2008)

Früher hab ich das auch nicht so gesehen aber das Argument von vierlagig, dass wir in irgend einem anderen Thread schon mal durchhatten hat mich überzeugt, so dass ich meine neuen Programme auch nach diesem Stil schreibe.


vierlagig schrieb:


> für den instandhalter bedeutet diese gliederung:
> 
> - bei einem defekten eingang, muß keine lange querverweisliste abgearbeitet werden. einfach umverdrahten, im INPUT-Scan ändern ... fertig .. ähnlich für ausgänge (aber die sollten sowieso nur einmal beschrieben werden  ... aber bei S/R sinds schon mal zwei ...)


*ACK*


----------



## kiestumpe (4 März 2008)

Wie wärs denn mit dem Vorschlag, anstatt der Merker zwei Datenbausteine zu verwenden z.B. "DB-IN", "DB-OUT"?
Hab mit PEW und PAW schon ähnliches gemacht und die Erfahrungen, was gute Vorbereitung anbetrifft, sind recht gut.


----------



## OHGN (4 März 2008)

Für die "Merkerhasser" unter uns wäre das natürlich eine Alternative. 
Ich persönlich halte Merker für diesen Anwendungsfall aber für "in Ordnung".


----------



## vierlagig (4 März 2008)

kiestumpe schrieb:


> Wie wärs denn mit dem Vorschlag, anstatt der Merker zwei Datenbausteine zu verwenden z.B. "DB-IN", "DB-OUT"?
> Hab mit PEW und PAW schon ähnliches gemacht und die Erfahrungen, was gute Vorbereitung anbetrifft, sind recht gut.



is aber von der symbolik her eher gewöhnungsbedürfdig, wenn da dann DB_IN.A420_Q32_DIC_RDY stehen würde ... also alles im allen unübersichtlicher ... auch bei darstellung ohne symbolen...


----------



## Perfektionist (4 März 2008)

Ludewig schrieb:


> Ich denke , das Rangieren von Merkerbereichen kommt noch aus der Zeit vor einer komplett symbolischen Programmierung, wie sie in einer IEC-Umgebung standardisiert ist.


 
100%ige Zustimmung!


Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):

alt: "DI_Befehl_Start" an E0.0

ändern in Symboltabelle in
neu: "DI_Befehl_Start" an E1.1

dann Bausteinkonsistenzprüfung (die findet dann alle geänderten Symbole), schließlich die neuen Bausteine auf die CPU schießen.

(und wer E/A über Pointer addressiert, den schieß ich auf den Mond !!!)


EDIT: und hab es grad nochmal ausprobiert: bei einem jungfräulichen Projekt ist bei Siemens immer noch Operandenvorrang Absolutwert voreingestellt :sb7: :sb6: Leben die immer noch hinter dem Mond?


----------



## OHGN (4 März 2008)

Perfektionist schrieb:


> 100%ige Zustimmung!
> 
> 
> Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):
> ...


Wer allerdings schon mal in einer Nachtschicht eine Störung an einer Anlage beseitigen musste, weil ein SPS- Eingang defekt war, der wird die Variante mit dem Umrangieren auf Merker oder DB-Bereiche (egal) zu schätzen wissen.
Also ich finde das nicht schlecht.


----------



## Ralle (4 März 2008)

OHGN schrieb:


> Wer allerdings schon mal in einer Nachtschicht eine Störung an einer Anlage beseitigen musste, weil ein SPS- Eingang defekt war, der wird die Variante mit dem Umrangieren auf Merker oder DB-Bereiche (egal) zu schätzen wissen.
> Also ich finde das nicht schlecht.



Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder  mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.


----------



## vierlagig (4 März 2008)

Ralle schrieb:


> Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder  mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.



denk doch auch mal einer an die heulsusen von instandhalter ... wenn es in mehreren bausteinen umverdrahtet wird, müssen alle bausteine wieder in die cpu geladen werden und wer, wenn nicht der instandhalter, vergisst da gern mal einen baustein...


----------



## kiestumpe (4 März 2008)

Perfektionist schrieb:


> 100%ige Zustimmung!
> 
> 
> Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):
> ...


Tjaja, das alte Leid. Hat das immer zu 100% funktioniert mit dem hin- und herschalten Symbolisch / Absolut?


----------



## zotos (4 März 2008)

@Ludwig und den Perfektionist:
*ACK*

Also ein und Ausgänge auf Merker oder DBs zu rangieren ist IMHO völlig Überflüssig.



Perfektionist schrieb:


> ...
> EDIT: und hab es grad nochmal ausprobiert: bei einem jungfräulichen Projekt ist bei Siemens immer noch Operandenvorrang Absolutwert voreingestellt :sb7: :sb6: Leben die immer noch hinter dem Mond?



Ich finde es auch gruselig das Siemens noch so stark auf die Absolute Adressierung setzt.

@OHGN:
Ein nicht Siemens Beispiel wie einfach das geht, einen Eingang um zu verdrahten.
Einfach in den Globalen Variablen der Eingänge aus:

```
_0B080A       AT %IX0.8      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
```
z.B. ein:


```
_0B080A       AT %IX1.7      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
```
machen und fertig ist die Aktion. Das Umklemmen der Strippen darf man natürlich nicht vergessen ;o)

Auch das Argument mit dem Austesten im Büro von Approx greif IMHO nicht. Wenn man nicht weis auf welchem Physikalischen Eingang später einmal der Druckschalter angeschlossen sein wird, lässt man bei der Variablen Deklaration die AT Verknüpfung weg und fügt sie ein wenn man es weis.

```
_0B080A                      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
```
Das Siemens das mit der reinen Symbolischen Adressierung nicht auf die Reihe bekommt ist ein Armutszeugnis.


----------



## MW (4 März 2008)

vierlagig schrieb:


> denk doch auch mal einer an die heulsusen von instandhalter ... wenn es in mehreren bausteinen umverdrahtet wird, müssen alle bausteine wieder in die cpu geladen werden und wer, wenn nicht der instandhalter, vergisst da gern mal einen baustein...


 
Bist du nicht auch einer ???? 

Also ich hätte damit keine Probleme mit dem Umverdrahten

Und mal realistisch gesehen, wie oft geht den heute noch ein Eingang kaputt ???? Bei Ausgängen ist es klar, dass da hin und wieder einer den Geist aufgibt.


----------



## OHGN (4 März 2008)

Ralle schrieb:


> Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.


Ja, der Recourcenverbrauch ist natürlich höher. Und natürlich ist es nicht schlimm mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen.
Ich kann nur aus meiner eigenen Erfahrung als ehemaliger Instanthalter sprechen, dass es sehr Wohl ein Unterschied ist wenn ich genau weis dass ich nur einen Baustein in die SPS übertragen muss, anstatt mehrer und ich nicht erst prüfen muss wieviel und welche.
Vor allem wenn ein ganzes Rudel Anlagenfahrer und der Produktionsleiter um mich rumhüpfen. 
Aber ich will hier natürlich nicht behaupten, dass die Rangiererei nun das Non plus Ultra ist, von der Sache her kann das ja jeder machen wie er will.


----------



## Approx (4 März 2008)

OHGN schrieb:


> Aber ich will hier natürlich nicht behaupten, dass die Rangiererei nun das Non plus Ultra ist, von der Sache her kann das ja jeder machen wie er will.


100%ACK! Ich möchte halt keine Merkerschnittstellen und fertig. Meine heulsusigen Instandhalter auf Schicht haben es mir bereits gedankt!  
Meine Erfahrungen aus der Stahlindustrie sind die, daß weniger ein Eingang kaputt geht, sondern draussen die Peripherie abraucht... Und den defekten Näherungsschalter, Sensor ect. gilt es so schnell wie möglich zu finden. Das klappt halt besser mit Absolut-Adressierten Programmen ohne Merkerschnittstellen.

P.S: Ich wundere mich über diese kontroverse Diskussion, jeder nach seiner Fasson! (siehe Zitat OHGN...)

Gruß Approx


----------



## IBN-Service (4 März 2008)

Perfektionist schrieb:


> ...
> (und wer E/A über Pointer addressiert, den schieß ich auf den Mond !!!)
> ...



*ACK* 

CU

Jürgen

.


----------



## Ralle (4 März 2008)

Perfektionist schrieb:


> (und wer E/A über Pointer addressiert, den schieß ich auf den Mond !!!)



Guck mal: http://www.sps-forum.de/showpost.php?p=123260&postcount=10

Da haben wir das grad mal durch , fängst du also mit mir an, die Reise gönn ich mir, grins.

PS: Hast aber prinzipell Recht, gibt aber immer Ausnahmen!


----------



## Perfektionist (4 März 2008)

@Ralle: bezog sich nicht auf diese Geschichte - das hab ich gar nicht mitgelesen.

Ansonsten gilt m.E. generell: jeder Zugriff, der nicht im Querverweis auftaucht, ist schon mal verachtenswert. Insofern bin ich entschiedener Gegner von Pointeradressierung. Das gilt für mich bei jedem Pointerzugriff auf globale Elemente.

Dagegen kann ich einen Pointerzugriff auf lokale Variablen innerhalb der eigenen Instanz, gegebenenfalls auf eine UDT-Struktur, gut akzeptieren, besonders dann, wenn an leicht erkennbarer Stelle auf diese indirekte Adressierung hingewiesen wird.

Aber ich geb zu: meine oftmals einfach strukturierten Algorithmen verlangen maximal nach einem Indexzugriff auf eindimensionale Tabellen ...


----------



## jabba (4 März 2008)

Perfektionist schrieb:


> ...
> Ansonsten gilt m.E. generell: jeder Zugriff, der nicht im Querverweis auftaucht, ist schon mal verachtenswert. Insofern bin ich entschiedener Gegner von Pointeradressierung. Das gilt für mich bei jedem Pointerzugriff auf globale Elemente.
> 
> Dagegen kann ich einen Pointerzugriff auf lokale Variablen innerhalb der eigenen Instanz, gegebenenfalls auf eine UDT-Struktur, gut akzeptieren, besonders dann, wenn an leicht erkennbarer Stelle auf diese indirekte Adressierung hingewiesen wird.
> ...


 
*ACK* 

Hab einen neuen Kunden, die lesen über Pointer alle Eingänge vom ASI ein, und geben die über Pointer aus (Zwischengespeichert in einem DB). Den Ventilbaustein gibts nur einmal, und der zählt die Anzahl der Ventile durch, und greift über  indirekte Adressierung auf den DB zu. Die schreiben zwar nicht direkt auf den E/A wie oben erwähnt, aber den weg über den DB find ich auch nicht besser.Und die wundern sich, das die Maschinen beim austausch gegen eine 317 schneller werden.

Und jetzt soll ich das für die Maschinen so übernehmen , da alle Maschinen von denen so laufen :sb7:


----------



## repök (4 März 2008)

Approx schrieb:


> 100%ACK! Ich möchte halt keine Merkerschnittstellen und fertig. Meine heulsusigen Instandhalter auf Schicht haben es mir bereits gedankt!
> Meine Erfahrungen aus der Stahlindustrie sind die, daß weniger ein Eingang kaputt geht, sondern draussen die Peripherie abraucht... Und den defekten Näherungsschalter, Sensor ect. gilt es so schnell wie möglich zu finden. Das klappt halt besser mit Absolut-Adressierten Programmen ohne Merkerschnittstellen.
> 
> P.S: Ich wundere mich über diese kontroverse Diskussion, jeder nach seiner Fasson! (siehe Zitat OHGN...)
> ...


 
dafür gibts denn aber störmeldungen.


----------



## Approx (5 März 2008)

repök schrieb:


> dafür gibts denn aber störmeldungen.


 
Ach ja?  Ich stelle mir gerade eine Störmeldung vor, die etwa so lauten könnte: _"Bediener hat gedrückt, es passierte aber nix!"  _

Endlagen usw. kann man ja super überwachen, aber bei Befehlsgebern wird es dann schon schwieriger.  

Anm.: Die fetteste unserer Anlagen hat ca. 15.000 Meldungen (Alarm_8 ) im WinCC. Also Meldungen (auch Bedienmeldungen) existieren reichlich.

Gruß Approx


----------



## vierlagig (6 März 2008)

mal ein beispiel für ... na, wie soll ich sagen ... unsauber is da noch geschmeichelt ...


----------



## Perfektionist (6 März 2008)

vierlagig schrieb:


> mal ein beispiel für ... na, wie soll ich sagen ... unsauber is da noch geschmeichelt ...


 
hmmjaaa... könnt man sowas nicht auf Hygienepapier drucken?


----------



## Ralle (6 März 2008)

vierlagig schrieb:


> mal ein beispiel für ... na, wie soll ich sagen ... unsauber is da noch geschmeichelt ...



In diesem Falle ja, aber !!! Es gibt z.Bsp. auch Global DB, die sind in jedem Programm identisch, weil die Hersteller seinen eigenen Standard hat. Da werden dann auch globale Zugriffe und IN-Var gemischt genutzt. Das spart kilometerlange IN-Listen bei den Bausteinaufrufen. Es hat halt alles zwei Seiten.


----------



## vierlagig (6 März 2008)

Ralle schrieb:


> In diesem Falle ja, aber !!! Es gibt z.Bsp. auch Global DB, die sind in jedem Programm identisch, weil die Hersteller seinen eigenen Standard hat. Da werden dann auch globale Zugriffe und IN-Var gemischt genutzt. Das spart kilometerlange IN-Listen bei den Bausteinaufrufen. Es hat halt alles zwei Seiten.



die IN-Variablen werden alle samt mit globalen Adressen belegt, also Merker oder E/A´s ... man könnte sich in diesem Fall IMHO die Eingabe beim Bausteinaufruf sparen und gleich alles global adressieren ...

... hätte dazu schreiben sollen, dass der baustein nur einmal aufgerufen wird und die globalen Sachen darin garantiert nicht standardisiert sind - Gründe? ich weiß es einfach *kritischüberdenschreibtischzuseinemkollegenguckt*


----------



## Torsten05 (12 März 2008)

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


----------



## Perfektionist (12 März 2008)

Torsten05 schrieb:


> ...
> Was ich aber nicht nachvollziehen kann, ist die Abneigung von aussen auf Instanz-DBs zuzugreifen.
> ...


 
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:


----------



## Larry Laffer (12 März 2008)

Perfektionist schrieb:


> Und der absolute Killer: ändere die Instanz - und alle Querzugriffe müssen aktualisiert werden :twisted:


 
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


----------



## Torsten05 (12 März 2008)

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.
> 
> ...



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.

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!?!"


----------



## kiestumpe (12 März 2008)

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:
> 
> ...



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.


----------



## MSB (12 März 2008)

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


----------



## Torsten05 (12 März 2008)

kiestumpe schrieb:


> Hallo Torsten,
> 
> im Prinzip hat Perfektionist schon alles gesagt,
> aber was meinst du mit:
> ...



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.


----------



## Perfektionist (12 März 2008)

kiestumpe schrieb:


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


 
Huch - das Detail ist mir entgangen - Zugriff von aussen, da hatte ich automatisch


> u "Kette".schrittaktiv[1]


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 ...


----------



## Torsten05 (12 März 2008)

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


----------



## kiestumpe (13 März 2008)

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

```
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).


----------



## Torsten05 (14 März 2008)

Hi,



kiestumpe schrieb:


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



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


----------



## IBFS (14 März 2008)

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


 
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!


----------



## Torsten05 (14 März 2008)

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


----------



## IBFS (14 März 2008)

Torsten05 schrieb:


> Hi IBFS,
> 
> das hat aber einen Grund:
> 
> ...


 


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 (14 März 2008)

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


----------



## Ralle (15 März 2008)

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



*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.


----------



## zotos (15 März 2008)

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.




.schreiben zu rückwärts Kommentare die wie ,Sinn soviel macht Programmieren zu rückwärts Schrittketten


----------



## Ralle (15 März 2008)

zotos schrieb:


> schreiben zu rückwärts Kommentare die wie, Sinn soviel macht Programmieren zu rückwärts Schrittketten



So ein dummer Unsinn aber auch, zotos.


----------



## Ludewig (15 März 2008)

@zotos: Das Komma ist falsch.


----------



## zotos (15 März 2008)

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)


----------



## Torsten05 (15 März 2008)

Hi,

ich finde wenn es sich dabei um einen abgeschlossen Baustein handelt, der danach nur noch mit Werten versorgt wird, ist das OK, denn man kann die Eingangsvariablen ja "richtig" machen. Sonst ist das Lesen allerdings schon gewöhnungsbedürftig.

Ich sitz grad in Hannover und am Montag muss die Anlage wieder laufen. Eigentlich dachte ich das ich heute weiter komme, aber diese XFJSKAFJSF Lenze Regler...Die CPU ist fast schon zu klein, das pisselige TP170A kann GAR NIX von Haus aus und ist lahm wie Sau und Wincc Flex bringts auch nich...
ICH WILL NACH HAUSE ZU MAMA:wink:

Torsten


----------



## Lipperlandstern (16 März 2008)

zotos schrieb:


> .schreiben zu rückwärts Kommentare die wie ,Sinn soviel macht Programmieren zu rückwärts Schrittketten


 
Der gute alte UG hat irgendwo auch mal geschrieben,das er seine Schrittketten rückwärts programmiert.....

Also MUSS man Schrittketten rückwärts programmieren... das ist quasi ein Gesetz ( an das ich mich auch nicht halte..........)

Schönen Sonntag noch.....


----------



## nade (16 März 2008)

Wohl ehr ein ungeschriebenes Gesetz es ist.
Schüler von Joda es sind. 
Was auch gut klingt ist wenn ein Schütz mit Kontaktrückführung MG-Feuer simuliert weil *Zitat Grubeelektriker* " Die SPS ist schneller als ein Schütz".
Wenn die SPS noch *ROFL* über die Aufgaben die sie pro Zyklus abzuarbeiten hat......
Und zu KOP wäre uns UG glaub auch nur beim erwähnen dieser Programierweise explodiert.


----------



## zotos (16 März 2008)

Lipperlandstern schrieb:


> Der gute alte UG hat irgendwo auch mal geschrieben,das er seine Schrittketten rückwärts programmiert.....
> 
> Also MUSS man Schrittketten rückwärts programmieren... das ist quasi ein Gesetz ( an das ich mich auch nicht halte..........)
> 
> Schönen Sonntag noch.....



Gibt es da auch einen link auf den betreffenden Beitrag? Vorausgesetzt Deine Erinnerung spielt Dir keinen Streich, müsste ich meine Meinung dazu natürlich anpassen.


----------



## Kai (16 März 2008)

Lipperlandstern schrieb:


> Der gute alte UG hat irgendwo auch mal geschrieben,das er seine Schrittketten rückwärts programmiert.....
> 
> Also MUSS man Schrittketten rückwärts programmieren... das ist quasi ein Gesetz ( an das ich mich auch nicht halte..........)


 


zotos schrieb:


> Gibt es da auch einen link auf den betreffenden Beitrag? Vorausgesetzt Deine Erinnerung spielt Dir keinen Streich, müsste ich meine Meinung dazu natürlich anpassen.


 
http://www.sps-forum.de/showpost.php?p=50961&postcount=5

http://www.sps-forum.de/showthread.php?t=8926

Gruß Kai


----------



## zotos (16 März 2008)

Kai schrieb:


> http://www.sps-forum.de/showpost.php?p=50961&postcount=5
> 
> http://www.sps-forum.de/showthread.php?t=8926
> 
> Gruß Kai



Dann ist das Gesetzt. Ich werde mich bei meiner Nächsten Merker basierenden Schrittkette daran halten.

PS: Dieses Versprechen fällt mir sehr leicht ;o)


----------



## IBFS (17 März 2008)

zotos schrieb:


> Dann ist das Gesetzt. Ich werde mich bei meiner Nächsten Merker basierenden Schrittkette daran halten.
> 
> PS: Dieses Versprechen fällt mir sehr leicht ;o)


 

...ohhh, da werde ich wohl bald verhaftet - doch halt - zum Glück - ich nehme ja ------- >> SPL LIST


----------

