TIA AWL, KOP oder FUP

strippler

Level-1
Beiträge
2
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin moin,

befasse mich grade ein wenig mit SPS und hab auch schön ein paar Standard Programmierungen hinter mir.

Gibt es eine Empfehlung in welcher Programmiersprachen man als Anfänger anfangen sollte??

Sollte man AWL auf jeden Fall drauf haben oder kann man das vernachlässigen wenn man sowie so in FUP programmiert.

LG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also im ersten Netzwerk nehme ich immer AWL, dann traut sich keiner
weiter zu schauen. Wenn es dann doch einer tut geht es mit KOP weiter,
wo ich dann 254 Kontakte in reihe schalte, meistens stürzt beim scrollen
TIA ab. OK ... OK ab den dritten Netzwerk kommt dann ein Goto Netzwerk 1
in SCL und man sitzt in einer Endlosschleife fest.
 
Man sollte das richtige Werkzeug nehmen um die Aufgabe zu lösen. Beherrschen sollte man alle Editoren also Kop, Fup, AWL, SCL, und Graph.

gruss
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der René spricht mir aus der Seele ...

Aber jeder soll wählen was ihm liegt!

Ich sehe die Geschichte mit den Programmiersprachen wie Religion. Es gibt verschiedene, jede hat ihre Vor- und Nachteile.
Ich habe meine Wahl getroffen, und schwatze sie nicht jedem auf. Ich erwarte aber das ich auch nicht zugequatscht werde was denn für mich das Richtige wäre!

Grüße

Marcel
 
Pah. Kop und Graph sind unnötig und Fup is nur für Anfäger :sc6:

mfG René

Jedem das seine. Ich habe z.B. jahrelang Montageanlagen im Sondermaschienenbau programmiert, viele pneumatische Achsen, viele Servoantriebe, viele Bewegungen parallel. Das geht, meiner Meinung nach, mit Graph am besten. Naja, und KOP ist halt ne passion von mir... Aber wie einige Vorredner schon meinten, für jede Aufgabe, das richtige Tool. Beherrschen sollte man alle.
 
Ich programmiere nur noch mit Siri, das schickt den Code zu Apple, der kommt korrekt zurück und das wars. :)
Aber Spaß beiseite, wer AWL kann, der kann fast allen Code halbwegs lesen, aber es ist kein Muß. FUP/KOP ist sicher gut, ST/SCL sollte man sich auf jeden Fall ansehen.
Alles in Allem hängt viel von der Aufgabenstellung ab, reine Bitschubserei mache ich immer noch in KOP/FUP (ist einfach sehr übersichtlich), Kommunikation und Datengeschubse in AWL oder SCL.
 
Gut das du richtig Ahnung hast......... :rolleyes: .... Aber wie man so einen Quatsch schreiben kann ist mir unerklärlich.

Hehe. ;-)
Die Frage nach der Programmiersprache im sps Forum ist dasselbe wie die Frage nach dem richtigen Öl im Autoforum. Oder der richtigen Reitweise im Pferdeforum.

Trotzdem bei Siemens hat jede Sprache ihre Berechtigung. Ausser FUP das ist nur dazu da, dass das Scrollrad der Maus nicht umsonst ist.
Im ernst in FUP werden selbst einfachste Verknüpfungen schnell 20 Seiten Lang. Ich sehe keinen Vorteil darin. Ausser das Menschen mit einer Schreibschwäche auch ein Programm zusammenklicken können.

Fup in siemens ist ja auch nur awl sehr viel platzintensiver dargestellt. Das ist bei Fup z.b. Bei SAIA ganz was anderes.

Mit freundlichen Grüßen René
 
Hi

und man sollte die Performanceunterschiede der Sprachen nicht ganz außer acht lassen.

Bei der 400 geht alles über AWL. Bei linearen Programmen (wer hat das schon) ist die Laufzeit / Zykluszeit proportional der MC7 Länge. Doppelt so viele L MW10 brauchen doppelt so lang.
Bei der 300 geht auch alles über AWL. Selbst bei linearen Programmen schwankt die Laufzeit / Zykluszeit gegenüber der MC7 Länge. Zumindest bei der 319 gilt der Satz "doppelt so viele L MW10; T MW20; brauchen doppelt so lang" nicht! Man muss schon unterschiedliche Adressen nehmen. Unsinniger Code braucht keine Laufzeit.

