Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 8 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 71

Thema: Java als SPS Programmiersprache

  1. #1
    Registriert seit
    02.05.2004
    Beiträge
    1
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    ich möchte hier die Diskussion über die SPS / PLC Programmiersprachen anstossen. Mich würde intressieren wie ihr die Programmiersprachen im vergleich seht. Mein Problem bei diesen SPS-Sprachen ist, das alle immer wieder die Norm 61131 bemühen aber trotz dem keine einheitliche Sprache sondern immer wieder dialekte von diese Norm angelegt werden.
    Hier meine Fragen:
    1.Werden die Sparchen KOP / FUP / ST / AS noch gebraucht ?
    2.Sollte nicht nur Textuelle-Sprachen verwendet werden ?
    3.Sollte als Programmiersprache nicht z.B. Java verwendet werden.
    Diese Sprache ist sehr standardisiert. Als Entwicklungs-System könnte
    eine Open Source Anwendung dienen z.B. Eclipse.

    Legende:
    Anweisungsliste (AWL), Instruction List (IL)
    - assemblerartige Sprache, nur hardwareunabhängiger Teil ist genormt
    Kontaktplan(KOP), Ladder Diadramm (LD)
    - grafische Dartsellung mit Kontakten, Kästen und Spulen
    Funktionsbausteinsprache (FBS), Function Block Diagramm (FBD)
    - analog zu Logikplänen, deshalb auch als Funktionsplan (FUP) bezeichnet
    Ablaufsprache (AS), Sequential Function Chart (SFC)
    - (grafische) Beschreibung von Ablaufketten mit Schritten und Transitionen
    Strukturierter Text (ST), Structured Text (ST)
    - Hochsprache, an PASCAL angelehnt mit SPSspezifischen Erweiterungen
    - speziell für komplexe Berechnungen und Algorithmen

    Mit freundlichen Grüßen
    EdgarRR
    Zitieren Zitieren Java als SPS Programmiersprache  

  2. #2
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Zitat Zitat von EdgarRR
    Hallo,

    bei diesen SPS-Sprachen ist, das alle immer wieder die Norm 61131 bemühen aber trotz dem keine einheitliche Sprache sondern immer wieder dialekte von diese Norm angelegt
    werden
    Hier meine Fragen:
    1.Werden die Sparchen KOP / FUP / ST / AS noch gebraucht ?
    Ja
    2.Sollte nicht nur Textuelle-Sprachen verwendet werden ?
    Nein.
    Schau dir mal COBOL an. Wenn du nicht einen masochistischen Spass am Tippen hast, verstehst du auf Anhieb was ich meine.
    3.Sollte als Programmiersprache nicht z.B. Java verwendet
    werden.
    Au ja. Ein Stromstossrelais auf einer kleinen SPS:
    Code:
    final static boolean[] Eingaenge;
    Eingaenge[] = new Boolean[14];
    final static boolean[] Ausgaenge;
    Ausgaenge[] = new Boolean[10];
    /*
    Im Gegensatz zu C,Pascal oder Makroassembler gibt es nun     	leider keine Möglickeit, die physikalischen Adressen der Ein-und Ausgänge anzugeben. Sprache erweitern oder native Bibliothek einbinden?
    */
    final static boolean[] Merker;
    /*
    So eine Definition belegt pro boolean 32 Bits. Das
    ist nicht schlechte Implementierung, sondern so festgelegt.
    Wenn man?s ändern würde, merkt man es spätestens, wenn man ein boolean in einen stream schreibt (casts gibts ja nicht).
    */
    Merker[] = new Boolean[256];
    /*
     Ok, wir wollten ja gar nicht 256 Merker verwenden, sondern nur 3:
     boolean clock, master,slave;
     wuerde es auch tun, aber wenn ich die zu einem Bus-Partner,
     z.B. Bedienpanel schicke, wie weiss ich welcher welcher
     ist ? Paket packen:
    
     byte[] panelInfo=new byte[5];
     panelInfo[2]=myFancyBitPacker.pack(slave,master); ?
     ProfiBus.send(panelInfo);
    */
    Merker[0]=Eingang[0];  // clock=Eingang[0];
    /*
      Flip-Flop:
    */
    if (Merker[0]) Merker[2]=Merker[1];
    if (^Merker[0]) Merker[1]=^Merker[2];
    
    Ausgang[0]=Merker[2];
    /*
      Das war jetzt ein Stromstossrelais. JAVA typisch könnte
      das Flip-Flop auch gleich eine Klasse sein:
    */
      public class FlipFlop {
      	boolean clock,master,slave;
    	public setInput(boolean in){
    	  clock=in;
    	}
    	public getOutput(){
    	  return master;
    	}
    	/*
    	jetzt tut es noch nix. 1.Vorschlag:
    	*/
    	public setInput(boolean in){
    	  clock=in;
    	  if(clock) slave=^master; 
    	  else master=^slave;
    	}
    /*
     Jetzt tut es was. Vielleicht wäre es aber noch
     schöner, es zu einer "autonom" agierenden
     Komponente zu machen, aus der man Netwerke "bauen" 	
     kann:
     Irgenwo im aufrufenden Programm stünde dann:
    
     FlipFlop flipFlop1;
     Eingang[0].addPropertyChangeListener(flipFlop1);
     flipFlop1.output.addPropertyChangeListener(Ausgang[0]);
    */
    
      public propertyChanged(PropertyChangeEvent e){
        if(e.get.// Auswertung von Art des Events und neuem Wert
        if(clock) slave=^master; else
    	  	master=^slave;
      }
    /*
      So, jetzt haben wir 2 Dinge geschafft: 
      1. die Reihenfolge der Abarbeitung ausgehebelt.
      Schaltnetze mit invertierenden Rückführeingängen lösen 
      jetzt Event-Stürme aus. Nachbildung eines Schütz, das
      seinen Spulenanschluss unterbricht, perfekt möglich.
      2.Im ersten Ansatz waren die Variablen statisch. Auftritt
      GarbageCollector, um den Event-Müll abzufahren.
    */
     }
    Diese Sprache ist sehr standardisiert.
    Und deshalb müssten sich die SPS-typischen booleans daran halten, wie booleans für die gelegentliche Verwendung in allgemeinen Programmen definiert wurden.
    Als Entwicklungs-System könnte
    eine Open Source Anwendung dienen z.B. Eclipse.
    Ja, das geht auch so. Man kann ja ein Eclipse-Plugin für jede der vorhandenen Sprachen schreiben: Editor, Compiler, Eingabe-Syntaxprüfung, automatische Ergänzungsvorschläge, Debugger, Simulator.
    Das kann dann Step7 und alle anderen ähnlichen Werkzeuge ablösen. Neue SPS-Marke braucht nur ein paar Erweiterungen.
    Dann haben wir alles zusammen, um eine richtig komfortable Analyse draufzusetzen:

    Du gehst an eine unbekannte Maschine, wo unerlärlicherweise der Ausgang A46.3 ("Hubtisch senken") nicht kommt. Das Tool lädt sich das undokumentierte SPS-Progamm aus der CPU. Du klickst auf "Explain state", tippst A46.3 ein und kreuzt an "explain not true". Das Tool vollzieht über beliebige Netzwerke die Ergebnisbildung nach und zeigt dir:
    1.Möglichkeit E16.3 und E32.3 müsssten 1 sein.
    2.Möglichkeit: M45.2 müsste 1 sein. M45.2 würde in PB 22 NW 3 speichernd gesetzt, wenn zu den vorhandenen Bedingungen hinzukäme: E46.7=1

    Aus dem Schaltplan:
    16.3 Handbetrieb,
    E32.3 manuell senken,
    E46.7 Initiator Tisch oben

  3. #3
    Anonymous Gast

    Standard

    Ich glaube dass die 61131 schon der richtige Weg ist. Jetzt müssten "nur noch" die Hersteller auch wirklich standardisieren.
    Das ist wirklich nicht so einfach wie es sich anhört. Die Großen Hersteller und ihre Systeme blicken ja nun auf ein paar Jährchen Entwicklung zurück und haben ihr Süppchen mehr oder weniger gut gekocht. Das jetzt einfach mit einer einheitlichen Sprache oder Sprachfamilie abzulösen ist nicht nur firmenpolitisch sondern auch technisch schwierig. Das sind historisch gewachsene Systeme. Und stell dir erst mal vor was die „älteren“… sorry das ist jetzt etwas hart… sagen wir mal die… die alteingesessenen Programmierer dazu sagen würden. Ich kann mich dunkel daran erinnern wie die S7 auf dem Markt auftauchte war das Geschrei groß. Aber von Zeit zu Zeit muss eben eine Veränderung her. Wenn man aber die AWL/FUP/KOP Programmier die eh selten zu solch nützlichen Sprachen wie ST und AS greifen dazu bewegen will (um nicht zwingen zu sagen) in einer Sprache wie z.B. Java zu Programmieren dann wird die Reaktion sehr deutlich „negativ“ sein.

    Außerdem ist Java gar nicht für die Automatisierung gedacht und das würde man immer wieder merken und bis es jeder Hersteller an sein System angepasst hätte wäre davon nicht mehr viel identisch.

    Es ist nun mal so dass es nötig ist für jede Aufgabe die Richtige Programmiersprache zu wählen. Das bestätigt wohl jeder Programmierer. Die meisten (größeren) Projekte sind wohl in mehr als einer Sprache verfasst. Wenn ich es mit einer S7 zu tun habe, benutze ich für 20-30% FUP (Verknüpfungen und Verriegelungen) das ist ziemlich unabhängig von der Aufgabe den Rest teilen sich dann ST für Berechnungen und Wortverarbeitung und natürlich AS (Graph7) für den Ablauf. Das man die Aufgaben z.B. nur in AWL lösen könnte ist ja wohl jedem klar, ob es sinn macht wohl eher nicht.

    Warum eigentlich Java? Viele SPS-Hersteller bieten doch an C Programme zu implementieren das kannst Du auch mit dem Notepad schreiben und anschließen Kompilieren.

    Mir gefällt CoDeSys von 3S sehr-gut. Ich habe eine Entwicklungsumgebung für Hardware von verschiedenen Herstellern bzw. für Soft-SPS&en.

    Gruß

    ZoToS

  4. #4
    Registriert seit
    07.05.2004
    Ort
    Campbelltown
    Beiträge
    2.437
    Danke
    131
    Erhielt 276 Danke für 86 Beiträge

    Standard

    Hi,
    ich programmiere S7 und B&R. Ich hasse dieses eingeschränkte S7-Zeug. Die B&R kann C und Automation Basic neben KOP,AWL,AS. Ich bevorzuge die C und A-Basic. Ich habe noch nie ST unter S7 getestet, steht aber ganz oben auf der Liste. Kann ich da auch mit Zeigern und Strukturen vernünftig arbeiten?

    Das Problem ist, nicht jeder SPSler hat ein gescheites Infostudium oder ähnliches. Schon gar nicht die Elektriker, Kundendienstler, denk an die kleinen Betriebe. Deshalb kommst Du nicht um die KOP,FUP Sache herum. Das nichts untereinander kompatibel ist, ist schei.... und lässtig. So schreibe ich ein Standardprogramm unter S7 und ein halbes Jahr tippe ich es in B&R.

    Zottelchen hat ja einen Kurz kommentar geschrieben. Leg den mal einem Nichtinformatiker vor.

    Gruß pt

  5. #5
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Bin selbst kein "gelernter" Informatiker
    Unter anderem dachte ich, daß dieser Kommentar den ursprünglichen Poster von seiner eigenen Idee abschrecken möchte.
    Ich selbst wäre ganz zufrieden wenn es nur einen gescheiten Assembler von jedem SPS-Hersteller gäbe. Eingabe in beliebigem Texteditor, assemblieren fertig. An Step7 habe ich mich gewöhnt. Microwins Syntaxhilfe fügt mir Schaden zu: Ich tippe was ein, Microwin korrigiert, ich weiss im selben Moment, daß es nicht korrekt ist, korrigiere aber die Korrektur,nicht meine Eingabe, woraus wieder Müll entsteht...

    Dein S7 nach B&R Problem liesse sich dann so lösen:
    1. Im S7 Quelltext per Suche&Ersteze oder per Script bekannte Inkompatibilitäten durch äquivalente Ausdrücke von B&R ersetzen.
    2. Eventuell verbleibende Reste nacharbeiten.

    Wenn das zu viel Arbeit macht oder nur oft genug vorkommt, eigene Makros schreiben, die sich per #define oder Schalter im Script S7- oder B&R-spezifisch auflösen lassen.

    Edgar könnte dann ein Backend (Codegenerator) zu GCJ (gnu JAVA Compiler) haben, was ihm den Assemblercode beliebiger Steuerungen aus JAVA erzeugt. Einmal in der Welt, würde dieses Backend automatisch auch mit GCC (gnu C Compiler) fuktionieren und dir gestatten, die Steurung in C zu Programmieren. Liebhaber erhielten Fortran und Ada als Dreingabe.
    Das alles bräuchte noch jeweils eine ( für C kleine, für JAVA grosse) Zusatzbibliothek, die ein paar Funktionen
    enthält, die der Compiler zur Laufzeit vorraussetzt.

  6. #6
    Anonymous Gast

    Standard

    Das mit dem Assembler hört sich zwar gut an ist aber nicht so. Das würde nie ein wirklich gutes System ergeben wenn Du versuchst eine Maschine in Assembler zu Programmieren. Selbst C ist sehr unkomfortabel für aufgaben die nach dem Prinzip der Echtzeitfähigkeit laufen sollen. Man verfängt sich sehr schnell in einer schleife oder spricht eine falsche Hardwareadresse an. Bei Assembler mit den ganzen JMP (Jump&s/Goto&s) würdest Du wahnsinnig werden. Dazu kommt noch das Betriebssystem der Hersteller, jeder Hersteller hat da doch ein OS auf der Kiste laufen um die Hardware anzusprechen und übergeordnete Funktionen wie Schnittstellen-Protokolle, Watchdogs, Diagnosetools, etc. zu realisieren.
    Das ist mit Sicherheit auch nicht überall gleich!
    Es gibt aber doch Steuerungen die mit C Programmiert werden?! Ja, die gibt es und zwar jede menge. Aber die meisten benutzen diese Funktion als Erweiterung um Abläufe zu programmieren komplexe Berechnungen auszuführen… eben um Algorithmen abzubilden.
    Der „Verknüpfungskram“ ist dort meist immer noch in einer SPS-Funktion in AWL/FUP/KOP gelöst. Was soll euere SPS eigentlich machen? Wollt ihr noch Prozesse und Maschinen steuern(?) oder doch lieber die Lohnbuchhaltung darauf machen? Es ist nun mal so das jedes Problem nach der geeigneten Programmiersprache verlangt. Und der schritt zu C/Assembler wäre ein Rückschritt. Assembler sollte man den Herstellern überlassen.
    Ich meine das es sinniger wäre ein genormtes Projektformat zu erzeugen dass auf der IEC61131-3 beruht und dann von verschiedenen Entwicklungsumgebungen bearbeitet werden kann.
    Aber das ist ja alles nur Wunschdenken! Es ist nun mal so das jeder Hersteller (in Deutschland Siemens) ein berechtigtes Interesse daran hat das jeder sein Süppchen weiter alleine kocht. Es ist nun mal so dass die Inkompatibilität auch ein Vorteil ist. Wie oft kommt es denn vor das der Kunde auf ein SPS-System besteht auch wenn er dafür mehr Geld ausgeben muss? Das System das die eigenen Betriebselektriker beherrschen ist das beste System für den Kunden. Folglich verdient z.B. Siemens daran das ihr System nicht einfach austauschbar ist. //um die zurufe und was ist mit den kompatiblen Systemen wie VIPA und Co. Gleich zu beantworten. Es ist doch so wenn ein Maschinenbauer auf billige Produkte wert legt dann kauft er auch billige Produkte. Wenn man als Firma Siemens nicht in die Preisklasse einsteigen möchte verkauft man eben Lizenzen macht damit noch genug Geld und braucht sich nicht mit den Kunden zu belasten die um den Preis feilschen und dann auch noch Garantieansprüche stellen.//

    Fazit 1: Historischgewachsene Monopole und Systeme sind schwer zu kippen!

    Fazit 2: Jeder Programmierer hat einwenig Macht. Und kann das System vorschlagen das er für das bessere hält. Wenn die Argumente gut sind kann er dies vielleicht auch mal durchsetzen.

    Gruß
    ZoToS

  7. #7
    Registriert seit
    18.06.2003
    Beiträge
    49
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hi

    Also ich bin einer von den schlecht ausgebildeten.
    Leider bin ich selbst kein "gelernter Informatiker" und wenn ich die Jungs an den Anlagen sehe bin ich auch oft froh das es so ist.

    Mir persönlich gefällt die IEC1131-3 nicht ganz so gut. Wir setzen Sie zwar bei AEG und S7 200 -Steuerungen ein aber ist nicht 100% mein Fall.

    Von allen "Sprachen" wenn man Sie so nennen darf gefällt mir AWL eigentlich am besten aber beim Beobachten im Status haben FUP und KOP doch einige Vorteile.

    Viele Kunden wünschen sich auch ein Programm in KOP oder FUP so das wir in den letzten Jahren immer mehr in KOP oder FUP die Programme schreiben. Das KOP und FUP etwas mehr Speicher braucht weiß ich auch.
    Unsere eigenen Funktionsbausteine schreiben wir nur in AWL oder SCL.

    Ich glaube das die gut ausgebildeten Informatiker auch nur C, C++, Pascal,VB,COBOL usw. wählen weil in Ihrem Studium der Schwerpunkt auf diesen Sprachen liegt und keiner gerne was neues lernt und manchmal liegt es auch daran das sich die Informatiker vielleicht für was besonderes halten.


    netten Gruß

    Christian

  8. #8
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Asl erstes mal: Ich wollte den Assembler als Basis-Tool. Dann kann man den Codegenerator eines beliebigen Compilers veranlassen, passende Assembler-Code zu generieren. In der Praxis nur GCC oder SDCC, da man deren Codegeneratoren selbst verändern kann.

    Zitat Zitat von xZoToSx
    Das mit dem Assembler hört sich zwar gut an ist aber nicht so. Das würde nie ein wirklich gutes System ergeben wenn Du versuchst eine Maschine in Assembler zu Programmieren.
    De facto hat AWL sehr viel Ähnlichkeit mit Assembler. Ich stelle hier mal S7 code und 8051-Assembler nebeneinander. 8051 bietet sich an, da er Befehler zur direkten Bit-Manipulation hat. Manche Mnemonics mögen falsch sein, ist schon etwas her:
    Code:
    S7			S7-200		8051
    U E3.4 	 	LD I3.4		MOV C,P3.4
    O M2.6		O M2.6		ORL  C,2.6
    S M3.4		S m3.4,1		JNC	M1:			*
    								SET	3.4
    								M1&#58; <folgeanweisung>	
    L MB 17		LD MB7				 MOV 17,A
    L 15							
    +I			+I,15,MB7	ADD A,15
    T MB17					MOV A,17
    Schreibe jetzt nicht mehr, weil es ätzend ist, dass einigermaßen in Spalten zu schreiben...
    Die Sprunganweisung über den set-Befehl zusammen mit der folgenden Marke kann man in ein Makro packen, dann siehts noch gleicher aus.
    Selbst C ist sehr unkomfortabel für aufgaben die nach dem Prinzip der Echtzeitfähigkeit laufen sollen. Man verfängt sich sehr schnell in einer schleife oder spricht eine falsche Hardwareadresse an.
    Bei Schleifen ist die Hauptgefahr, dass sie halt mit mehr oder weniger Durchläufen wechselnde Laufzeiten benötigen. Du hast aber auch in Step7 Schleifenbefehle...
    Bei Assembler mit den ganzen JMP (Jump&s/Goto&s) würdest Du wahnsinnig werden.
    Ist das mit Marken bei Step7 anders? Ok, du kansst nur im selben Block springen.
    Dazu kommt noch das Betriebssystem der Hersteller, jeder Hersteller hat da doch ein OS auf der Kiste laufen um die Hardware anzusprechen und übergeordnete Funktionen wie Schnittstellen-Protokolle, Watchdogs, Diagnosetools, etc. zu realisieren.
    Da must du die Dokumentation der Schnittstelle und der Funktionalität haben. Ist mit den SFBs/SFCs genau das gleiche.
    Das ist mit Sicherheit auch nicht überall gleich!
    Es gibt aber doch Steuerungen die mit C Programmiert werden?! Ja, die gibt es und zwar jede menge. Aber die meisten benutzen diese Funktion als Erweiterung um Abläufe zu programmieren komplexe Berechnungen auszuführen? eben um Algorithmen abzubilden.
    Der ?Verknüpfungskram? ist dort meist immer noch in einer SPS-Funktion in AWL/FUP/KOP gelöst. Was soll euere SPS eigentlich machen? Wollt ihr noch Prozesse und Maschinen steuern(?)
    C oder andere Hochsprachen machen genau da Sinn, wo heute auch ST Sinn macht.
    Manchmal brauch man auch Mathematik und Algorithmen in der Maschinensteurung:
    Ich Habe eine Niveauregelung, wo ich von einem Gas-Ausperlrohr ein recht "verrauschtes" Signal bekomme. Neben dem absoluten Wert muss ich auswerten, ob der Spiegel steigt fällt und ob er das schnell oder langsam tut. Direkte Differenzbildung geht nicht. Ich habe auf einer 95U (10 Jahre her) zwei oder drei FIR-Filter programmiert, die mir Tiefpässe verschiedener Grenzfrequenz bilden. Damit ist die Kiste restlos ausgelastet.
    Aber das ist ja alles nur Wunschdenken! Es ist nun mal so das jeder Hersteller (in Deutschland Siemens) ein berechtigtes Interesse daran hat das jeder sein Süppchen weiter alleine kocht.
    Ja

  9. #9
    Anonymous Gast

    Standard

    @Zottel: Hallo!
    Technisch gesehen sind unsere Ansichten gar nicht weit von einander entfernt. Nur die Interpretation der Aussagen ist eine andere.
    Z.B. ich deute auf eine Gefahr hin, das bei Assembler oft mit Sprüngen gearbeitet wird und dies zu Problemen führen kann.

    Ist das mit Marken bei Step7 anders?
    Antwort: Nein, man kann sich dort auch „tot“ springen.

    Jetzt kommt das Aber: Man muss nicht so Häufigspringen wie in Assembler. Als beweis verweise ich auf Deinen „Code“ in dem Du sehr anschaulich S7-AWL, S7-200-AWL und 8051-Assembler vergleichst. In dieser simplen Anweisung benötigst Du bereits eine Sprungmarke für Assembler auch wenn diese sehr übersichtlich auf einen Blick zu überschauen ist kann das in größeren Programmen zur Verwirrung führen.

    Da must du die Dokumentation der Schnittstelle und der Funktionalität haben. Ist mit den SFBs/SFCs genau das gleiche.
    Das die Schnittstellen des SPS-OS genauso übersichtlich gehalten sind wie die der SFBs/SFCs halte ich für ein Gerücht.

    Das es sinn macht auf einer SPS eine Hochsprache wie C anzubieten habe ich nie bestritten. Aber mit ST/SCL ist es auch getan.

    Meine Meinung steht: Mit Assembler sollen sich die SPS-Hardwarehersteller rumschlagen. Für den SPS-Programmierer wäre das ein Rückschritt.

    Gruß
    ZoToS

  10. #10
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von xZoToSx
    @Zottel: Hallo!
    Jetzt kommt das Aber: Man muss nicht so Häufigspringen wie in Assembler. Als beweis verweise ich auf Deinen ?Code? in dem Du sehr anschaulich S7-AWL, S7-200-AWL und 8051-Assembler vergleichst. In dieser simplen Anweisung benötigst Du bereits eine Sprungmarke für Assembler auch wenn diese sehr übersichtlich auf einen Blick zu überschauen ist kann das in größeren Programmen zur Verwirrung führen.
    Und genau da habe ich dazugeschrieben, dass man das in ein Makro packen kann. Ausserdem benötigt man es nur auf einem 8051. Die S7 hat wahrscheinlich ein VKE-bedingtes set als einzelnen Maschinenbefehl.
    Der 8051 braucht auch Bibliotheksaufrufe für Realzahlberechnungen. Ein 80486 braucht das nicht. Eine S7 wohl auch nicht.
    An anderen Stellen agiert auch Step7 bei der Code-Erzeugung wie ein Makroassembler. Disassemblier mal den Maschinencode, der aus einem FB-Aufruf mit Parametern wird...
    Dass die Schnittstellen des SPS-OS genauso übersichtlich gehalten sind wie die der SFBs/SFCs halte ich für ein Gerücht.
    Ich halte die SFBs/SFCs nicht für den Gipfel der Übersichtlichkeit.Beispiel: Wozu überhaupt ein SFX zum Lesen der Uhrzeit? Das könnte man auch aus einem Sondermerkerbereich lesen. Gegenargument: Konsistenz der Daten über mehrere Byte-Lesebefehle. Gegengegenargument: In einem Rutsch mit dem Blockkopierbefehl kopieren. Der sollte ja auch wegen der Konsistenz beliebiger Daten ununterbrechbar sein.

    Wenn die Funktionalität eines SPS-OS nicht umfangreicher ist, sollte auch die Schnittstelle nicht größer ausfallen.
    Meine Meinung steht: Mit Assembler sollen sich die SPS-Hardwarehersteller rumschlagen. Für den SPS-Programmierer wäre das ein Rückschritt.

    Mein Beispiel sollte zeigen, dass ein AWL-Programmiere schon jetzt de facto Assembler programmiert. D.h., auf derselben niedrigen Abstraktionsebene.

    Was ich ändern möchte, ist das ein Programm namens Assembler zur Verfügung steht, was AWL-Quelltext(wie im AWL-Bausteineditor und wie im AWL-Quelleneditor), von mir aus mit absolut identischer Syntax wie Step7, in den Binärcode umsetzt.
    Als Standalone-Programm und nicht hinter dem Bausteineditor verborgen.
    Dann kann ich mein AWL-Programm in einem beliebigen Editor schreiben.
    An anderer Stelle wurde hier im Forum über irgendwelche EXCEL-Anwendungen, die irgendwelche
    Bezeichner oder Kommentare auf eine Länge von 40? bringen, diskutiert. Ein anständiger Assembler "fräße" Textdateien mit beliebig langen Bezeichnern und Kommentaren, "whitespace" als Trennzeichen. Er erwartet nicht bestimmte syntaktische Elemente an bestimmter Spaltenposition.
    Wenn ich heute Code wiederverwenden will, muss er sich entweder für einen FB/FC eignen, oder ich muss ihn manuell per copy/paste übertragen. Da würde ein #include helfen.
    Und dann gibt es nebenbei, als Abfallprodukt, die Möglichkeit Codegeneratoren für Hochsprachen zu schreiben, egal wie sinnvoll das ist, aber es gäbe sie.
    Es gibt auch andere Gründe, AWL automatisch generieren zu wollen:
    Auf der S5 hatte ich öfter das Problem, Analogwerte skalieren zu müssen mit den MUL und DIV FBs. Dabei darf man keine Überläufe bei den Ganzzahlen erzeugen. Andererseits möchte man keine Genauigkeit verschenken. Man kan mit Schiebebefehlen die Eingangsvariablen der Rechnung anpassen. Das ist aber fehlerträchtig. Genau das ließe sich mit einem Programm automatisieren und auf Korrektheit testen.

Ähnliche Themen

  1. Welche Programmiersprache ?
    Von Kerry im Forum Stammtisch
    Antworten: 1
    Letzter Beitrag: 26.08.2010, 21:03
  2. Welche Programmiersprache lernen und wie?
    Von Rifel im Forum CODESYS und IEC61131
    Antworten: 9
    Letzter Beitrag: 30.10.2009, 15:25
  3. Programmiersprache AWL S5/S7
    Von Hippede im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 19.06.2009, 14:54
  4. Antworten: 13
    Letzter Beitrag: 03.04.2009, 09:19
  5. Welche Programmiersprache für Automatisierer?
    Von Ticker im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 16.08.2005, 09:08

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •