Wie programmiert der Praktiker ?

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

kinners, contenance, wenigstens ein wenig, SV is wo anners!

 

[Question_mark]

Brauch ich nicht..

Hallo,

contenance,

Ist das auch so ein Scheiss-Tool ??
Kannste behalten ..

Gruß

Question_mark

 

[funkdoc]

Zuviel Werbung?
-> Hier kostenlos registrieren

zur effektivität der ausbildung sollte man im FUP prgrammieren.
viele leute verstehen das sogenannte Logik-Gatter bei FUP viel schneller als KOP (ausgenommen elektriker, da braucht man doch etwas planlesekenntisse) oder gar AWL.

in der simatik ist FUP in allen ansichten (KOP,AWL) darstellbar. hingegen ist die AWL das leider nicht, da man hier mit dieser sehr direkten schreibweise viel abkürzt. man müsste zb. für die darstellung in FUP dann beim AWL programmieren viele "no operation"-befehle (=NOP) an nichtbelegte ein- und ausgangsvariablen eines bausteins oder oder zb. eines timers schreiben.
man sollte beim programmieren stets an leute denken, die nach einem kommen und die da dann ein service oder störungsbehebung machen sollen.

daher find ich FUP als einstieg schonmal eine gute idee.

zudem kann man zunehmend auch an anderen steuerungen wie zb. mitsubishi seit einiger zeit auch in FUP programmieren... was ein umsteigen wieder viel einfacher macht, da ja die grundbefelhe bei jeder steuereung sehr ähnlich (meistens auch gleich) sind.

grüsse

 

[Roos]

Also für die Instandhalter bin ich auch der Meinung, dass für die schnelle fehlersuche kop und fup ideal sind.
ich muss aber sagen dass ich trotz dem lieber in awl programme schreibe weils einfach schneller geht...
mfg roos

 

[dodo]

            ____________
           |    MOVE    |
           |            |  
#zuweisen -+ EN     OUT +- #INT_variable
           |            |
           |            |
   B#16#F -+ IN     ENO +- 
           |____________|

...hatten wir doch heut schon mal...

Stimmt! War'n schlechtes Beispiel!
Ich weiss aber, dass es irgendwas mit zuweisen oder Vergleichen gab, was nicht ging.
Und spätestens bei komplexen Berechnungen geht's nicht ohne AWL.

Und wer eine komplexe Industrieanlage mit mehreren Teilanlagen in AWL runterklopft, gehört nicht vors PG.

Den Spruch versteh ich nicht!?
Wie programmierst Du denn komplexe Industrieanlagen? in FUP?
Frage ist natürlich, was man unter komplexer Industrieanlage versteht?
Ich hab hier zum Bsp. ne Anlage mit ner 416er CPU, 113 DP-Busteilnehmern an drei Mastersystemen, 52K belegten E/A und etwas über 500 Bausteinen drin.
Bewegen tun sich allerdings nur 2 Zylinder!

Ich find's blöd, dass bei Postings, bei denen Meinungen geäussert werden, dann gerne mal der Ton etwas "persönlich" wird. Letzten Endes kann ja jeder programmieren, wie er will und es kommt (siehe oben) auf den Anwendungsfall an, was am besten passt.

Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen.

Wieso? Ich kenn genug Leute, die jeden Tag das Gegenteil beweisen.
Wie oben geschrieben: Kommt drauf an, was man programmiert!
EIn Kollege von mir programmiert jeden Tag an echt komplexen NC Bearbeitungszentren rum und kennt SINUMERIK hoch und runter. Der kann noch nicht mal ne IF Abfrage programmieren. Brauch er aber auch nicht!

Es gibt auch Hochsprachenprogrammierer die in den SPS-Bereich einsteigen und keinen blassen Schimmer von SPS-Programmierung haben.

Setz Dich mal als SPS Programmierer vor'n PC und programmier schnell ne Datenbankanwendung in einer objektorientierten Sprach runter!
Da wirst Du auch Probleme haben.

Das Kernproblem ist oft, dass immer noch viele Leute denken, programmieren ist programmieren!
SPS, Hochsprachen, Webprogramierung..., alles verschiedene Welten.
Als würde man einen Hufschmied in eine Goldschmiedewerkstatt stecken und würde sagen "Schmied ist Schmied"! *ROFL*

Wobei ich der Meinung bin,ass viele Hochsprachen-Proggern(ohne denen zu nahe treten zu wollen, bin schliesslich selber gelegentlich einer), die Meinung haben, SPS wäre einfacher zu programmieren und wer Hochsprache kann, kann auch SPS :sc6: :sm11:
Gerade PC Programmierer gehen da oft auch sehr lässig ran. Die kennen das halt nicht anders: Wenn das Programm nicht funzt, stürtzt halt mal der Rechner ab oder so. Dann starten wir neu und fertig.
Aber bei ner SPS...!?
Das ist dann so wie der Unterschied, auf einer gemalten Linie zu laufen oder auf'm Hochseil! :sm14:

Über das Thema "Roboter", die ja irgendwo in der Mitte stehen, lass ich mich jetzt aber nicht mehr aus!

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen.
...

...
Wieso? Ich kenn genug Leute, die jeden Tag das Gegenteil beweisen.
Wie oben geschrieben: Kommt drauf an, was man programmiert!
EIn Kollege von mir programmiert jeden Tag an echt komplexen NC Bearbeitungszentren rum und kennt SINUMERIK hoch und runter. Der kann noch nicht mal ne IF Abfrage programmieren. Brauch er aber auch nicht!
...

Ist doch ganz klar wer neu in den SPS Bereich Einsteigt hat wahrscheinlich vor da noch einige viel Jahre (Jahrzehnte) in diesem Bereich zu arbeiten. Die Tendenz geht doch ganz klar weg von IL(AWL) hin zu ST(SCL). Also nur weil heute jemand in dem Bereich heute der Held ist, bedeutet nicht das er sich nicht weiter bilden muss.
Die Anforderungen ändern sich doch auch. Es fallen bei der Produktion immer mehr Daten an, Anbindungen an Leitrechner und Datenbanken. Schon bei einem popligen Datamatrix Code muss man sich Strings zu recht kopieren und wieder auseinander pflücken.

Auch Siemens hat den Trend erkannt:

Bei der Programmierung von SIMOTION haben Sie die Wahl: Ob grafisch mit Motion Control Chart (MCC), wie von der PLC gewohnt mit Kontaktplan (KOP) / Funktionsplan (FUP) oder mit der Hochsprache Structured Text (ST), das Engineeringsystem SCOUT versteht einfach alles.

Aber ein schritt weiter weg von der SPS im Bereich der HMI trifft man immer öfter auf Skriptsprachen. Auch da ist es sicher nicht kein Nachteil sich mal mit Hochsprachen auseinander gesetzt zu haben.

 

[Perfektionist]

von Wikipedia http://de.wikipedia.org/wiki/Programm

Ein Computerprogramm ist eine statische Folge von Anweisungen.

in diesem Sinn ist für mich KOP/FUP kein Programm sondern die grafische Darstellung eines Programmes. Wer also programmieren lernen will, muss sich m.E. auf das Verfassen von Anweisungslisten einlassen ...

 

[derwestermann]

Wissenswertes

Wie der Name schon sagt:

http://www.ipsta.de/seiten_html/wissenswertes_frei.html

 

[achim532000]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie progammiert ??

Hallo,

und vielen Dank erst mal für die vielen Antworten, Meinungen und Tips.
Manche haben sich zwar etwas unschön ausgelassen aber was solls.
Klar zu erkennen komplizierte anspruchsvolle Programme in AWL, SCL und GRAPH. Mit den Azubi werde ich weiter vorwiegend in FUP programmieren.
Bei Ablaufsteuerungen habe ich mich selbst für Graph entschieden, eröffnet mehr Möglichkeiten, lässt sich übersichtlich und schnell programmieren. PROFIBUS scheint stark verbreitet zu sein. Waren gestern bei SIEMENS zu "5 bis 7", die erzählten das Gleiche. Der Trend soll jedoch zu PROFINET gehen.
Also, Allen die mitgemacht haben nochmals vielen Dank, Ihr habt mir geholfen.

Gruss aus dem Harz

von Achim

 

[dodo]

von Wikipedia http://de.wikipedia.org/wiki/Programm

in diesem Sinn ist für mich KOP/FUP kein Programm sondern die grafische Darstellung eines Programmes. Wer also programmieren lernen will, muss sich m.E. auf das Verfassen von Anweisungslisten einlassen ...

Da ist insofern was dran, als das das Programm letzten Endes doch immer als Text gespeichert wird!

 

[vierlagig]

Waren gestern bei SIEMENS zu "5 bis 7", die erzählten das Gleiche. Der Trend soll jedoch zu PROFINET gehen.

wenn ich siemens wär würd ich das auch verbreiten ... aber was an dieser marketing-strategischen aussage nun wirklich dran ist, sieht man an den wenigen posts, fragen und anregungen hier ... oder ist PROFINET so unkompliziert, dass es selbst der heulende instandhalter versteht?

 

[funkdoc]

Zuviel Werbung?
-> Hier kostenlos registrieren

weder noch.

profinet ist ein "standart" der erst in nächster zeit die kommunikation von steuerungen, geräten und servern bestimmen wird.

dass hier im forum darüber kaum was steht, liegt aber nicht an der komplexität dieser busverbindung (NIC) sondern vielmehr an der wenigen verbreitung (bisher) dieses standarts und den hohen preisen von PROFINET komponenten.

die vorteile liegen ja klar auf der hand: volle bandbreite mit bis zu 100Mbit/s, keine DP adapter mehr, einfache vernetzung mit CAT5 oder CAT7 in sternstruktur oder wie auch immer und herkömmliche switches wie sie in jeder firma vorkommen (ausgenommen PROFINET IO IRT<1ms latenz), unbegrenzte teilnehmerschaft*, gigabit netzwerk backboned möglich, ein kabel von managementebene über Prozessleitebene bis zur Feldebene,........

übrigens wird PROFINET nicht nur von siemens gepusht sondern vielmehr von der PROFIBUS nutzerorganisation. heisst Profinet wird sich in zukunft auch an anderen steuerungen finden.

ps. zwecks geschwindigkeit: der sprung zum gigabitnetz scheint auch nicht mehr fern.

grüsse

 

[arcis]

+

Hochsprachenprogrammierung und SPS-Programmierung sind zwei grundlegend verschiedene Welten.

Leider wird die SPS-Programmierung von vielen Hochsprachenprogrammierern durchgehend als absolutes Pipifax betrachtet. Die paar Ein- und Ausgänge kann doch jeder Ansteuern, was soll daran so schwierig sein? Und so kann es dann schon mal passieren, dass auch ein C-Programmierer auf eine SPS losgelassen wird, mit den entsprechenden oben bereits erwähnten Ergebnissen.

Ich halte SPS-Progammierung und Hochsprachenprogrammierung vom intellektuellen Anspruch her für absolut gleichwertig. Es geht nicht darum, ein irgendwie lauffähiges SPS-Programm zu fabrizieren, das die paar Ein- und Ausgänge ansteuert, sondern eine robuste, wartbare, verständliche SPS-Software zu machen, mit der gearbeitet werden kann. Das sind dann schon Unterschiede, für die meines Erachtens viele Jahre Erfahrung und der Einsatz von etwas Gehirnschmalz notwendig sind.

Hauptaufgabe wird es aber bleiben, gegen die leider allgemein verbreitete Geringschätzung von SPS-Programmierung fortwährend, unermüdlich und immerzu anzupredigen.

 

[TobiasA]

Ja nee is klar Du baust überall Schmiermerker ein. Du bist ja ein ganz cleverer. Böse lokale Variablen ganz böse.


Bussysteme sind auch Böse?
Ihr setzt also nicht nur begrenzt Bussysteme, nein auch der Horizont ist stark eingeschränkt ;o)

