Frage zu SPS

[blurry333]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum kann man eine SPS denn nicht einfach mit der Programmiersprache C++ programmieren ? Warum eine eigene Sprache .

U E1.0
U E1.1
= A0.0

in C++

if(E1.0 && E1.1) A0.0

Wozu also AWL lernen ?

 

[bike]

Warum kann man eine SPS denn nicht einfach mit der Programmiersprache C++ programmieren ? Warum eine eigene Sprache .

U E1.0
U E1.1
= A0.0

in C++

if(E1.0 && E1.1) A0.0

Wozu also AWL lernen ?

Es steht dir doch frei, die PLC in C++ zu programmieren.
Dumm ist es nur, wenn die PLC dich nicht versteht.

Es ist doch müßig nachzudenken, warum es verschiedene Programmiersprachen gibt.


bike

P.S: ist der Siemensserver wieder online?

 

[eYe]

Zuviel Werbung?
-> Hier kostenlos registrieren

1) Es gibt SPSen die lassen sich mit C++ programmieren
2) Niemand zwingt dich AWL zu nutzen
3) AWL war lange vor C++ da
4) Zeig mir mal den C++ code um das 3te Bit aus nem byte auf True zu prüfen?

 

[blurry333]

ein Microcontroller wird auch mit C programmiert.

Und da kann man auch die bits prüfen .

 

[zotos]

Nimm doch ST/SCL das ist an Pascal angelehnt.

A0.0 := E1.0 AND E1.1;

C und C++ ist mir eh zu kryptisch.

 

