Wie programmiert der Praktiker ?

Zuviel Werbung?
-> Hier kostenlos registrieren
vladi schrieb:
Ich entschuldige mich für Alles, was evtl. Jemand beleidigt hat!
Zum Vergrößern anklicken....

Ne, das muß nu nicht sein ;) , ich seh schon, du bist heut auf der Schiene, die 180 verdreht ist :ROFLMAO: !

vladi schrieb:
P.S. Mache zur Zeit je LabView, so interessiert mich euer SPS Sch..überhaupt nicht! :ROFLMAO:
(falls länger nichts von mir gehört, Account löschen, dann habe ich mich wahrscheinlich umgebracht, oder Klappse..)
Zum Vergrößern anklicken....

Sag wenigstens Bescheid, welche Klappse...
 
vladi schrieb:
Hi Kollege,


solche komplizierte und grosse :rolleyes: mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt :rolleyes: ..bzw. durch z.B. Anzeige von Statuszustände am OP der Bediener selber sieht, was los ist; das ist gute Programmierung; und nicht bei jedem Fehler ran mit dem PG und Merker beobachten...
Hatte schon mal ein Auftrag, eine bestehende Anlage(S7, mit DP, OP usw.) Meldungsmässig zu erweitern, da war kaum sowas programmiert: Anlage ist stehengeblieben, keine Meldung, nix :rolleyes: . Und das ist oft so, leider.

Vladi
Zum Vergrößern anklicken....


Das ist richtig. Trotzdem gibt es nach wie vor Merker, die nur eine untergeordnete Rolle spielen und erst in Verknüpfung mit weiteren Zuständen wirklich zu einer Meldung führen. Es gibt zum Beispiel auch eine Innen- und Außenspannung- und den Merker für die Innenspannung zeige ich nicht direkt an, weil ich sonst 25 Meldungen gleichzeitig habe und alles Wichtige dann untergeht. Also werden solche Merker nur dann zu einer Meldung verarbeitet, wenn dieser Signalzustand wirklich für den Bediener relevant sind, also z.B. die Funktion Innenspannung auch ausgewählt ist.
Probleme habe ich meist nur dann, wenn sich jemand verprogrammiert hat- und das kann der Bediener am HMI schlecht nachvollziehen. Die meisten anderen Dinge kann man mit Diagnose und Meldungen erschlagen.
Für uns sind in erster Linie Erweiterungen relevant. Und leider programmiert nicht jeder in einem eingängigen, überschaubaren und gut dokumentiertem Stil. In einigen Anlagen wird gänzlich auf Kommentare verzichtet...
Und das sind dann meist Leute, die von den Hochsprachen her kommen (oder von Fanuc...).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie programmiert der Praktiker?

Hallo Achim,

die am meisten genutzte Darstellung ist bei uns im Betrieb AWL.
Für den Anfang würde ich Dir aber raten in KOP oder FUP zu programmieren.
Dann kannst Du auch alle Bausteine die Du programmierst in KOP/FUP oder Anweisungsliste darstellen.
Es ist auch für Deine Lehrgangsteilnehmer sich leichter in der SPS-Welt zu recht zu finden.Vor allem sehen sie Bei KOP, bzw. FUP welche Bedingungen erfüllt sind am besten.Wird ein Programm in FUP oder KOP geschrieben, und man stellt die Ansicht nach AWL um, dann sind in den Bausteinen sogenannte Platzhalter die in den Programmzeilen stehen, die da wären (NOP 0, oder BLD-Anweisungen. Also nicht erschrecken, das macht der Editor von selbst.
Bei uns setzen wir folgende Techniken ein (ASI,Profibus,Profinet). Wobei Profinet aber noch in den Kinderschuhen steckt, das nutzen wir hauptsächlich bei den S7 mit Saftetyteil. Das heisst die herkömmlichen Not-Auskombinationen (mit Schütz, oder Pilz-Relais) werden durch sogenannte sichere Eingangs oder Ausgangsmodule ersetzt.
Einen Rat für den Anfang will ich Dir auch noch geben, lass das programmieren in SCL außen vor, dies geht in den Bereich der Hochsprachen und verwirrt nur am Anfang.
Wenn Du noch mehr wissen willst, dann schreibe doch einfach wieder.

Gruß

Ben
 
Hallo Leute,
Ich habe die Ganze Diskussion mitverfolgt und aus den Antworten wird mir klar, was der Einzelne programmiert. Ich habe von der Mini-Anlage bis zur großen Verpackungsmaschine schon viel programmiert, hauptsächlich Siemens aber auch Rockwell. Ich bin auch in der PC-Programmierung aktiv und kenne Delphi, VB und C#.
Man sollte doch mit der Sprache programmieren, welche für den jeweiligen Einsatz am geeignetsten ist.
- Kleinere bis mittlere Programme ohne große Wiederverwertbarkeit direkt mit Merkern und in KOP oder FUP möglichst geradeaus programmieren, ohne groß parametrierbare Bausteine und Lokaldaten einzusetzen. Tatsächlich kann man doch solche Programme sehr gut nachvollziehen und erweitern. Der Anteil an Berechnungen und Datenverarbeitung sollte nicht zu hoch sein.
- Große Anlagen und Maschinen, streng gekapselt,modular und symbolisch programmieren. Gundsätzlich versuchen keine Merker zu verwenden. Man kommt zu schnell an die Grenzen und die Wiederverwertbarkeit ist zu gerring, wenn man Merker einsetzt. Bei Datenverarbeitung und Berechnungen bietet sich meiner Meinung nach SCL an.

Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.

Das Verständis eines Programmes hängt doch nicht von der Programmiersprache ab, sondern vom Verständnis des Ablaufs.

Einer der wichtigsten Grundsätze bei der Programmierung sollte doch sein: Kein Maschinenstillstand ohne Meldung! Wenn man das berücksichtigt, kann das Instandhaltungspersonal in vielen Fällen auf den Einsatz eines PG verzichten.

Wir setzen in größeren Umfang Achssteuerungen mit Hochsprachenprogrammierung ein. Ich habe die Erfahrung gemacht, daß selbst für den Elektriker viele Vorgänge in der Hochsprache leichter nachvollziehbar sind. Die Grenzen zwischen klassischer SPS- und Hochsprachenprogrammierung sind im Fallen begriffen.

Für den, der gerade beginnt SPS programmieren zu lernen ist meiner Meinung nach KOP/FUP der beste Einstieg. Auf AWL kann man getrost verzichten. Später sollte man dann SCL oder eine andere Hochsprache dazulernen.

Busysteme:
Bei uns sind hauptsächlich Profibus DP (S7) und Devicenet(Rockwell) im Einsatz. In etwas weiterer Zukunft wird wohl ein Ethernet basierender Feldbus (PROFINET)eingesetzt werden.


Gruß

Tom
 
Hallo Tom,

95% Zustimmung, aber

Tom Doll schrieb:
...
Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.
...
Zum Vergrößern anklicken....
ist meines Erachtens Quatsch!!!

AWL ist nicht übelste Assemblerprogrammierung. Wenn der Code zu 95% aus Lade und Transferbefehlen besteht (bestünde?), dann ist KOP/FUP die dümmste Alternative. Und wenn bei Binärverknüpfungen Klammern gebraucht werden, lege ich diese Zwischenergebnisse auf sprechende Variablen - es geht auch ohne ellenlangem Code und Klammern hab ich nicht!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn wir schon am zerpflücken sind :rolleyes:

Tom Doll schrieb:
Gundsätzlich versuchen keine Merker zu verwenden. Man kommt zu schnell an die Grenzen und die Wiederverwertbarkeit ist zu gerring, wenn man Merker einsetzt.
Zum Vergrößern anklicken....

das ist doch kokolores, wenn die symbolik steht, kann man die da definierten merker auf alle baugleichen oder bauähnliche anlagen anwenden ...

und zum thema AWL: da muß ich dem Perfektionist recht geben, L und T sollte nicht der hauptbestandteil sein, da läuft was schief ... UND: klammern sind OK, wenn man sie versteht ;) ... sie ermöglichen, dass der code in KOP/FUP darstellbar ist ...
 
Perfektionist schrieb:
AWL ist nicht übelste Assemblerprogrammierung. Wenn der Code zu 95% aus Lade und Transferbefehlen besteht (bestünde?), dann ist KOP/FUP die dümmste Alternative. Und wenn bei Binärverknüpfungen Klammern gebraucht werden, lege ich diese Zwischenergebnisse auf sprechende Variablen - es geht auch ohne ellenlangem Code und Klammern hab ich nicht!
Zum Vergrößern anklicken....

Wie oft wird im Forum eigentlich noch über KOP/FUP/AWL gestritten???
Ich würde sagen: JEDER MAL NEN KNÜPPEL IN DIE HAND, UND DANN ENTSCHEIDUNGSFINDUNG!!! :ROFLMAO:
 
vierlagig schrieb:
...
das ist doch kokolores, wenn die symbolik steht, kann man die da definierten merker auf alle baugleichen oder bauähnliche anlagen anwenden ...
Zum Vergrößern anklicken....

Gerade bei der S7 die ja idiotischerweise zur absoluten Adressierung neigt und die rein symbolische Programmierung oft unnötig erschwert, sind Überschneidungen von Merkerbereichen äußerst nervig. Bei jedem bibliotheksfähige Baustein ist die Verwendung von Merkern tabu.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
zotos schrieb:
Bei jedem bibliotheksfähige Baustein ist die Verwendung von Merkern tabu.
Zum Vergrößern anklicken....

*ACK*

...dem ist nichts hinzuzufügen...

AUSSER:
ein programm besteht halt nicht nur aus bibliotheksfähigen bausteinen, irgendwo müssen die ja auch aufgerufen werden und schnittstellen zwischen den bausteinen geschaffen werden und auch schnittstellen zur außenwelt
 
Diese Diskussion kommt mir langsam vor, als würde jemand fragen
"Fahr ich besser 3er BMW oder Golf GTI"

Oder noch eher: "Fahr ich lieber Auto oder Boot"

1. Jeder wie er will und kann!
2. Kommt immer auf den Fall an!


Binäre Verknüpfungen in SCL machen genauso wenig Sinn wie mathematische Berechnungen oder Kommunikationsabläufe in FUP/KOP

Man könnte fast denken, hier wären Maschinenbauer anwesend. ;)
Die denken ja auch fast immer, SPS wäre U Eingang = Ausgang. :rolleyes:



Bei mir ist es auch so, dass der Kunde vorgibt, wie sein Programm auszusehen hat. Und wenn er das letztendlich in KOP haben will, programmier ich das auch in KOP, damit ich direkt ne saubere Darstellung habe.




[Zeigefingerhebmodus]
Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?

Sätze wie "AWL Programme enden nur zu oft in Spaghetti Code" unterstellen doch immer, dass AWL Programmierer unsauberer arbeiten als andere Programmierer.
Ob und wie das unübersichtlich wird, kommt auf den einzelnen Programmierer an und hängt nicht von der Sprache ab.
[/Zeigefingerhebmodus ]

Ich programmiere am liebsten AWL, weil ich noch aus der S5 Welt komme.
Da ging einfach nicht alles in anderen Sprachen.
Und ich bin ein Kommentar-Freak. Ich schätze mal, dass ich hinter mindestens 80% der Programmzeilen einen Kommentar schreibe.
Das geht halt nicht in graphischen Darstellungen.


Wir können ja ne neue Sprache erfinden!
Namensvorchlag: FT (Freundlicher Text)
Programmbeispiel:
Liebe Maschine, mach bitte die richtigen Dinge zur richtigen Zeit!
Wenn irgendwas nicht so klappt, wie's soll, wäre ich Dir sehr dankbar für eine kurze Mitteilung auf dem Operator Panel!
 
dodo schrieb:
...

Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?

Sätze wie "AWL Programme enden nur zu oft in Spaghetti Code" unterstellen doch immer, dass AWL Programmierer unsauberer arbeiten als andere Programmierer.
Ob und wie das unübersichtlich wird, kommt auf den einzelnen Programmierer an und hängt nicht von der Sprache ab.
...
Zum Vergrößern anklicken....

vielen Dank!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
dodo schrieb:
[Zeigefingerhebmodus]
Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?

Sätze wie "AWL Programme enden nur zu oft in Spaghetti Code" unterstellen doch immer, dass AWL Programmierer unsauberer arbeiten als andere Programmierer.
Ob und wie das unübersichtlich wird, kommt auf den einzelnen Programmierer an und hängt nicht von der Sprache ab.
[/Zeigefingerhebmodus ]
Zum Vergrößern anklicken....

AWL verleitet zum Spaghetti Code. Da die wichtige Strukturelemente fehlen, muss man sehr schnell zu Sprüngen greifen und dies wird schnell unübersichtlich. Die Vermeidung von Sprüngen wie "GOTO" und die Sinnvollen Ausnahmen sind doch ein alter Hut.

Einige Strukturelemente wie z.B. Loop, Sprungleiste wurden zwar nachgepflegt machen aber auch AWL noch keine Hochsprache.

Daher ist sind Verallgemeinerungen wie: "AWL Programme enden nur zu oft in Spaghetti Code" schon nicht ganz unberechtigt. Es liegt immer in der Hand des Programmierers aber der Befehlsumfang einer Sprache ist nicht ganz unbeteiligt.
 
Tom Doll schrieb:
Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.
Zum Vergrößern anklicken....

Hallo Leute,

Da bin ich falsch verstanden worden, bzw. ich habe mich falsch ausgedrückt, darum will ich mich konkreter ausdrücken:
Wenn ich Berechnung oder Datenverarbeitungsfunktionen mit AWL programmiere bestehen diese zum Großteil aus Lade- und Transferanweisungen und Typkonvertierungen, die eigentlichen Anweisungen zur Berechnung u.ä. sind absolut in der Minderzahl. (da kann mir keiner widersprechen).

Weiterhin bin ich der Meinung, daß man binäre Verknüpfungen wegen der Übersichtlichkeit besser in KOP/FUP programmiert. Daß rein binäre Verknüpfungen in AWL Netzwerken auch in KOP/FUB darstellbar sind, ist mir bewusst. Aber nur wenn man sich and die Konvertierungsregeln hält.

Berechnungen und DV in KOP/FUP sind unter Umständen auch nicht besser darzustellen als in AWL.

Kann ich AWL nicht vermeiden, so ist Disziplin bei der Kommentierung unabdingbar.


Wenn in bibliothekfähigen Bausteinen Merker verwendet werden kommt es immer wieder zu Problem der Adressüberschneidung, das bemerkt man meist erst bein Zusammenkopieren und dann hat man unnötige Arbeit damit. Das habe ich leider schon zu oft durchexerziert.

Ich habe viele Kollegen, die noch lieber in AWL programmieren, weil man da "Alles machen kann" (- Leider!), Sie es immer schon so gemacht haben....
Bemerkenswert ist, dass die Programme dieser Kollegen auch die wüsteten sind, da werden Instanz DB Zugriffe aus irgendwelchen FC's durchgeführt, Merker kreuz und quer verwendet und die Programmteiel sind meist nicht wiederverwendbar. Positiv ist, dass sich die meisten einen besseren Programmierstil aneignen, wenn man Ihnen moderne Programmierweisen zeigt und auch erklärt.
 
Tom Doll schrieb:
Berechnungen und DV in KOP/FUP sind unter Umständen auch nicht besser darzustellen als in AWL
Zum Vergrößern anklicken....
berechnungen und DV sind in kop und fup dermassen ungeeignet und bilden absolut keine bessere übersichtlichkeit als in awl. bitverknüpfungen hingegen schon.
die "einfachen" verschaltungen sollten für servicetechniker und instandhalter so übersichtlich und gut kommentiert wie nur möglich sein. wie kommen denn die leute bei einer störungsbehebung dazu, da stundenlang sich durch einen code zu wühlen, der vielleicht sogar absichtlich verkompliziert wurde und hinter einem noch der chefe steht und die stillstandsminuten zählt. das sind oft arme schweine zugegeben.

aber ich bin auch der meinung das ein programm für zb. eine verfahrenstechnische anlage gar nicht ohne awl auskommen sollte.

grüsse
 