An der CNC kann ich Merker beobachten, lokale Variablen dagegen nicht. Also setze ich für wichtige Verknüpfungen und für solche Dinge, die ich in anderen Bausteinen benötige, Merker ein. Für andere Dinge nehme ich auch lokale Variablen- nämlich für Dinge, die nur im entsprechenden FC benötigt werden und für die Fehlerdiagnose verzichtbar sind. Hat für mich den Vorteil, dass ich den Kollegen, der vor Ort ist, bitten kann, doch mal nach dem Zustand eines Merkers zu schauen.
Aber ich sehe keinen Sinn darin, für alles nur lokale Variablen zu benutzen, die dann über die Schnittstelle des FC's in einen Merker oder einen DB zu schreiben und dann dieses Bit im Datenbaustein oder den Merker dann hintenrum weiter zu benutzen. Warum zum Henker schreibt man das dann nicht gleich in einen Merker, sondern fummelt sich da einen ab?
Für solche Sachen wie "Futter gespannt", die für die Fehlersuche wichtig sind und/ oder in anderen Bausteinen benötigt werden, benutze ich Merker.
Die Leute, von denen ich spreche, benutzen Merker überhaupt nicht. Stattdessen wird entweder alles in DB's geschrieben oder mit Variablen zurechtgefummelt. Das wäre mit Merkern deutlich eleganter und einfacher gelöst.
Ich hab' irgendwo noch ein Beispiel davon rumliegen.

Dass wir keine Bussysteme einsetzen, liegt nicht daran, dass sie "böse" sind, sondern dass sie in von der Baugröße her kleinen Anlagen (Baugröße 5 auf 5 Meter) und ca. 20-30 Ein- und ca. 20 Ausgängen nicht wirklich relevant sind.
Bei der 840D sl laufen die Sinamics- Antriebe auf Profibus.

 

[vladi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kompliziert..

Hi Kollege,

An der CNC kann ich Merker beobachten,
........
....Dass wir keine Bussysteme einsetzen, liegt nicht daran, dass sie "böse" sind, sondern dass sie in von der Baugröße her kleinen Anlagen (Baugröße 5 auf 5 Meter) und ca. 20-30 Ein- und ca. 20 Ausgängen nicht wirklich relevant sind.

solche komplizierte und grosse mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt ..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 . Und das ist oft so, leider.

Vladi

 

[zotos]

...
solche komplizierte und grosse mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt ..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...
...

*ACK*

Hochsprachenprogrammierung und SPS-Programmierung sind zwei grundlegend verschiedene Welten.
...

@arcis: Es mag ja für Dich so schön einfach sein, die Programmierer Welt in "SPS-Programmierer" und Hochsprachen Programmierung zu unterteilen. Die Realität sieht da aber ganz anders aus.
Ein SPS-Programmierer ist der der SPSen Programmiert. Für einige Aufgaben ist eine Hochsprache eben deutlich besser geeignet und da sollte man es auch einsetzten.

Dazu ist jeder Programmierer ein Mensch und somit ein Individuum. Ich würde mich nicht wagen alle auf gerade mal zwei Schubladen aufzuteilen und das noch zu bewerten.

 

[Ralle]

Hi Kollege,


solche komplizierte und grosse mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt ..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 . Und das ist oft so, leider.

Vladi

Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.

Doch es gibt mindestens einen:

...
zurück zum Thema:

mein Beitrag sollte zeigen dass ich die Einwände von TobiasA in Punkto Lokalvariablen verstehe. Es heisst nicht dass ich das so mache. Aber mal zum Nachdenken! Nicht alle Kunden haben eine Instandhaltung, nicht alle SPSen haben Fernwartung, nicht alle Kunden sind räumlich um die Ecke. Hilfe - und sei es nur ein Signalzustand helfen teilweise bei der Diagnose. Man kann dann eine Lösung ausarbeiten und damit zum Kunde. Sollte doch Kosten sparen, oder? Genauso wie innovative SPS-Tools ;-)
...

 

[Ralle]

Doch es gibt mindestens einen:

Zotos, es ging ausschließlich um das Zitat, das ich erwähne, nicht um irgendwelche Dinge die irgendjemand, irgendwann abgelassen hat!

 

[vladi]

Ok, Ok

Hi,

Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.

ist ja gut, ich dachte, solche Disskusionen haben zumindest eine gute Seite: vielleicht denkt man mehr an gute hier vorgeschlagene Programmiermethoden bei der nächsten Anlage. Ich mache das. Vom Forum habe mich für einige gute Sachen inspirieren lassen, auch wenn die in KOP waren. Aber es gibt auch Holzköpfe, die wissen alles besser, und ihre Anlagen..na ja.. da muss die Instandhaltung täglich rangehen.

Ich entschuldige mich für Alles, was evtl. Jemand beleidigt hat!
Schönes Wochenende:

Vladi

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