[Tommi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wie schon gesagt wurde, AWL stammt aus den Anfängen der SPS
und hat sich bis heute gehalten.

Die Hochsprachen sind heute "Konkurenz" für AWL und was besser ist,
darüber kann man wunderbar stundenlang diskutieren.

Leute, die Hochsprache gelernt haben, SPS vorher nicht kannten und jünger als 30 Jahre sind, verstehen oft nicht, warum es AWL überhaupt gibt.

Komplexe binäre logische Verknüpfungen kann man sehr gut mit den
grafischen Sprachen KOP und FUP darstellen, insbesondere den
Signalfluss.

Was genommen wird, hängt von den Vorlieben des Programmierers ab,
oder davon, was der Kunde bestellt hat.

Das es auch Hochsprachen für SPS gibt (ST oder SCL), ist Dir bekannt?

Programmiersprachenmix ist in der SPS auch möglich.

Gruß
Tommi

 

[MCerv]

Soll das jetzt ne Grundsatzdiskussion werden?

Wo sind wir? - In der Automatisierungstechnik!
Hier gibt es die drei Grundsprachen AWL / KOP / FUP zum steuern von Maschinen, Anlagen und Prozessen.
Da aber die Jungs von der UNI sich imma damit schwer tun, bzw. für gewisse Aufgaben es einfacher ist diese in einer Hochsprache besser zu lösen gibt es bei SIEMENS noch SCL.
Und dann gibt es da ja noch GRAPH, welches ideal für sich immer wiederholende Abläufe (kurz Schrittketten) ist.

Wie schon gesagt sind wir in der Automatisierungstechnik und ich denke es gibt für jeden Anwendungsfall das passende Tool. Ideal ist oft eine Kombination von Mehreren.

 

[zotos]

Soll das jetzt ne Grundsatzdiskussion werden?
...

Ja warum denn nicht? Ich führe die Grundsatzdiskussion hier im Forum schon seit 2004 und die Entwicklung gibt mir recht. ST/SCL hat in den letzten Jahren deutlich an Bedeutung und Beliebtheit gewonnen. Ich spiele mal etwas "Orakel" und behaupte in zehn Jahren hat ST/SCL diese Seuche ("AWL" genannt), bei Neuentwicklungen überholt.

 

[MCerv]

Zuviel Werbung?
-> Hier kostenlos registrieren

...Ich spiele mal etwas "Orakel" und behaupte in zehn Jahren hat ST/SCL diese Seuche ("AWL" genannt), bei Neuentwicklungen überholt.

Soweit würde ich nicht gehn, 10 Jahre, eher 20!
Was macht die Stärke eines Tools aus?
1. Es muss einen hohen Funktionsumfang haben (SCL stimmt)
2. Es muss von vielen beherscht werden (SCL stimmt nur bedingt, da die Berufsschulen oft noch auf die Klassiker setzen, ausgenommen die Technikerschulen!)
3.Es muss ein gut zu bedienender Editor vorhanden sein. (SCL, bei S7 -V5.5 war dieser sehr umständlich, ab V11 ist er besser. Mal sehn was die Praxis zeigt)

Was ist so schlimmes an AWL / KOP / FUP? Denk daran, auch wenn SCL an Bedeutung gewinnt, gibt es jede Menge Altanlagen, bei denen die Programme nicht in SCL geschrieben sind und dennoch supportet werden müssen! Wenn Du Glück hast musst Du Dich nicht mit Step 5 rumschlagen, aber es gibt genügend die das noch tun müssen. Maschinen / Anlagen werden in der Regel nicht alle 10 Jahre ausgetauscht nur weil es neue Technik gibt, geschweige denn modernisiert, wenn es nicht notwendig ist! Man darf die Industrie nicht mit der Hauselektronik verwechseln. In der Industrie hällt alles etwas länger!

 

[Tommi]

Ich spiele mal etwas "Orakel" und behaupte in zehn Jahren hat ST/SCL diese Seuche ("AWL" genannt), bei Neuentwicklungen überholt.

möglich, wenn die erste uns zweite Generation SPS-Programmierer im wohlverdienten Ruhestand ist.

Aber das soll sich ja noch etwas verzögern, Stichwort "Rente mit 69"

@blurry333: Gibt es einen besonderen Grund für Deine Frage?

Gruß
Tommi

 

[Magni]

Ich benutze AWL zb. um etwas kurz und schmerzlos zu halten. Mehrere Ladefunktionen hintereinander zb. sind in einem Netzwerk möglich. Würde ich das in FUP oder KOP programmieren, würde das ausufern. Ich benutze es, wie ich es brauche. Abläufe hingegen lassen sich übersichtlicher in FUP oder KOP programmieren. Ich möchte nicht auf AWL verzichten. Dabei ist es doch eigentlich uninteressant ob man die Befehle in einer Zeile (C++) oder untereinander schreibt. Davon abgesehen möchte ich eine Statusanzeige in C++ sehen....

Gruß Heiko

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

@blurry333: Gibt es einen besonderen Grund für Deine Frage?

Bestimmt, der Server von Siemens funktioniert wieder.
Und mit solchen klugen Fragen wird man schnell und einfach zum erfahrenen Nutzer.

Schau dir einfach die anderen Threats von ihm an, dann siehst du einiges.


bike

 

[zotos]

...
Was ist so schlimmes an AWL...

Ich beschränke mich mal auf AWL. Es sind die gleichen Gründe warum wir heute kaum noch Programme in Assembler schreiben.

Hochsprachen sind so konzipiert das man sie besser lesen kann. Das verbiegen von irgendwelchen Akkus und Adressregistern gibt den alten Hasen, dieses Gefühl hardwarenah zu programmieren. Das stimmt auch wenn man die SPS als Hardware sieht. Höhere Sprachen ermöglichen es, durch ihre Strukturelemente, sich näher an die Anlage und den darin ablaufenden Prozessen zu orientieren.
Verzweigungen, Schleifen, Index basierende Zugriffe sind zwar nur ein kleiner aber wichtiger Schritt. Wilde Pointerei mit der Verbiegung von Adressregistern ist eben so lästig und schwer wartbar wie Spagetticode Sprünge. Nicht ohne Grund sind Sprünge (Goto) verpönt.

AWL hat sich ja auch ein wenig verbessert siehe SPL und Loop aber es ist immer noch eine wenig abstrahierende Sprache. Um noch mal auf die Hardwarenähe zurück zu kommen. Das Sprachen wie SCL und Graph die CPU übermäßig belasten, ist ein Armutszeugnis für den Hardwarehersteller.

 

[MCerv]

...Um noch mal auf die Hardwarenähe zurück zu kommen. Das Sprachen wie SCL und Graph die CPU übermäßig belasten, ist ein Armutszeugnis für den Hardwarehersteller.

Aber sind wir das nicht bereits von Windows gewohnt? Kaum kommt ein neuer Prozessor, kommt ein neues Windows, was noch komfortabler und leistungsfähiger ist. Ich geb Dir recht, das GRAPH recourcenhungrig ist. Jedoch wenn ich mir die neuen CPU's betrachte, dann spielt das gar nicht mehr so eine gravierende Rolle (mehr Speicher mehr Performance, like Windows, wer arbeitet mit LINUX?). Für mich entscheidet der Komfort einer anwendungsgerechten Lösung. Dort wo GRAPH Sinn macht kommt es zu Einsatz, genauso wie SCL und auch AWL, ...

 

[SoftMachine]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen !

Ich spiele mal etwas "Orakel" und behaupte in zehn Jahren hat ST/SCL diese Seuche ("AWL" genannt), bei Neuentwicklungen überholt.

Um noch mal auf die Hardwarenähe zurück zu kommen. Das Sprachen wie SCL und Graph die CPU übermäßig belasten, ist ein Armutszeugnis für den Hardwarehersteller.

Bei allem Respekt...
aber hast du schon mal überlegt, das die CPU-Proz. eben genau auf diesen AWL-InstructionSet ausgelegt/optimiert sind ?
Oder wo kommen die geringen Bearbeitungszeiten oder/und Zykluszeiten her ?
Mach das mal mit Hochsprache und Win
Die Hochsprachen werden doch auch erst übersetzt, bevor sie ablauffähig sind...

Vielleicht sollte im Schaltschrank eine S7-PC-CPU-Baugruppe mit 500GB HD, 4GB DRAM, Kartenleser, Monitor-Anschluss und Win 7 verbaut sein ?
Und dann Alarmbearbeitung ...

Wie schon gesagt sind wir in der Automatisierungstechnik und ich denke es gibt für jeden Anwendungsfall das passende Tool. Ideal ist oft eine Kombination von Mehreren.

... eben ...

Für mich entscheidet der Komfort einer anwendungsgerechten Lösung. Dort wo GRAPH Sinn macht kommt es zu Einsatz, genauso wie SCL und auch AWL, ...

...so isses ...

Gruss an beide

P.S.: @ ZOTOS: aber nichts für ungut

 

[zotos]

Bei allem Respekt...
aber hast du schon mal überlegt, das die CPU-Proz. eben genau auf diesen AWL-InstructionSet ausgelegt/optimiert sind ?
Oder wo kommen die geringen Bearbeitungszeiten oder/und Zykluszeiten her ?
...

*ROFL*

Kurze Zykluszeit?! Du redest doch nicht von den Millisekunden (Plural) die so eine moderne Siemens CPU immer noch braucht.

Zu dem Thema der Auslegung. Ach und das ist ein SPS-spezifische Sache? Wie ist es den bei PC Prozessoren, oder dem Prozessor von so einem Smartphone, oder einem wirklich schnellen DSP (Digitaler Signalprozessor)?
Wenn man wie Du für die Geschwindigkeit von SPSen die Programmiersprache AWL verantwortlich macht, steckt man wahrscheinlich eben so wie der ganze Siemens SPS-Kram noch in den Achtzigerjahren des letzten Jahrhunderts fest.

Das im Siemens-Umfeld immer noch AWL "das Maß aller Dinge" ist liegt an der fehlenden Alternative die Siemens einfach nicht bietet. SCL war und ist bisher noch aufpreispflichtig, dazu ist der Editor eine Zumutung. Die Sprache an sich ist sehr leistungsfähig und komfortabel.

...
Mach das mal mit Hochsprache und Win
Die Hochsprachen werden doch auch erst übersetzt, bevor sie ablauffähig sind...

Das ziemlich wenig mit dem Thema zu tun. Das eine CPU am ende eh nur 0 und 1 sieht, ändert nichts am Vergleich Hochsprache vs. Assembler bzw. SCL vs. AWL

Oder willst Du PC-Anwendungen von nun an auch wieder in Assembler programmieren? So was ist etwas für Treiber und kleine schnelle Sachen aber nichts für große Projekte.

 

[bike]

wer arbeitet mit LINUX?).