Wenn eine kleine SCL-Zeile oder ein Bausteinaufruf in hunderte AWL Befehle abgebildet wird, dann dauert das eben.

Bei der 1200 gibt es kein AWL. Das was man mit KOP/FUP und SCL machen kann scheint viel weniger MC7Strich zu brauchen als auf der 400. Entsprechend schneller läuft es. Wobei die 1200 als "Kleinwagen" von haus aus ja nicht gerade schnell ist. Aber ich vergleiche ja die Sprachen. Bausteinaufrufe schlagen trotz aufwändiger Parameterübergabe bei weiten ncht so dramatisch zu wie bei der 400.

Die 1500 lässt sich nicht in die Karten schauen. Aber den Codespeicherbedarf bekommt man angezeigt. Und der ist genauso wie bei der 1200. Semantisch äquivalentes KOP/FUP und SCL geben sich nix bezüglich der Laufzeit.
AWL braucht mehr Code und läuft auch noch sehr unterschiedlich schnell. Ein von KOP nach AWL gebrachtes Programm läuft in KOP genauso schnell wie in AWL. Ein reines AWL Programm das mit AR und Anzeigewort hantiert, das ist richtig häßlich langsam.
Solange man mit Daten in optimierten Bausteinen rechnet dann ist die 1500 deutlich schneller als mit Daten in standard Bausteinen.


RUNTIME sei dank
HB


Hey Big S: Warum kann man eigentlich nicht KOP/FUP und SCL innerhalb eines Bausteins mischen? Wie Ralle schon sagt: Bitschubsen in KOP/FUP. Rechnen und Datenschubsen in SCL. Das wäre ein Traum.
 
Hi Aventinus

lies noch mal was ich schrieb. Es gibt deutliche Unterschiede zwischen 400, 300 (wobei die 319 anders war als die 316), 1200 und 1500.

bei der 400 wird jede Zeile ausgeführt. Wer 1000 mal L MW10 schreibt, der führt auch 1000 mal L MW10 aus entsprechend lang (Zykluszeit) dauert es.

bei der 319 ist das nicht so. Wer dort 1000 mal L MW10 schreibt, der kommt viel schneller weg. Die Ausführungsgeschwindigkeit (Zykluszeit) steht nicht mehr im direkt proportionalen Verhältnis zur Codegröße. Hier scheint die 319 selbst zu optimieren. Ob das auch bei einer 314 so ist weiß ich nicht. Ich vermute mal dass das von der Firmware-Version abhängt. Habe das aber nie nachgeprüft.

bei den 1200 wird durch TIA optimiert. Wer 1000 MOVE boxen mit immer den gleichen Variablen direkt hintereinander schreibt, der bekommt genauso viel Code wie bei einer einzigen MOVE box.

bei der 1500 wird noch viel mehr optimiert. S. verrät aber nicht was und wie. Ich habe bei meinen Spielereien mit RUNTIME folgendes interessante beobachtet.

Ein KOP Programm mit einem OB, einem DB, zwei FC. Der OB ruft die FC auf. DB und OB bleiben unverändert. Das Programm wird sowohl bei einer 1214 als auch bei einer 1516 verwendet. Der erste FC enthält ein paar Netzwerke, die eigentlich nix wichtiges machen. Ein bischen Addieren ein bischen subtrahieren. Ein wenig UND und ODER und ein paar Spulen. So zwanzig mittelgroße Netze. Weil ich ja Zeit messen will waren auch ein paar TON dabei. Die Instanzen dafür waren mit im DB. Eigentlich habe ich irgend was aus einem anderen Programm "geklaut", denn ich wollte wissen wie schnell der eine Baustein läuft. Dann habe ich mir im DB dafür eine Testumgebung geschaffen.
Der zweite FC ist SCL. Der wird nur benutzt um mit RUNTIME die Laufzeit des ersten FC zu vermessen. was ja leider nur mit SCL klappt.

Vermutung: Wenn ich die zu vermessenden Netze doppelt rein kopiere in den FC, dann sollten sich sowohl die Codegröße als auch die Laufzeit verdoppeln.
Überraschung: Nein die Laufzeit bleibt im wesentlichen gleich. Selbst die Codegröße bleibt im wesentlichen gleich.