Bein meiner letzten verfahrenstechnischen Anlage (ABB DCS System + HIMA Sicherheitssteuerung) kam ich wunderbar ohne AWL aus.
Aber ich gucke mal ob ich noch ein wenig AWL einbauen kann,
Vielleicht funktionierts dann besser:ROFLMAO:
Oder ich ändere alles auf PCS7 mit AWL:ROFLMAO:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
funkdoc schrieb:
berechnungen und DV sind in kop und fup dermassen ungeeignet und bilden absolut keine bessere übersichtlichkeit als in awl. bitverknüpfungen hingegen schon.
Zum Vergrößern anklicken....
Sag ich doch auch, oder? Berechnungen und DV am Besten in SCL.

funkdoc schrieb:
die "einfachen" verschaltungen sollten für servicetechniker und instandhalter so übersichtlich und gut kommentiert wie nur möglich sein. wie kommen denn die leute bei einer störungsbehebung dazu, da stundenlang sich durch einen code zu wühlen, der vielleicht sogar absichtlich verkompliziert wurde und hinter einem noch der chefe steht und die stillstandsminuten zählt. das sind oft arme schweine zugegeben.
Zum Vergrößern anklicken....

Gute Kommentierung ist Grundvoraussetzung, Strukturierter Auffbau auch.
Normalerweise sollte das Ziel sein, daß der Instandhalter / Servicetechniker in fast allen Fällen keine Software zur Störungsbehebung braucht. Ich weiß aber auch, daß das meist nicht der Fall ist, sollte aber Ziel der Programmierung sein ("Kein Stillstand ohne Meldung"). Mit dieser Problematik bin ich inzwischen sehr vertraut, da wir viele Maschinen mit schnellen Vorgängen haben in denen man in der S7 Software nichts sieht, was einem bei der Diagnose helfen würde.


funkdoc schrieb:
aber ich bin auch der meinung das ein programm für zb. eine verfahrenstechnische anlage gar nicht ohne awl auskommen sollte.
Zum Vergrößern anklicken....

Willst Du das Verallgemeinern?

AWL ist grundsätzlich mal sehr maschinennahe Programmierung, vergleichbar mit Assembler. Dadurch fehlen fast alle Elemente zur Strukturierung, selbst ein "if ... then" muß mit mindestens einem Sprung programmiert werden. Dies entspricht einen GOTO und ist meiner Meinung nach ein Kennzeichen für Spaghetti Code.
Rein aufgrund dieser Tatsache ist es sehr schwer dem Spaghetti Code zu vermeiden.

Durch Beschränkungen in der S7 ist es z.B. nicht möglich Felder vernünftig zu indizieren, dadurch wird man immer wieder gezwungen in AWL zu programmieren. Eine Alternative ist in den meisten Fällen SCL, das aber nicht jeder zur Verfügung hat.
 
Hi,

das AWL Spaghetti-Coder erzeugt ist ja wohl dummes Zeug. Das Sprünge nicht zu vermeiden sind, liegt daran das L unt T nicht VKE-Abhängig sind. Das sind sie aber bei FUP/KOP auch nicht. Es wird nur anders dargestellt. Es zwingt einen ja auch niemand Sprünge grundsätzlich über 4 Bildschirmseiten zu machen, sondern kann so machen wie es auch der Übersetzer aus FUP/KOP macht, und bleibt im gleichen Netzwerk.

Es scheint eher so als wenn die datenverarbeitenden Hochsprachenprogrammierer ihre gewohnte Umgebung genau so wenig verlassen wollen, wie die Maschinensteuernden Bitschubser.

Und niemals nicht kommen Instandhalter mit reinem SCL Code besser zurecht als mit AWL. Für die ist beides schwer zu verstehen. Dazu kommt noch das der Instandhalter erstmal SCL haben muss.

Es wird halt immer wichtiger die Daten einer Maschine zu verarbeiten, aber steuern sollte man sie auch noch, und das läuft halt immer noch überwiegend auf Bit-Ebene.

Tom Doll schrieb:
Durch Beschränkungen in der S7 ist es z.B. nicht möglich Felder vernünftig zu indizieren, dadurch wird man immer wieder gezwungen in AWL zu programmieren. Eine Alternative ist in den meisten Fällen SCL, das aber nicht jeder zur Verfügung hat.
Zum Vergrößern anklicken....

Was meinst du damit?

Torsten
 
Zuletzt bearbeitet:
Zurück
Oben