ich, daher schreibe ich meine Bausteine zu 80% in Quellen.

Mehr Komfort? Ja, mehr Programmcode im Hintergrund, der macht was er will.
Mehr Angriffsstellen für Viren und ähnliches bzw Fehlfunktionen, die nicht zuuu erklären sind.
Muss das wirklich sein, wenn man mit Rechnern arbeitet?
Es muss nicht unbedingt eine Kommandozeile sein, doch das was jetzt ist?

Zum Thema Awl oder so der Hinweis, dass die Compiler Assembler Code generieren.
Doch welcher Compiler ist Fehler frei?
Je mehr Programme zwischen Source und ausführbarem Programm arbeiten, je mehr Fehlerquellen sind es.
In einem Hochsprachen Programm zu debuggen ist nicht so einfach wie in awl bzw in den schönen graphischen Ansichten.
Nicht jeder Instandhalter hat ein Studium mit Schwerpunkt Programmierung hinter sich.


bike

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mir ist das ziemlich egal, ob AWL oder SCL, ich nutze immer das, was mit gerade am geeignetsten erscheint und womit ich am schnellstem am Ziel bin.

Aber zu deiner boolschen Verknüpfung in der Frage. Wenn du 20 Bits hast (zur Freigabe eines Servoantriebs durch alle beteiligten Stationen kann das schon mal nötig sein), die zu verknüpfen sind, dann mach ich das in KOP/FUP, das ist das einzige, wo ich sofort sehe, was los ist, also warum mein Antrieb z.Bsp. nicht loslaufen will. In AWL ist es da schon manchmal schwierig, den Überblick zu behalten, aber in SCL bekomme ich das in dem Falle fast gar nicht gut hin und ich denke, C++ könnte das auch nicht so gut anzeigen.