OK, dann mach ich das halt noch mal. Also eine dritte Kopie und eine vierte Kopie der zwanzig Netzwerke in den FC.
Überraschung: Die Laufzeit bleibt fast gleich. Die Codegröße bleibt fast gleich. :rolleyes:

Dann habe ich einen zweiten DB erzeugt, eine Kopie des ersten. Bin wieder auf die 2*20 Netz version zurück und habe in den zweiten zwanzig Netzwerke die DB-Zugriffe auf den zweiten DB gebogen -- suchen und ersetzen :) Jetzt wird ja in den kopierten Netzwerken auf was anderes zugegriffen.
Vermutung: sowohl die Codegröße als auch die Laufzeit sollten sich verdoppeln.
Im wesentlichen ja
Aber jetzt zeigen sich Unterschiede bei 1200 und 1500. Bei der 1200 komme ich sowohl für Laufzeit als auch für Codegröße auf den Faktor 1,9. (Meine TON sind nicht verdoppelt)
Bei der 1500 komme ich für die Laufzeit auf den Faktor 1,5 und bei der Codegröße auf den Faktor 1,8.

Wie gesagt, das gilt für die 1200 und die 1500. Nicht für die 400.

Was mir negativ aufgefallen ist, ist jedoch die Compilezeit. Bei den 20 Netzen kaum zu messen. Bei 10*20 Netzen dauert es Minuten -- soweit ich mich erinnere so 5. Bei 20*20 Netzen dauert es nicht 10 Minuten sondern 17 Minuten. Und bei 100*20 Netzen ist es regelmäßig wegen zu wenig Speicher durch Windows zwangsbeendet worden.

Hingegen ein Baustein mit 400 Netzen wo sich nichts wiederholt, wird in 3 Minuten übersetzt ... hm. Der Compiler scheint verbesserungsfähig.

'n schönen Tach auch
HB
 
Zuletzt bearbeitet:
bei den 1200 wird durch TIA optimiert. Wer 1000 MOVE boxen mit immer den gleichen Variablen direkt hintereinander schreibt, der bekommt genauso viel Code wie bei einer einzigen MOVE box.

Was für Speicherbereiche hast du da denn hin- und hergeschoben? Vielleicht gibt es ja mittlerweile sowas wie "dead code elimination", also Programmteile die keine Auswirkung haben werden entfernt. Das dürfte in der SPS aber eigentlich nur bei lokalen Temp-Variablen geschehen, da auf alle anderen Bereiche (statische FB Variablen, Merker, Global-DBs) auch von anderen Programmteilen wie Interrupts zugegriffen werden kann (die sind sozusagen volatile).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Thomas

sowohl als auch. Also Lokales und globales. Sonst hätte ich mir die Arbeit mit dem zweiten DB ja nicht machen müssen. Aber so weit ich mich erinnere waren das meiste Inputs, gefolgt von Temp, gefolgt von globalen DB-Zugriffen, gefolgt von Outputs.

Ich hab mal schenll was ausprobiert. Du hast recht. 100 mal L LD10 verschwindet. 100 mal L MD10 bleibt erhalten. Also jetzt mal nur auf die Codegröße geschaut, die PLCs sind so weit weg.

cool. Es gibt scheinbar sowas wie "dead code elimination" für 1500.

Und Konstanten in SCL scheinen auch zu verschwinden. #a[1]:=3+4+5; #a[2]:=3+4+5; #a[3]:=3+4+5; ....
braucht genauso viel Platz wie #a[1]:=12; #a[2]:=12; #a[3]:=12; ....


Die werden doch nicht einen richtigen Compiler machen :ROFLMAO:
HB
 
@HelleBarde

Aber 100*20 Nertwerke, das ist jetzt nicht wirklich viel und gibt mit zu denken :-(

Wenn man dann einen einzelnen Baustein ändert, dauerst es wieder 17 Minuten oder wird dann wenigstens nicht alles compiliert? Sollte ja so sein.
Leider konnte ich bei mengen TIA versuchen ebenfalls feststellen, dass es keine wirklichen Regeln für das Ergebnis gibt, das aus dem Code entsteht.
Das finde ich eigentlich recht unerfreulich für eine SPS, aber ist ja auch bei anderen neuen Systemen nicht mehr viel anders.
Man weiß im Prinzip nicht mehr, was genau man da codiert...
 
@HelleBarde

Aber 100*20 Nertwerke, das ist jetzt nicht wirklich viel und gibt mit zu denken :-(

Mir auch, aber wie oben geschrieben: wenn sich nichts wiederholt, dann geht es viel schneller. Offensichtlich kostet die Suche nach dem "unnützen Code" einiges an Zeit.

Ich finde ja toll, dass sowas wie "dead code elimination" "constant folding" und "value propagation" verwendet wird. Und wenn wir schon von anderen Systemen reden: Beckhoff verwendet beim TWIN CAT System ja einen richtigen C-compiler von Microsoft. Der macht bestimmt noch viel mehr solche Sachen (sprung vorhersagen, register renaming, ... ). Wir wissen immer weniger was die Teile tatsächlich machen. Aber solange die das richtig tun kann es uns doch egal sein. Und wenn man dann liest, was so ein Prozessor heute alles kann und hat (out of order excecution, 3 level von caches, mehrere Kerne, Hyperthreading ... ) , dann bin ich eigentlich froh, dass ich keinen Compiler mache sondern ihn verwende und meckern darf was die anderen alles schlecht machen :)

Problematisch ist es wenn der Compiler so ewig braucht wie der von S und noch problematischer wird es wenn das was raus kommt nicht das ist, was in der Referenz darüber behauptet wird -- siehe SCL und dern REAL-bug.:sad:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie viele Anweisung hatte denn ein Netz? Wenn nur eine Anweisung, dann wären das ja nur 2000 Anweisungen, da kann doch keiner 17 Minuten dran rumrechnen diese Anzahl zu übersetzen. In der Zeit übersetzt man einen kompletten Linux Kernel...

Was das Hauptproblem bei der ganzen Optimiererei ist, dass der Code nachher noch online beobachtbar bleibt.
Was wird dir in deinem Baustein wo der Compiler die meisten Anweisungen rausgeworfen hat denn online angezeigt?
Online-Status nur bei einer Anweisung, wird einem bei den anderen Anweisung was vorgegaukelt, oder ist dieser Baustein dann sozusagen ohne Debug-Informationen und nicht beobachtbar?
Das alles konnte man bei Step 7 am SCL-Übersetzer noch einstellen. Beim TIA-Portal scheinen die ganzen Optionen entfallen zu sein.

TwinCAT hat imho die Codegenerierung von Codesys übernommen, und bei Codesys ist die Codegenerierung laut Aussage eines 3S Mitarbeiters hier im Forum eine komplette Eigenentwicklung. TwinCAT 3 nutzt das MS Visual Studio nur als Rahmen. Es gibt auch von Atmel das AVR-Studio, welches als GUI ebenfall das Visual Studio verwendet, die Codegenerierung übernimmt aber der (AVR)-GCC.
 
Hi Thomas

die zwanzig Netzwerke haben so in etwa abgerundet 800 Bytes Code erzeugt. Plus die TON und ein Compare vorne und hinten. Macht dann 900 Bytes. Pro Kopie kommen aber nur rund aufgerundet 100 bytes dazu. Also sind circa 700 Bytes als unnütz betrachtet worden.

Doch, doch, leider kostet das Finden der 100 unnützen Kopieen 17 Minuten.


Mir hat vor zwei Jahren einer von Beckhof erzählt, dass der 3S Compiler verwendet wird um aus KOP/FUP/SCL und AWL C zu machen. Das ist bestimmt eine Eigenentwicklung. Und jetzt kämme es drauf an was du für ein Zielsystem hast. Wenn das ein Mehrkern Celeron ist, dann wird das C wird vom Microsoft Compiler in x86 verwandelt. Bei der TwinCat ist da ja noch ein gewaltiges Laufzeitsystem dazuzubinden, bevor aus einem PC104 System eine Steuerung wird.

Wenn du ein Zielsystem auf ARM-Basis hast, dann sei es der GCC.

Aber der Beckhof-Mann kam damals schon ziemlich ins schwimmen und schwitzen. Ich wußte schon da nicht, was ist davon Marketing Lüge und wo steckt der wahre Kern des Pudels.


Gibt es außer 3S, S und KirchnerSoft überhaupt einen Hersteller für IEC 61131-3 Sprachen? Mir fallen nur die drei ein, obwohl es zig Steuerungshersteller gibt. Aber die verwenden alle 3S. Halt, da ist ja noch VIPA, die haben auch eine IDE.

'n schön' Tach auch
HB
 
Zurück
Oben