Alles hat also eine gewisse Berechtigung, wenn man es denn optimal nutzt.

 

[MCerv]

...SCL war und ist bisher noch aufpreispflichtig, dazu ist der Editor eine Zumutung. Die Sprache an sich ist sehr leistungsfähig und komfortabel. ...

Mal zu Deiner Information, seit der Step7 V11 gehören SCL, GRAPH und TELESERVICE zum Grundpaket. Nur kannst Du SCL und GRAPH bis jetzt nicht für die 1200'er CPU's einsetzen! Der SCL Editor ist deutlich verbessert worden!

 

[SoftMachine]

Hallo zusammen !

Kurze Zykluszeit?! Du redest doch nicht von den Millisekunden (Plural) die so eine moderne Siemens CPU immer noch braucht.

Naja...

Also, habe ich in S7 (AWL und FUP) programmiert und hier nun als Beispiel:
-FIFO-Speicher für ca. 150 Einträge mit variablen Eintrags-Längen
-vorgeschaltetes Directory mit Beginn und Länge der Einträge
-Suchfunktion für jeden einzelnen der Einträge wegen Bearbeitung/Löschen/Prio ändern durch Bediener usw.
-Visualisierung und Bearbeitung der Stack-Einträge auf 14 Panels an der Anlage

...lief zunächst auf Win-PC-Basis.
--> Suchen, finden und anzeigen eines bestimmten Eintrags: ca. 12 s
--> Editieren/Löschen eines bestimmten Eintrags und Restaurieren des Directory und des Stacks: ca. 10 s

S7-Lösung in AWL/FUP, indirekte Adressierung mit pointern usw.:
--> Suchen/Finden und anzeigen eines bestimmten Eintrags : ca. 1 s
--> Editieren/Löschen eines bestimmten Eintrags und Restaurieren des Directory und des Stacks: ca. 3 s

Noch Fragen zur Zyklus- oder Bearbeitungszeit ???

Hier arbeitet ein ASIP (... google, google...), aber ein DSP ist das:
Ein Digitaler Signalprozessor (engl. digital signal processor, DSP) dient der kontinuierlichen Bearbeitung von digitalen Signalen (vorrangig Audio- oder Videosignale) durch die Digitale Signalverarbeitung.

Willste hier ein Multmediacenter im Schaltschrank aufmachen ???

Ein application-specific instruction-set processor (ASIP, zu deutsch etwa: Prozessor mit anwendungsspezifischem Befehlssatz) ist ein Prozessor, dessen Befehlssatz für eine Klasse von Anwendungen optimiert wurde.


Und wie MCerv auch bereits sagte:

Mir ist das ziemlich egal, ob AWL oder SCL, ich nutze immer das, was mit gerade am geeignetsten erscheint und womit ich am schnellstem am Ziel bin.

Also nochmal: jo, so isses !

Gruss an alle