# Java als SPS Programmiersprache



## EdgarRR

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


----------



## Zottel

EdgarRR schrieb:
			
		

> 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


----------



## Anonymous

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


----------



## plc_tippser

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 :lol: kommentar geschrieben. Leg den mal einem Nichtinformatiker vor.

Gruß pt


----------



## Zottel

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.


----------



## Anonymous

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


----------



## EWS

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


----------



## Zottel

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.



			
				xZoToSx schrieb:
			
		

> 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: <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


----------



## Anonymous

@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


----------



## Zottel

xZoToSx schrieb:
			
		

> @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.


----------



## Anonymous

*Sprachen*

Na wenn ihr sonst keine Probleme habt dann is ja gut. Wer genug zu tun hat der kommt erst gar nich auf die Idee sich über sowas Gedanken zu machen. IEC hin und her. Ne einheitliche Software mag Vorteile haben, aber reizt die jeweilige Steuerung nicht aus. Und wer denkt, dass Siemens alles offenlegt der hat auch noch die Illusion vom Weihnachtsmann. Nicht irgendwelche Vorschriften zählen, sondern wer das Monopol hat. Es gibt paar grosse Siemens, AB usw. Dann gibts paar bedeutungslose Trittbrettfahrer wie V..A und H.......z die wahrscheinlich mal ne Putzfrau von Siemens bestochen haben paar Unterlagen zu beschaffen. Guckt doch Microsoft an. Denkt ihr die lassen sich Vorschriften machen wie die Programme auszusehen haben? darüber machen sich nun wirklich nur gefrustete Informatiker ne Waffel, n SPS-Anwender garantiert nicht. Aber brütet ruhig weiter. Is besser als wenn ihr Würmer schreibt. Ihr ändert daran nichts. Und wenn jemand denkt dass er was allgemeingültiges schreiben kann was für alle SPSen gilt geht erbärmlich baden. Welcher Hersteller gibt schon mehr Infos als er muss?

In diesem Sinne...


----------



## Zottel

*Re: Sprachen*



			
				Hubert2 schrieb:
			
		

> Na wenn ihr sonst keine Probleme habt dann is ja gut.
> Wer genug zu tun hat der kommt erst gar nich auf die Idee sich über sowas Gedanken zu machen.


Genug zu tun, mit den Editoren zu kämpfen, Trivialitäten von Hand in AWL zu kodieren,AB nach Siemens und zurück zu portieren?


> IEC hin und her. Ne einheitliche Software mag Vorteile haben, aber reizt die jeweilige Steuerung nicht aus.


Das ist bei Prozessoren und C (der nicht besten aber auf den meiste Plattformen verbreiteten Sprache) ähnlich, daher hat mancher C-Compiler Erweiterungen, sei es für MMX,3D-now usw. im PC-Bereich oder Keil C51 für die Bitbefehle des 8051.


> Und wer denkt, dass Siemens alles offenlegt der hat auch noch die Illusion vom Weihnachtsmann. Nicht irgendwelche Vorschriften zählen, sondern wer das Monopol hat.


Das weiss ich besser als viele andere. 

[url]http://libnodave.sourceforge.net
[/url] 
Ist eine Bibliothek zur Kommunikation mit Siemens-Steuerungen. War Arbeit, das aus der mitprotokollierten Kommunikation nachzubilden.


> Es gibt paar grosse Siemens, AB usw. Dann gibts paar bedeutungslose Trittbrettfahrer wie V..A und H.......z die wahrscheinlich mal ne Putzfrau von Siemens bestochen haben paar Unterlagen zu beschaffen. Guckt doch Microsoft an. Denkt ihr die lassen sich Vorschriften machen wie die Programme auszusehen haben? darüber machen sich nun wirklich nur gefrustete Informatiker ne Waffel, n SPS-Anwender garantiert nicht.


Sowenig wie viele Winzigweich-Anwender


> [/url]


----------



## zotos

http://www.heise.de/newsticker/meldung/48795


----------



## Zottel

Interessant, nur braucht es halt einen recht grossen Rechner um mit 22ms Reaktionszeit eine Aufgabe zu erledigen, die ein 8051 mit <1k Assemblercode auch bewäligt.


----------



## drfunfrock

EdgarRR schrieb:
			
		

> Hallo,
> 
> ich möchte hier die Diskussion über die SPS / PLC Programmiersprachen anstossen. Mich würde intressieren wie ihr die Programmiersprachen im vergleich seht.



Ich finde JAVA derzeit nicht passend, weil diese Sprache von einem Branchenfremden kommt und in ihrem Kern nicht offen ist. Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht. Da werden implizite Automaten mit über 20 Zuständen mit vielen Merkern programmiert und das ganze noch als Leiterdiagramm. Selbstverständlich nicht aus einem Guss, sondern historisch entwickelt, so dass selbst dem langjährigen Kollegen die Puste ausgeht. 

Daraufhin began ich ein Experiment mit der Sprache ST. Ich erstellte wie in der VHDL-Programmierung einen einfachen Moore-Automaten (siehe http://tinyurl.com/68bxv) und erzielte sofort einen Erfolg.  Es hat sich herausgestellt, dass ST einfachste Objektorientierung möglich macht, aber nicht sonderlich gut unterstützt. Wenn man ST noch eine einfache Objektorientierung verpassen würde, könnte man sehr zufrieden sein. Uns hat jedenfalls die Möglichkeit der einfachsten Objektorientierung sehr geholfen. Wir haben dabei den Code, der innerhalb von 3 Jahren "gewachsen" ist, innerhalb von 3 Wochen ersetzt. Ich hätte mir aber gewünscht, dass ganze sauberer zu programmieren, so dass ein Teil der Doku unnötig geworden wäre.

Gerade wenn viele, auch selbstständig einsetzbare Einheiten , zusammenarbeiten sollen, ist Objektorientierung ein bequemer und fast selbstdokumentierender Weg. Es geht als nicht so sehr um den Namen der Programmiersprache, sondern um deren Eigenschaften und da meine ich, sollte über Objektorientierung nachgedacht werden. AWL ist IMHO inakzeptabel, weil diese Sprache in keiner Weise Problem beschreibend ist.

Ach ja: Performance hat es nicht gekostet, aber jede Menge eingesparten Code.

Doc Funfrock


----------



## Zottel

drfunfrock schrieb:
			
		

> Ich finde JAVA derzeit nicht passend, weil diese Sprache von einem Branchenfremden kommt


Das kann nicht der Punkt sein. Typische Betriebsblinde würden wach werden müssen, wenn ein Auswärtiger was besseres bringt.


> ...und in ihrem Kern nicht offen ist.


Was ist der Kern? Die Sprachdefinition? Da ist JAVA meines Wissens offen. Für AWL x-beliebiger Hersteller existieren im allgemeinen nicht einmal formale Definitionen.


> Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht. Da werden implizite Automaten mit über 20 Zuständen mit vielen Merkern programmiert und das ganze noch als Leiterdiagramm. Selbstverständlich nicht aus einem Guss, sondern historisch entwickelt, so dass selbst dem langjährigen Kollegen die Puste ausgeht.


Möglicheweise dann, wenn er fremde Programme nachvollziehen muß. Das ist aber in einer OO-Sprache nicht eo ipso (automatisch) besser


> Daraufhin began ich ein Experiment mit der Sprache ST. Ich erstellte wie in der VHDL-Programmierung einen einfachen Moore-Automaten (siehe http://tinyurl.com/68bxv) und erzielte sofort einen Erfolg.


Wie mißt du den Erfolg? Ich messe ihn mal daran, daß das Steuerprogram richtig auf Eingaben des Bedienes und Ereignisse der äußeren Welt (Prozeß) reagiert.
Ein AWL- oder Assembler-Programm (oder beliebig programmiertes Programm zur Steuerung von Maschinen) ist ok, wenn es das tut. In der OO teilst du dies in zwei Schritte auf:
Dein Programm bildet dein Objektmodell richtig ab und du nennst dein Programm sei korrekt.
Zwischen der Wirklichkeit und dem Programm steht nun die Modellierung als Objekt. Wenn dein Programm nicht funktioniert, mußt du das Objektmodells infrage stellen.
In einem Zyklus von Testen und Korrigieren hast du jetzt auch zwei Schritte.


----------



## Ralf

Guten morgen,

ich kann nicht umhin davor zu warnen jedem Trend hinterherzulaufen. Wenn man versucht Erkenntnisse aus der schnellebige IT Welt auf die doch eher konstante der Automatisierungstechnik zu beziehen - wir sind ja schließlich in einem Automatisierungstechnikforum - sollte man sich (dies mag jetzt bissig klingen) nicht auf nur eine Teilsicht beschränken.
Die IT hat eine rasante Entwicklung hinter sich. Zu der Zeit als die ersten PCs auf den Markt gebracht wurden, gab es ja schon leistungsfähige Kleinrechner; Digital Equipment (Hi PLC_T) hat zu dieser Zeit als Reaktion auf den IBM PC mal schnell deren ‚Clusterrechner’ PDP 11 mit ´nem bißchen Userinterface zusammengedengelt und ihn als RAINBOW oder PROFESSIONAL verkauft, die Dinger waren um einiges Leistungsfähiger als der PC, aber auch für das private rumspielen unerschwinglich. 
Im IT Massenmarkt wurden folglich der PC als Leistungsschwaches Gerät angeboten, der Sektor, der Rechenleistung benötigte, bediente sich mit professionellen Geräten (selbstverständlich für teuer Geld).
Die professionellen Geräte – auch der Nachfolger der PDP (die gute alte VAX) wurden – zumindest wenn es um technische Problemstellungen in FORTRAN programmiert, bei eher Daten- als Rechenintensiven Anwendungen war glaube ich ALGOL on the top. Betriebssysteme die im Profibereich zum Einsatz kamen, waren UNIX und für die DEC Rechner VMS. 
Im ‚Amateurbereich’ - der ja nun erst mal zum Profibereich werden mußte – wurde das getan was jeder Amateur macht, es wurde mächtig gepfuscht. Ein unbedeutender EDV – Händler aus Seattle, dessen größter verdienst wohl immer noch die Erfindung der ‚unhandled exception’ ist, kaufte das Betriebssystem DOS und verschacherte teure Lizenzen (das war nicht ungeschickt / ich hätte auch gerne ganz viel Geld). Die Anforderungen der Kunden verschoben sich – EDV, jetzt ja für jeden erschwinglich, mußte auch für jeden bedienbar werden – zu ebendieser Zeit kam meine damalige Freundin mit ´nem Mac nach Hause. Microsoft sah Handlungsbedarf, es wurde auf das antiquierte DOS – Gerüst ein schönes buntes Windows Haus aufgesetzt, diesem Konstruktionsprinzip blieb Microsoft bis Win ME treu; jeder kann sich bildlich vorstellen, daß ein Haus maximal soviel taugt wie sein Fundament, das Haus war aber
A – Ein virtuelles Haus, bei dem ein Einsturz nicht wehtut
B – Ohnehin nur das Haus für die Amateure, die Profis blieben ja beim bewährten
Erst als die Profiwelt sah, daß es in der Amateurwelt leistungsfähige Rechner für kleines Geld gab, wollte Microsoft auch den Profisektor bedienen, den Profis konnte man jedoch nicht die alte DOS Bretterbude andrehen. Microsoft tat was es immer getan hat und ging Einkaufen. DEC hingegen – ziemlich klamm – entwickelte ein neues Betriebssystem. Heraus kam Windows NT, von DEC halbfertig erworben von Microsoft zuerst angekündigt, dann noch mal verschoben und angekündigt, dann ... verschoben ... angekündigt (irgendwie hieß das Betriebssystem zu diesem Zeitpunkt Windows NOT THERE) und endlich lang erwartet unausgereift wie es war auf dem Markt geworfen. 
Diese gesamten Beschriebenen Betriebssysteme sind auf Objektorientiertheit zugeschnitten. (Für alle die bis hierhin gelesen habe – das war das Thema.) Der Hauptsinn der Objektorientiertheit bestand darin, Strukturen die schon vorhanden sind (Klassen) zu verwenden, also eine Schalfläche nicht neu zu programmieren sondern aus der Klasse Schaltfläche eine spezifische Schalfläche oder abermals eine Klasse der OK / abbrechen Schaltfläche zu machen. Den Betriebssystemen entstand hieraus ein riesiger Arbeitsspeicherverwaltungsaufwand, sie hatten es nicht mehr mit Programmierern zu tun, die direkt auf Speicher oder auch auf Schnittstellen zugriffen, sondern mußten diese Aufgaben selbst erledigen. Durch diesen Kunstgriff hatte man Computer gebaut, die nicht mehr nur mit einer Aufgabe befaßt sind, Computer wurden erst durch die Objektorientiertheit universeller - ! UND INSTABIELER !
Rechenintensive Anwendungen, kritische Finanzprozesse oder auch Automatisierungsprozesse müssen aber eins nicht sein: Universell, stabil hingegen wäre gelegentlich nicht schlecht. Fürs Universelle gibt’s ja in der Automatisierung noch den Visualisierungsrechner im Leitstand oder das CE Panel in der Schranktür, für den Fall, daß diese Geräte ausfallen schafft man sich Notbedienmöglichkeiten und kann auch Auftraggebern plausibel machen, daß dies nun fehleranfällige IT und nicht Automatisierungstechnik ist. Wer seine Anlagensteuerung auf fehleranfällige Speicherzuweisungen durch Objektorientiertheit aufsetzt, kann größere Schäden hierdurch nicht einfach begründen, sondern braucht ein Ticket für ‚den Zug nach Nirgendwo’ – da finden sie einen nicht.

Gruß

Ralf


----------



## Ralle

@Ralf 

Guter Aufsatz von meinem Namensvetter !!!  :shock: 

Ralf hat Recht, es ist ja nicht so, daß im Bereich der Automatisierungstechnik keine Innovationsfreudigkeit herrscht. Man kann dem Markt nur Stabilität wünschen (technische natürlich), nur so können stabile SPS-Systeme betrieben werden. Inzwischen stürzt mein W2K-Rechner höchst selten ab (warum????), aber trotzdem, eine SPS ist mit persönlich in 10 Jahren erst einmal gestorben. Objektorientiert ist ja schön und gut, aber wenn ich so meinen Programmierstil (Delphi) betrachte, dann würde ich nicht wagen, mit einem meiner Programme eine kritische (Sicherheit und Kosten) Maschine zu steuern, daß überlaß ich lieber einer guten alten SPS.

rk


----------



## Zottel

Ralle schrieb:
			
		

> Objektorientiert ist ja schön und gut, aber wenn ich so meinen Programmierstil (Delphi) betrachte, dann würde ich nicht wagen, mit einem meiner Programme eine kritische (Sicherheit und Kosten) Maschine zu steuern, daß überlaß ich lieber einer guten alten SPS.


Wenn man in der SPS "Zeiger" =berechnete Adressen, B MW x in der S5, alle Aren indirekter Adressierung in der S7 benutzt, kann man auch typische Probleme von Pascal und C bekommen: Zeiger, die auf nicht existierenden oder anderweitig genutzten Speicher verweisen und Überläufe der Ziel-Speicherbereiche.

Bei ganz "einfachen" Problemen, die überwiegend Boole´sche Logik bearbeiten, habe ich schon haarsträubende Progamme gesehen, vor allem bei Schrittketten. Erst neulich habe ich in eine Steuerung hineingeguckt, bei der zwei Teilschrittketten das Hoch- und Herunterfahren steuern. Bei ungünstigem Zusammentreffen "Ein-Taster noch gedrückt" und "gewisse Störung tritt auf" ist sie nach der Benennung der Merker gleichzeitig "ein" und "aus" !
Der Kummer gewohnte Bediener kommt da nur durch Not-Aus raus und muß von vorne Einrichten.


----------



## zotos

Ich bin kein Fan von der Idee Java in einer SPS einzusetzen. Ich muss aber drfunfrock recht geben das es zeit ist Objekt orientierte Programmierung in der Automatisierung zu verbreiten. Das die Automatisierungstechnik größten teils noch tief in den Achtzigern steckt erlebe ich auch tag täglich. Das ist aber größtenteils legitim. Es wird ja auch selten ein Projekt wirklich neu geschrieben. Die meisten Programmierer arbeiten wohl nach dem Patchwork Prinzip, Copy -> Past. Und dann behaupten sie noch das wäre eine Art Bibliothek. Die Schuld für die rückständliche Programmierweise Tragen wohl die Hersteller der SPS-Systeme. Das AWL so was von out ist werden einige Kollegen nicht akzeptieren wollen aber was ist an AWL besser im vergleich zu ST (für Siemens SCL)? Dass Sprünge aller GOTO super schlecht für die Übersichtlichkeit und Fehlersicherheit sind ist seit 1968 genügend Diskutiert worden


> Dijkstra (1968) einen Artikel in den Communications of the ACM, der den Anfang moderner Software-Entwicklung markierte. Statt wilder Sprünge durch GOTO-Befehle sollten WHILE, DO oder UNTIL den Programmfluss strukturieren


Ein weiteres Problem sehe ich in der gerade durch Siemens unterstützen Merker und Datenbaustein Philosophie. Ich verstehe nicht warum das sich immer noch hält die Speicheraufteilung sollte Aufgabe des Betriebssystems sein. Das ich als Benutzer mit Merkerwortadressen arbeiten muss ist schlicht eine Aufforderung unsaubere Programmierung zu betreiben und Überschneidungen zu provozieren. Das sollte wie in jeder Hochsprache nur über Variablen laufen.
Aber ich verschwende hier nur Zeit und Energie. Das der Weg in der Automatisierung weiter in Richtung Hochsprache und Objekt Orientierung geht ist leicht ersichtlich, der Strukturierte Text ist ein beweis dafür. 
Es ist aber ebenso klar das FUP (zur Not auch AWL und KOP) für einfache Logische Verknüpfungen unersetzlich und unschlagbar ist. Speziallösungen wie grafische Schrittketten a la Graph7 sind natürlich auch sehr berechtigte Ansätze und werden wohl noch zunehmen ich denke da an Datenflussmodelle a la LabView.
Man kann da aber nicht nach einem klaren Schnitt rufen. Ein sehr großer Prozentsatz der Automatisierungslösungen basiert auf AWL und daher muss man sich damit abfinden die Philosophie die dahinter steckt als Praxistauglich zu bewerten und nicht zu verurteilen.

Ich möchte hier keine Anfeindungen es ging mir nur darum die Richtung zu zeigen in die sich, meiner Meinung nach,  die Automatisierungstechnik entwickelt.


----------



## Heinz

@zotos
Siemens geht den Weg in Richtung objektorientierte Programmierung.
Durch die Zugriffe auf die Daten der Multiinstanzen und durch die Multiinstanzen überhaupt entwickelt sich langsam eine objektorientierter Ansatz. Weiterhin wurde der Ansatz durch das CFC Zusatzpaket weiterentwickelt.  Es ist natürlich so, dass vieles noch fehlt insbesondere die Ereignisse und Methoden. 

Andere Programmiersprachen wie Steeble Chase sind dort schon weiter. 

Ansonsten denke ich auch, dass die "alten" Sprachen wie AWL aussterben werden

Gruß Heinz


----------



## Ralle

Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten. Sicher, ein Schlumi-Programmierer kann jede gute Programmiersprache versauen.
In der normalen Maschinensteuerung ist doch die Problemstellung(hier kraß vereifacht) folgende:

500 Eingänge, 200 Ausgänge --> Automatischer Ablauf in Abhängigkeit der Eingänge und von ein paar internen Vorgaben (auch nichts anderes als Eingänge). 

Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind. Übersicht oder gar Einblick in die Abläufe geht da völlig verloren.

Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten. Die Gefahr dabei, soetwas könnte gute Programmierer "fast!!!!!" überflüssig machen (Script-Kiddis reichen  :lol: )

rk


----------



## Ralf

Nunja, vereinfacht gesagt, Java: 
Wenn der Maus - Listener sich aufgehängt hat schließe ich das Programm und mach es wieder auf.
Wenn der Hydraulikstempel listener sich in der Automatisierung aufgehängt hat mach ich ein Dummes Gesicht und geh laufen ...

Gruß

Ralf


----------



## Zottel

Die Multiinstanzen gehen insofern Richtuung OO, als sie Daten und Methoden zu deren Bearbeitung zusammenfassen.
Was nicht geht, ist Verebung und überladen:
"Pumpe C läuft wie Pumpe A und B, aber mit anderer Hyterese"
Hier bleibt nur:
1. Dem FB einen extra Parameter zu geben, der bei A und B konstant ist. 
2. Den FB kopieren, umbenennen und die Hysterese ändern. 

1. führt auf Dauer zu Bibliotheks-FBs, die im konkreten Anwendungsfall mehr überflüssige als benutzte Parameter haben.
2. führt zu einem Haufen spezialisierter Bausteine.

OO macht das nicht automatisch besser: Entweder sind analog zu 1 schon Methoden für alles und jedes drin oder man leitet ständig neue Objekte ab.
Mehrfachverebung sollte es richten, aber schaut euch mal C++ mit Mehrfachvererbung an!

JAVAs Ansatz, verschiedenens Verhalten an Klassen zu deligieren finde ich da überschaubarer. Es führt aber dazu, daß man im Nachhinein bestehende Objekte zerlegt und die Funktionalität auslagert. Ich habe noch keine gute Methode kennengelernt, um beim ersten Entwurf eines Objekts gleich alles "richtig" zu machen.


> Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten.


Die Wartung hätte natürlich auf der Ebene der Beschreibung zu erfolgen. Man nimmt ja auch nicht den C-Compiler her, um nachher das Ergebnis auf Assemblerebene zu ändern. Aber wie es Assembler-Unterprogramme in Hochsprachenprogrammen gibt (oder native Code, der von JAVA aufgerufen wird), wird es wieder AWL geben, um Probleme zu lösen, die man in der Beschreibungssprache nicht ausdrücken kann oder bei denen es auf maximale Effizienz ankommt.
[/quote]


----------



## Ralf

Guten... diesmal abend

Ich ergänze hier meinen Beitrag von heute morgen. Ich habe dort einiges Allgemeines erzählt, ohne meine ‚gemeinte’ Kernaussage auch nur ansatzweise zum Ausdruck zu bringen.

(kann Markus das ganze Topic nicht in den Stammtisch verschieben, das wäre wahrscheinlich eher  was für ´ne Diskussion mit Wein, Bier, Zigaretten und ‚nem Dicken Kopf am nächsten Morgen)

Jemand der meint Objektorientiertheit sei die allseligmachende Eigenschaft einer guten Programmiersprache, befindet sich auf dem Holzweg. Objektorientiertheit ist gut, wenn man Probleme zu lösen hat, die 
-	gut zu modellieren sind
-	häufig in abgewandelter Form zu finden sind
Die meisten derjenigen, die SPSen programmieren arbeiten im Anlagenbau. Sie finden keine geeigneten Modelle  für die auftretenden Probleme (es sei denn man hat da eine Reglung, da ist ja PID ein geeignetes Modell. Sie haben es nicht mit Problemen zu tun, die häufig in abgewandelter  Form bestehen. Entweder gibt es eine Funktion zigmal auf gleiche Art gelöst werden muß, oder Funktionen sind so unterschiedlich, daß sie mit verschiedenen (Unter)Programmen gelöst werden müssen. 

Ähnlich geht es den IT – Leuten, aber mit geänderten Vorzeichen. Der große Anteil der IT – Anwendungen, die der ‚Normaluser’ so sieht, beruht auf Modellen / die Benutzerschnittstelle ist ja nur ein einziges Modell. Auch sind in der IT vielfach Probleme zu lösen, die auf dem selben Rechner in leicht abgewandelter Form an vielen Stellen zu lösen sind (z.B. Rufe den Datei öffnen Dialog auf, und öffne die gewählte Datei). Hier macht Objektorientiertheit Sinn. 

Wenn die IT aber mit Problemen konfrontiert ist, die denen des Anlagenbaus vergleichbar sind (in meinem vorherigen ‚Guten morgen’ -  Beitrag ‚Profibereich’), geht sie einen anderen Weg. Im Profibereich wird viel Geld für Rechenleistung ausgegeben. Probleme die singulär auftreten werden auch singulär d.h. nicht Performance lastig und Instabilitäten fördernd gelöst. Wenn eine Bank sich einen Rechner leistet, der die Bankgeschäfte abwickelt, ist nach wie vor COBOL (in meinem anderen Beitrag hatte ich ALGOL geschrieben / Ist aber COBOL) Maß aller Dinge, große Forschungsabteilungen die Großrechner benutzen, geben diesen ihre Aufgabenstellungen (‚simulier mir mal das Schwingungsverhalten einer Nockenwelle’) nach wie vor in FORTRAN. Würde hier der dringende Wunsch nach Objektorientiertheit bestehen, hätte man längst umgeschwenkt. Dies tut man nicht, da man keine Performancediebe oder noch schlimmer Rechnerstabilitätsgefährder gebrauchen kann. 

Die Lastenhefte dieser Aufgabenstellungen entsprechen am ehesten denen, die auch wir aus der Anlagenautomation kennen: Ganz wichtig ist, das Programm läuft stabil.

Gruß

Ralf


----------



## drfunfrock

Zottel schrieb:
			
		

> Möglicheweise dann, wenn er fremde Programme nachvollziehen muß. Das ist aber in einer OO-Sprache nicht eo ipso (automatisch) besser


Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.  Ich bin selbst mit Einplatinen-Z80-Platinen gross geworden und habe nicht die mindesten Skrupel gehabt, eine höhere Sprache zu wählen.

AWL und ähnliche Sprachen unterstützen die Beschreibung der Problemlösung nicht oder anders, derartige Programmiersprachen ermöglichen eine Lösung, dass ist aber schon alles. ST ist das schon ein ganzes Stück weiter.  Mit einer objektorientierten Sprache ist das i.d.R. wesentlich einfacher.  Aus einem Programmtext sollte i.d.R. das Konzept herauszuslesen sein.



> Wie mißt du den Erfolg? Ich messe ihn mal daran, daß das Steuerprogram richtig auf Eingaben des Bedienes und Ereignisse der äußeren Welt (Prozeß) reagiert.


Das allein wäre nun doch ein bischen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein. Ich wäre nie zur Programmierung einer SPS gekommen, wenn es nicht organisatorisches Chaos gegeben hätte, welches zu einem Code führte, der funktionierte, aber weder veränderbar noch selbstdokumentierend war.

Mein Erfolg war der, das Kollegen sofort mir bestätigten, dass mein Experiment nicht nur funktionierte, sondern auch für andere lesbar war.




> Zwischen der Wirklichkeit und dem Programm steht nun die Modellierung als Objekt. Wenn dein Programm nicht funktioniert, mußt du das Objektmodells infrage stellen.



So arbeite ich nicht. Erst wird ein Konzept aufgestellt, dass die wichtigsten Kriterien darstellt und zum Entwurfkriterium eines Algorithmusses macht. Hält der Algorithmus den Kriterien stand, beginne ich zu Kodieren und nicht nach dem Trial- und Error-Verfahren. Das hat den Vorteil, dass Irrwege nicht so schnell beschritten werden und Kollegen eine Chance haben sich zu beteiligen.

Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konderativ sind, obwohl das  oftmals nur eine Scheinsicherheit ist.


----------



## drfunfrock

*Auswahl von Programmiersprachen*

Ich versuche mal etwas kurz zur Auswahl von Programmiersprachen einzuwerfen:

Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein. Bsp: Die Programmierung mit Assembler kann ein Problem lösen, dass dann aber selten gut beschrieben ist. Daher sind Diagramme mit LD durchaus i.O. wenn sie die Prolemlösung angemessen darstellen.

Eine Programmiersprache sollte auch die sichere Programmierung unterstützen und nicht nur ermöglichen. Bsp. In ST ist es möglich enumerated Datentypen zu Integern durch eine Zuweisung zu konvertieren, um solche Werte auch in Case-Of Anweisungen benutzen zu können. Grundsätzlich sollten implizite Casts nicht möglich sein. Das Konzept von Pointern macht die Systeme auch nicht sehr viel zuverlässiger.

Eine Programmiersprache (und ihre Umgebung) sollte ein gute Codeorganisation unterstützen.


----------



## drfunfrock

Ralle schrieb:
			
		

> Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten.



Ich selbst  habe Step7 und die Software von Beckhoff in den Fingern gehabt und kann nur sagen, das Siemens Step7 eine Zumutung ist. Ich weiss noch nicht wie stabil Beckhoff TwinCat wirklich ist, aber zumind. ist die Programmierungebung sehr sauber und gut programmiert. Die Installation ist innerhalb von 3 Minuten abgeschlossen. Keine langwierige Registrierung diverser Komponenten....



			
				Ralle schrieb:
			
		

> Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind.



Ich denke, wenn man nicht unbedingt alle Features von C++ implementiert, ist auch das zu schaffen. Zudem sind heutige Prozessoren doch etwas leitungsfähiger. Zudem benötigt man sicherlich leicht abgewandelte Konzepte. Events lassen sich durchaus über Hardware erzeugen. Eine Beschreibung einer Anlage über Objekte ist nicht in jedem Fall sinnvoll, aber sicherlich kann es einen grossen Gewinn bei verteilten Anlagen bringen.


----------



## Anonymous

*Sprache*

Aber sonst habt ihr wohl keine Probleme? Sinnlose Diskussionen! Automatisierungstechnik ist kein Feld für Hobbyprogrammierer. Macht lieber was mit "Hello World" ;-)

Bernd


----------



## Ralf

> Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.


 Ein Postulat! 
Gott sei dank hat Drfunrock keinen Brief an meinen Chef geschrieben mit der Betreffzeile 
*Wofür kriegt der eigentlich Geld, bei dem Sinnlosen Kram, den der tut*
dann wär's um mich geschehen.


> Das allein wäre nun doch ein bißchen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein


 Schon wieder ein Postulat,
Meiner Meinung zufolge muß ein Programm in erster Linie den Aufgaben entsprechen, die vom Auftraggeber respektive der Anlage an das Programm gestellt werden, erst sekundär können Eigenschaften wie Verständlichkeit und Erweiterungsfähigkeit gestellt werden. _Versuch mal einer einem Auftraggeber zu erklären, das die Programmierung zwar nicht ganz den erheblichen Performanceanforderungen entspricht, aber dafür jederzeit erweiterbar..._ spätestens hier ist man tot.


> Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konserativ sind, obwohl das oftmals nur eine Scheinsicherheit ist.


 :?:  :?:  :?: Ich versteh den Zusammenhang nicht, ich bin konservativ, aber das ist nur eine Scheinsicherheit _Kratzamkopf_ wird schon richtig sein.


> Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein.


Hier ist noch mal die (nicht nur in der Automatisierung) wichtige Prioritätenfrage zu klären.


> Grundsätzlich sollten implizite Casts nicht möglich sein.


Woher nimmst Du das? Wenn es *Zweckdienlich* ist wandle ich Dir jede REAL in INT :!:  :!:  :!:


----------



## zotos

*Es war einmal…*

Es war einmal…

Ich hatte mal einen Vorgesetzten in einem Ingenieurbüro der auch auf Programmierungen abgefahren ist wie er sie aus der S5-Welt gekannt hat. Ernannte das konventionelle  Programmierung und war glücklich damit. Wenn er ein Programm von mir gesehen hat mit FB die mehrfach aufgerufen wurden und Instanz DB´s war er sauer und richtig aus war es als ich einen Fünfzeiler SCL verwendet hatte er konnte mich nicht mehr leiden und ich ihn nicht mehr sehen. Ein Kollege hat mir nach dem ich die Firma verlassen hatte gesagt das es wohl daran lag das der Vorgesetze gemerkt hat das ihn die Technik überholt und er sich nicht etwas von einem Neuling erklären lassen wollte. Die Automatisierungstechnik hat sich in den letzten Jahren stark geändert oder lötet ihr noch 74 Reihen? Das mit dem Objektorientierten Ansatz ist schon gut gerade wenn man die Datenkapselung betrachtet und nur Methoden auf den Bereichzugreifen dürfen die das auch sollen.

 @BerndS: Mach mir einen gefallen und Sterbe doch einfach aus. :stinkefinger:  :!:   //das war nur die Retourekutsche für das doofe „Hello World“ Kommentar.

Ich bin froh das auch andere der Ansicht sein werden das AWL ausstirbt und SCL & Co. die modernen Nachfolger werden.

Der Vorteil ist ich kann auch mit AWL umgehen :!: :wink:


----------



## Ralf

Ich schrieb doch


> das wäre wahrscheinlich eher was für ´ne Diskussion mit Wein, Bier, Zigaretten und ‚nem Dicken Kopf am nächsten Morgen


.... jaja ....

Gruß

Ralf


----------



## zotos

@Ralf

guter Plan :lol:  :!:


----------



## drfunfrock

Ralf schrieb:
			
		

> Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.
> 
> 
> 
> Ein Postulat!
> Gott sei dank hat Drfunrock keinen Brief an meinen Chef geschrieben mit der Betreffzeile
> *Wofür kriegt der eigentlich Geld, bei dem Sinnlosen Kram, den der tut*
> dann wär's um mich geschehen.
Zum Vergrößern anklicken....


Es geht nicht darum die Welt zu verbessern, sondern darum darüber zu diskutieren, inwieweit man es besser machen kann.



> Meiner Meinung zufolge muß ein Programm in erster Linie den Aufgaben entsprechen, die vom Auftraggeber respektive der Anlage an das Programm gestellt werden, erst sekundär können Eigenschaften wie Verständlichkeit und Erweiterungsfähigkeit gestellt werden.


Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch und würde die Entlassung für so eine Pfuschermentalität riskieren. Es geht darum, dass eine Produktionsanlage nicht erweitert werden konnte, weil die Programmierung einfach chaotisch war. Dadurch ist uns ein Auftrag durch die Lappen gegangen. 

Wer zudem seine Arbeit nicht konzeptionell vorbereiten kann, der wird immer wieder Code produzieren, der derartige Ergebnisse bringt. 



> _Versuch mal einer einem Auftraggeber zu erklären, das die Programmierung zwar nicht ganz den erheblichen Performanceanforderungen entspricht, aber dafür jederzeit erweiterbar..._ spätestens hier ist man tot.



Das ist doch nun wirklich eine Ausrede. Gute Arbeit entspricht allen Anforderungen und dazu gehört neben dem sauberen Softwareengineering auch die Bedingungen der Anlage einzuhalten. Alles andere ist in meinen Augen Pfuscherei. Geschwindigkeit und Softwareengineering sind kein Widerspruch.


----------



## drfunfrock

*Re: Sprache*



			
				BerndS schrieb:
			
		

> Aber sonst habt ihr wohl keine Probleme? Sinnlose Diskussionen! Automatisierungstechnik ist kein Feld für Hobbyprogrammierer. Macht lieber was mit "Hello World" ;-)
> 
> Bernd



Ja, klar mit einem schönen Bier geht es besser  Es sind häufig  alteingesessene Automatisierer die mit Betonköpfen und einem Brett vor dem Kopf durch den Alltag laufen und meinen sie seien die Könige.


----------



## Ralf

> Wer zudem seine Arbeit nicht konzeptionell vorbereiten kann, der wird immer wieder Code produzieren, der derartige Ergebnisse bringt


*1. - *Wen beurteilst Du hier
*2. - *Welche Ergebnisse meinst Du

Schreib doch bitte nicht so unverständlich, eine Konzentration auf das Sachliche wäre angebracht

Gruß

Ralf


----------



## Ralf

> Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch


Aha, Du führst also nur Arbeiten zum Selbstzweck durch, hast also weder vom Endkunden, Deinem Arbeitgeber oder sonstwem einen Auftrag.

Dann mag Deine Position verständlich sein.


----------



## Ralf

@Markus
Wenn Dir dieser Beitrag irgendwie auf den Geist fällt, lösch Ihn bitte

@drfunrock
Ich kann es mir jetzt absolut nicht mehr verkneifen


> Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht.


-	drfunrock beschäftigt sich seit drei Wochen (einem gesunden Schlaf / Beschäftigungsverhältnis voraussetzend also seit max. 180 Stunden) mit SPSen
-	drfunrock weiß, wie es Anfang der 80ern zuging – vor über 20 Jahren 


> ... erzielte sofort einen Erfolg


-	drfunrock revolutionierte gewachsene Strukturen


> Erst wird ein Konzept aufgestellt, dass die wichtigsten Kriterien darstellt und zum Entwurfkriterium eines Algorithmusses macht. Hält der Algorithmus den Kriterien stand, beginne ich zu Kodieren und nicht nach dem Trial- und Error-Verfahren. Das hat den Vorteil, dass Irrwege nicht so schnell beschritten werden und Kollegen eine Chance haben sich zu beteiligen.


Aha, drfunrock bekommt mit den oben errechneten 180 Stunden Erfahrung die Gelegenheit den Arbeitsprozeß zu gestalten. Er programmiert nicht wie wir alle :?: nach dem Versuch und Irrtum Prinzip sondern stellt (vor oder während der 180 Stunden) ein schlüssiges Konzept auf, in das :!: seine Kollegen :!: einbezogen werden können.


> Ich selbst habe Step7 und die Software von Beckhoff in den Fingern gehabt und kann nur sagen, das Siemens Step7 eine Zumutung ist. Ich weiss noch nicht wie stabil Beckhoff TwinCat wirklich ist, aber zumind. ist die Programmierungebung sehr sauber und gut programmiert. Die Installation ist innerhalb von 3 Minuten abgeschlossen. Keine langwierige Registrierung diverser Komponenten....


drfunrock nutzt die in den 180 Stunden zwangläufig anfallenden Kaffeepausen sinnvoll mit dem Vergleich von Entwicklungsumgebungen 


> Es sind häufig alteingesessene Automatisierer die mit Betonköpfen und einem Brett vor dem Kopf durch den Alltag laufen und meinen sie seien die Könige.


drfunrock weiß, daß die Automatisierungswelt von Pfeifen bestimmt wird – spätestens nachdem man sich 180 Stunden mit der SPS Programmierung auseinandergesetzt hat, wird dem normalsterblichen das klar.

Ich möchte hier noch einmal meine Kernaussage aus dem letzten Beitrag unterbringen, die sich mit den aktuellen Mitteln der IT bezüglich der Objektorientiertheit auseinandersetzt


> Wenn die IT aber mit Problemen konfrontiert ist, die denen des Anlagenbaus vergleichbar sind (in meinem vorherigen ‚Guten morgen’ - Beitrag ‚Profibereich’), geht sie einen anderen Weg. Im Profibereich wird viel Geld für Rechenleistung ausgegeben. Probleme die singulär auftreten werden auch singulär d.h. nicht Performance lastig und Instabilitäten fördernd gelöst. Wenn eine Bank sich einen Rechner leistet, der die Bankgeschäfte abwickelt, ist nach wie vor COBOL (in meinem anderen Beitrag hatte ich ALGOL geschrieben / Ist aber COBOL) Maß aller Dinge, große Forschungsabteilungen die Großrechner benutzen, geben diesen ihre Aufgabenstellungen (‚simulier mir mal das Schwingungsverhalten einer Nockenwelle’) nach wie vor in FORTRAN. Würde hier der dringende Wunsch nach Objektorientiertheit bestehen, hätte man längst umgeschwenkt. Dies tut man nicht, da man keine Performancediebe oder noch schlimmer Rechnerstabilitätsgefährder gebrauchen kann.


----------



## sps-concept

*gewachsene Strukturen*

is schon genial wie schnell manche dazu mutieren die Arbeit von anderen zu werten! Nach 3 Wochen die Erfahrung von Jahren übern Haufen werfen, als Anfänger alte Strukturen ablösen.... Kein Trial & Error.. wow! Da entfällt wohl auch die Inbetriebnahme? Da lassen sich ja 50% der Kosten sparen. Man steckt vor Auslieferung die MMC und fragt dann wenn der Elektriker eingeschalten hat ob alles läuft. Natürlich läuft alles, man will nur ne Bestätigung. Also ich nehme den Beitrag hier schon lange nicht mehr ernst. Da will nur einer reizen

MfG
André Räppel


----------



## drfunfrock

Ralf schrieb:
			
		

> Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch
> 
> 
> 
> Aha, Du führst also nur Arbeiten zum Selbstzweck durch, hast also weder vom Endkunden, Deinem Arbeitgeber oder sonstwem einen Auftrag.
> 
> Dann mag Deine Position verständlich sein.
Zum Vergrößern anklicken....


Du nimmst wohl alles persönlich? Es ist ein grosser Unterschied, ob  jemand alle 2 Wochen für einen anderen Kunden arbeitet oder nur die Anlage in der Firma wartet bei der er seinen Job hat.  

Nichts für ungut, aber ich habe im meinen Leben genug Programmierer gesehen, die tausende Zeilen Kode produzierten und das ohne eine Zeile Dokumentation zu hinterlassen. Es mag ja Auftraggeber geben, die so etwas aus Unkenntnis hinnehmen oder schlicht aus Faulheit. Ich akzeptiere so etwas nicht und würde von jedem, der so ein Ergebnis abliefert  Schadensersatz fordern. Die Zeiten, in denen Programmierer - und seien es SPS-Techniker  - Narrenfreiheit hatten, sind vorbei.


----------



## drfunfrock

*Re: gewachsene Strukturen*



			
				sps-concept schrieb:
			
		

> is schon genial wie schnell manche dazu mutieren die Arbeit von anderen zu werten! Nach 3 Wochen die Erfahrung von Jahren übern Haufen werfen, als Anfänger alte Strukturen ablösen.... Kein Trial & Error.. wow!
> André Räppel



Programmieren ist keine esoterische Kunst, sondern ein Mittel ein Ziel zu erreichen und muss systematisch angewendet werden. Trial- und Error beim Programmieren sind daher IMHO im Normalfall die Handwerkszeuge von Pfuschern.


----------



## sps-concept

*haha*

jetzt reichts aber! Meinste weil du deine Schützselbsthaltung oder wars sogar ne Wendeschützschaltung innerhalb von 3 Wochen hingekriegt hast kannste uns hier alle als Pfuscher beschimpfen? Jedes Programm hat Fehler im Konzept und diese werden bei der Inbetriebnahme beseitigt. Ein voll durchdachtes Programm kann keiner bezahlen. Die Fehler merkt man am einfachsten am lebenden Objekt. Du scheinst dich wirklich auf Arbeit zu langweilen und in fremden Programmen rumzuschnüffeln. Schadenersatz ;-)  Wie das Programm auszusehen hat steht im Pflichtenheft. Wenns nicht drinsteht hat man Narrenfreiheit. Hauptsache es funktioniert. Und falls es einen Instandhalter gibt sollte er es verstehen. Nach 3 Wochen sollteste nich solche Sprüche loslassen!!!

MfG
André Räppel


----------



## drfunfrock

*Re: haha*



			
				sps-concept schrieb:
			
		

> jetzt reichts aber! Meinste weil du deine Schützselbsthaltung oder wars sogar ne Wendeschützschaltung innerhalb von 3 Wochen hingekriegt hast kannste uns hier alle als Pfuscher beschimpfen?



Wenn du dich hier angesprochen fühlst, ist das dein Problem. Ich habe nur meinen Standpunkt bzgl. der Programmierung hier geschrieben. Wenn du der Meinung bist, Müll oder eine Doktorarbeit beim Kunden abliefern zu können, dann ist dass die Sache deines Kunden. 

Ich beziehe mich eigentlich nur auf die objektorientierte Programmierung, die es in vielen Fällen leichter macht, eine Problemlösung zu bekommen. Die Dokumentation der Programme sollte für einen Betrieb eigentlich selbstverständlich sein. Wer Produktionsanlagen fährt und die SPS-Programme nicht dokumentiert hat, der ist bescheuert.

Übrigens: Selbst wenn ein Kunde nicht alles in das Pflichtenheft schreibt, so ist es ein Merkmal für einen guten Dienstleisters, wenn dieser eine Arbeit abliefert, die auch noch von anderen verstanden wird.


----------



## Anonymous

*drfunrock*

@ drfunrock
du bist eine Schande für die Automatisierungstechnik! Du hast doch noch die Eierschalen hinter den Ohren. Ich hab mir mal deine Beiträge hier durchgelesen. Du musst doch nicht ganz dicht sein! Es ist ja eine Frechheit anderen vorzuwerfen dass sie Scheisse abliefern. Wenn dein Spatzenhirn ein Programm nicht versteht heisst das nicht dass es schlecht ist. Wo hat man dich rausgelassen? Ich bin schon viele Jahre in der Branche aber so ein vorlauter Frischling wie du ist mir noch nicht untergekommen. Trägst du auf Arbeit einen Schlips?

Bernd


----------



## drfunfrock

*Re: drfunrock*



			
				BerndS schrieb:
			
		

> @ drfunrock
> du bist eine Schande für die Automatisierungstechnik!


Warum?



> Du musst doch nicht ganz dicht sein!


Warum?



> Es ist ja eine Frechheit anderen vorzuwerfen dass sie Scheisse abliefern.


Schlechte Ergebnisse rechtfertigen Kritik. Ein Programm auf einer Produktionsanlage - und auf nichts anderes bezog ich mich - das nicht dokumentiert wurde und unleserlich ist, kann man nur in den Mülleimer werfen. Und wenn dann plötzlich Behauptungen kommen, dass man in so einem Fall nicht mit Konzepten arbeiten kann, fällt das auf die Autoren zurück.



> Trägst du auf Arbeit einen Schlips?



Das ist hier im Normalfall weder üblich, noch erwünscht. Etwas, was auch für die Chetage gilt. Schlips gibt es nur für den Vertrieb, wenn Kunden aus dem Ausland auftauchen. An den meisten Tagen trage ich dieselbe Kluft, wie unsere Produktionsmitarbeiter., da diese gegen ESD imprägniert wurde.


----------



## Anonymous

*Schlips*

warum du ne Schande bist? Weil du allen alteingesessenen Programmieren einen Betonkopf andichtest. Es gab schon ordentliche Programme da wusstest du noch nicht einmal wie SPS geschrieben wird.

Für dich wäre ein Schlips angebracht. Scheinst ja deinem Chef ständig zeigen zu wollen was für ein toller Typ du bist und dass er die letzten 20 Jahre (als du wahrscheinlich noch vollautomatisiert und konzeptlos in die Windeln geschissen hast) von den Automatisierungsfirmen beschissen worden ist. Wenn man so tief in den Arsch kriecht wie du hinterlässt das einen braunen Ring am Hals. Dafür brauchst du den Schlips.

Wer gibt dir eigentlich das Recht nachdem du seit 3 Wochen weisst wie SPS geschrieben wird über andere zu urteilen die schon Jahrelang zufriedene Kunden haben? Bist du der SPS-Gott?

Bernd


----------



## Anonymous

*Programmieren*

drfunrock wenn du so gut bist dann gib uns mit Betonkopf gestraften unqualifizierten Pfuschern doch eine Kostprobe von deinen Programmierkünsten. Stell doch mal ein Stück Code hier rein. Am besten mit Adressregistern und Pointern usw. Aber nichts geklautes! So ich muss mal kurz weg.. meine Frau wartet im Bett. Ich denke mal in 5 Minuten müsste ich wieder da sein ;-) Wenn alles gut vorbereitet ist gehts schnell ;-)

Bernd


----------



## drfunfrock

*Re: Programmieren*



			
				BerndS schrieb:
			
		

> drfunrock wenn du so gut bist dann gib uns mit Betonkopf gestraften unqualifizierten Pfuschern doch eine Kostprobe von deinen Programmierkünsten. Stell doch mal ein Stück Code hier rein. Am besten mit Adressregistern und Pointern usw. Aber nichts geklautes! So ich muss mal kurz weg.. meine Frau wartet im Bett. Ich denke mal in 5 Minuten müsste ich wieder da sein ;-) Wenn alles gut vorbereitet ist gehts schnell ;-)
> 
> Bernd



Das hättest du wohl gerne, dass ich Kode, der meinem Arbeitgeber gehört in das Internet stelle. Als alter Hase, wie du vorgibst einer zu sein, müsstest du  eigentlich wissen, dass das nicht i.O. ist.


----------



## Anonymous

*Code*

wieso gehört der Code deinem Arbeitgeber? Du sollst ja auch nicht den von anderen Programmierern reinstellen. Und wer sollte einem verbieten sein geistiges Eigentum reinzustellen? Ihr errichtet keine Anlagen, es wird kein Know How verschenkt.. wo solls auch herkommen? Lieber hab ich nen Betonkopf als nen Hohlkopf. Ausserdem kannste ja auch ganz unverfänglich hier etwas schreiben. Haste Angst dich zu blamieren? Die grosse Fresse haste doch auch

Bernd


----------



## drfunfrock

*Re: Schlips*



			
				BerndS schrieb:
			
		

> Wer gibt dir eigentlich das Recht nachdem du seit 3 Wochen weisst wie SPS geschrieben wird über andere zu urteilen die schon Jahrelang zufriedene Kunden haben?
> 
> Bernd



1) Warum sollte ich vor Ehrfurcht erschaudern? Nur weil da irgendwelche Techniker behaupten, sie arbeiten seit 10 Jahren mit SPS-Technik? Du weisst doch selbst, dass das kein Kriterium für ordentliche Arbeit ist?

2) Ob jemand zufriedene Kunden hat, kann ich nicht beurteilen. Das kann jeder behaupten.

Im Forum zum Schaltschrankbau - einem Gebiet von dem ich leider überhaupt keine Peilung habe - läuft die Diskussion viel konstruktiver. Es stellte jemand die Frage, in welcher Reihenfolge die Kabel angeschlossen werden sollten und da wurde nicht einfach nur mit der Erfahrung von 20 Berufsjahren geprahlt., sondern eigene Ideen präsentiert. 

Wenn mir jemand aber, auf meinen kurzen Einwurf hin, das einfach drauflos programmieren nicht das beste ist,  gleich mit seiner Berufserfahrung kommt, läuft mir die Galle über. Denn was weiss der von meiner Erfahrung? Nix. Ich gebe damit auch nicht an, sondern beklagte mich höchsten über die Unvernunft meiner Firma, sich eine Anlage ohne Doku programmieren zu lassen. Wenn diese Anlage auch noch 10% des Umsatzes bringt, sind das keine Kleinigkeiten. Denn der Programmierer ist längst woanders und nicht mehr erreichbar.


----------



## Anonymous

*Doku*

Tja vom Schaltschrankbau haste keine Ahnung. Vom Programmieren auch nicht viel mehr. Wenn du etwas drauf hättest (ausser Zahnbelag) dann hättest du schon längst mal die Software nachdokumentieren können. Aber lieber regste dich drüber auf. Wenn der Programmierer für euch nicht mehr erreichbar ist dann kann ich mir vorstellen wie die Sache abgelaufen ist. Mich rufen Kunden auch Jahre später noch an und wollen Tips für Umbauten und die damit verbundenen Änderungen. Selbst wenn der Programmierer die Firma wechselt ist er noch erreichbar. Aber wahrscheinlich will der eure Bude nicht mehr sehen

Bernd


----------



## drfunfrock

*Re: Code*



			
				BerndS schrieb:
			
		

> wieso gehört der Code deinem Arbeitgeber? Du sollst ja auch nicht den von anderen Programmierern reinstellen. Und wer sollte einem verbieten sein geistiges Eigentum reinzustellen? Ihr errichtet keine Anlagen, es wird kein Know How verschenkt.. wo solls auch herkommen? Lieber hab ich nen Betonkopf als nen Hohlkopf. Ausserdem kannste ja auch ganz unverfänglich hier etwas schreiben. Haste Angst dich zu blamieren? Die grosse Fresse haste doch auch
> 
> Bernd



Na wenn du so gut bist, erzähl doch mal wie du eine Montagelinie (basierend auf Monorailbahn von Montech www.montech.ch ) mit 50 Transportwagen und 30 automatischen Stationen, so programmierst, dass nicht nur mehr als 4 Produkte gleichzeitig gefertigt werden können, sondern jederzeit auch neue Produkte  mit anderen Prozessen gefertig werden können. So etwas ist deiner Meinung nach vielleicht eine Trivialität, aber wenn dein Arbeitgeber vom Betrieb dieser Anlage abhängig ist, dann schaust du nicht einfach zu, wenn die Fertigung eines Produktes sich um mehre Wochen verzögert, weil der Techniker mit jeder Änderung etwa 1 Woche zu kämpfen hatte. 

Es kann ja sein, dass in deinem Falle die Headhunter dich schon umwerben, um dir den nächsten Posten anzubieten. Ich bin nicht in dieser Lage und werde aufpassen - soweit ich das kann - dass der Betrieb nicht vor die Hunde geht.


----------



## drfunfrock

*Re: Doku*



			
				BerndS schrieb:
			
		

> Mich rufen Kunden auch Jahre später noch an und wollen Tips für Umbauten und die damit verbundenen Änderungen.
> Bernd



Klar, dass nennt man denn basteln. Auf solche Buden, die noch nicht einmal Geld in einen SPS-Techniker stecken wollen, damit der die Anlage erweitert, kann ich pfeifen. Das läuft denn so: Kann ich von Ihnen einen Tip haben? Aber wenn es ums zahlen geht, wird die Telefonleitung gekappt. Nein, danke. Wer vernünftig ist und es sich leisten kann, arbeitet nicht mit solchen Buden zusammen.


----------



## Anonymous

*Programm*

entweder man legt sich ne Teileverfolgung an und schreibt den Typ, Bearbeitungsfortschritt, Messwerte, io/nio-Kennungen da rein, liest aus ob die Bearbeitung in Station x erfolgen soll etc. Oder man macht das mit Identifikationssystemen ala Moby. Kostet zwar erstmal aber man weiss woran man ist. Das ist dann alles neustartsicher und vor allem manipulationssicher.Sicher musst du aufpassen dass die Firma nicht vor die Hunde geht. Woanders wirste an deinem Können gemessen bei der Einstellung und nicht an deiner Grossfresse. Ausserdem seid ihr doch selbst schuld wenn jede Änderung jemand anders macht. Weiterhin hätte man ja eine gewisse Flexibilität mitbeauftragen können. Ohne dass sowas verlangt wird wird es keiner reinprogrammieren - egal wie gut die Firma ist. Will ja alles bezahlt sein.

Was ist nun mit dem Code vom SPS-Gott drfunrock? Musste dir erst was schreiben lassen?

Bernd


----------



## Ralf

N’abend ....

@Bernd & Andre

Ich glaube, daß unsere Aufregung überflüssig ist, noch nie fiel eine Eiche um, weil sie von einem Hund bepißt wurde

@drfunrock

Einen muß ich Dir noch mitgeben ......


> da diese gegen ESD imprägniert wurde


soso .... gegen ESD imprägniert, gegen *e*lectro*s*tatic *d*evices imprägniert. Imprägnieren, tut man das nicht eher zum Schutz von *e*lectro*s*tatic *d*evices. Aber Gott sei Dank weiß ich jetzt, daß ich aller Voraussicht nach mit Dir beruflich nichts zu tun bekomme, das Elend bleibt mir erspart


@all (und mal wieder ‚in Topic’)

Objektorientiertheit hat in vielen Anwendungsgebieten viele Vorteile, birgt jedoch einen riesigen Haken, der sie für die Automatisierungstechnik unbrauchbar macht.

Objektorientierte Programmierung bedingt zwangsläufig eine dynamische Speicherverwaltung, Objekte können ja von Programm dynamisch erzeugt werden, und benötigen dann zusätzlichen Speicherplatz. In Objektorientierten Programmen ist also weder die Speichernutzung noch die Abarbeitungszeit mit vertretbarem Aufwand zu bestimmen. Das Bestimmen der Abarbeitungszeit ist in den meisten Automatisierungsanwendungen dringend erwünscht, in vielen auch ein Zwang (erst kürzlich hatte ich meine erste S7 Failsafe mit TÜV -  Abnahme, der TÜV Mensch hätte bestimmt anerkennend genickt, wenn ich auf (das irgendwo frei vom Zyklus schwebende) Objekt verwiesen hätte, von dem ich auch nicht weis, wann es endlich die Magnetventile zumacht.  

Um noch mal auf mein Beispiel IT zu kommen, wenn man derzeit einen Server bei SUN bestellt (das sind mittelschwere Rechenleistungsgranaten) besteht die Option einen FORTRAN 95 Compiler mitzubestellen. FORTRAN ist die Sprache für Rechenpower pur, ist aber nun nicht Objektorientiert. Diejenigen, die solche Maschinen kaufen, können (schätze ich jedenfalls) die Leistungsfähigkeit von einzelnen Entwicklungssystemen einschätzen, und wissen dementsprechend abzuwägen.

Da ich ohnehin ein großer Freund von Beispielen bin, möchte ich hier noch zwei weitere ausführen, die veranschaulichen, daß in kaum einem Lebensbereich die Möglichkeit besteht für alle Bedürfnisse die Universallösung zu finden.

Beispiel 1: Wer hat das bessere Auto
Nr1: Der Ferrarifahrer / Nr.2: Der Fahrer eines Mercedes S600 (selbstverständlich Vollausstattung
Beide werden (obwohl beide Autos ggf. sogar gleichteuer sind) bereitwillig behaupten, mein Auto ist besser, ist einer von beiden dumm? Oder mag es eventuell sein, daß jeder von beiden nur das für seinen Anwendungsfall bestehende Optimum an Auto hat

Beispiel 2: Wer hat die bessere Wohnung
Nr1: Berlin Mitte, Penthouse auf einem Zentral gelegenen Gebäude / Wert 1,2 Mio. €
Nr2: Potsdam, Weitläufige Villa / Wert 1,2 Mio. €
Beide werden bereitwillig behaupten, ich wohne besser, ist einer von beiden dumm? Oder mag es eventuell sein, daß jeder von beiden nur das für seinen Anwendungsfall bestehende Optimum an Wohnung hat

Ich persönlich habe mein Auto ja von der Firma, einen Kombi, und fürs gleiche Geld gibt’s beim gleichen Hersteller ein schnittiges Coupe ....

Auch bei der Software kann man nicht alles haben, Objektorientiertheit und gnadenlose Stabilität gibt’s genausowenig wie die in den Beispielen benannten Fahrdynamik und riesigen Komfort oder zentralste Lage und weitläufigen Garten in Kombination .... schade eigentlich, so spielt das Leben.


----------



## Anonymous

*Probleme?*

Sag mal hast du die Probleme schon länger? Bist du in Behandlung? Ich arbeite mit diesen Firmen gut zusammen. Die haben eine eigene Instandhaltung. Es wird keine Telefonleitung gekappt und es wird wegen der Tips auch kein Geld verlangt. Das nennt man Service am Kunden. Schon gehört? Das funktioniert aber nur wenn das Verhältnis zwischeneinander klappt. Wenn mir aber bei der Inbetriebnahme son Blindfisch wie du gute Ratschläge geben wollte und alles bemängelt den würde ich mir schon vom Hals halten und dumm sterben lassen. Beauftragt ihr wegen jeder kleinen Änderung ne Firma? Vielleicht weil ne Lampe anders blinken soll. Kann 3 Gründe haben.

ihr seid stinkend faul

ihr habt keine Ahnung

ihr wollt euch auf Kosten anderer die Software bereinigen lassen

Bernd


----------



## drfunfrock

*Re: Programm*



			
				BerndS schrieb:
			
		

> entweder man legt sich ne Teileverfolgung an und schreibt den Typ, Bearbeitungsfortschritt, Messwerte, io/nio-Kennungen da rein, liest aus ob die Bearbeitung in Station x erfolgen soll etc. Oder man macht das mit Identifikationssystemen ala Moby. Kostet zwar erstmal aber man weiss woran man ist. Das ist dann alles neustartsicher und vor allem manipulationssicher.
> Bernd



Da kommt man sich doch näher: 

Die Anlage hat weder einen Neustart vertragen, noch war sie manipulationssicher.  Bei einem Fehler der Anlage mussten jedesmal alle Wagen neu aufgesetzt werden. Solche Probleme enstehen einfach, wenn eine Firma und die Anlage über Jahre wachsen. Anders als in D, sind hier Dienstleister nicht so gefragt, jedenfalls hatten die einen Techniker damals eingestellt und keiner war in der Lage die Arbeitsergebnisse einzuschätzen.

Und gerade in der Anfangszeit wird da gerne und viel gebastelt.  Deswegen werde ich bestimmt nicht gleich kündigen, aber sicherlich es besser machen wollen. Nun läuft die Sache so weit, dass alle grundlegenden Kriterien erfüllt sind.  Interessant wäre es zu erfahren, in wieweit meine Programmkonstruktion in ST eigentlich allg. Qualitätsanforderungen entspricht. Ich habe eigentlich nichts weiter getan als Moore-Automaten aus der VHDL-Programmierung in ST übertragen. Da wir fast nur Sequenzen in der Programmierung haben, hätte man zwar auch auf die Diagrammform zurückgreifen können, aber in der Eile habe ich da auf Bekanntes zurückgegriffen.  Die Wagen werden zur Zeit noch über Barcodes in der Eingangsstation identifiziert, um dann von Station zu Station weitergereicht zu werden. Die Steuerung der Produktion für ein konretes Produkt läuft über Prozesslisten. Also habe ich so ziemlich das gemacht, was du in deinem Beitrag angedeutet hast. 

Nur meine Aufgabe war immer noch relativ leicht. Ich hatte es weder mit Antrieben, noch mit regelungstechnischen Aufgaben zu tun.


----------



## Ralf

Hat denn hier niemend mehr etwas

*ON TOPIC*

 :?:    :?:    :?:    :?:    :?:    :?:    :?:    :?:


----------



## drfunfrock

Ralf schrieb:
			
		

> N’abend ....
> Einen muß ich Dir noch mitgeben ......
> 
> 
> 
> da diese gegen ESD imprägniert wurde
> 
> 
> 
> soso .... gegen ESD imprägniert, gegen *e*lectro*s*tatic *d*evices imprägniert.
Zum Vergrößern anklicken....


<Klugscheissmodus>
  ESD = Electro Static Discharge 
  nachzusehen bei http://de.wikipedia.org/wiki/ESD
</Klugscheissmodus>



> Objektorientiertheit hat in vielen Anwendungsgebieten viele Vorteile, birgt jedoch einen riesigen Haken, der sie für die Automatisierungstechnik unbrauchbar macht.
> 
> Objektorientierte Programmierung bedingt zwangsläufig eine dynamische Speicherverwaltung, Objekte können ja von Programm dynamisch erzeugt werden, und benötigen dann zusätzlichen Speicherplatz.



Man kann es so implementieren, muss es aber nicht. Das Leben kann auch aus Kompromissen bestehen, wie auch objektorientiert Sprachen es machen. Einer der härtesten Fälle ist sicherlich C++, während Perl sich mit ganz einfachen Konstrukten zufriedengibt. So könnte man es auch in der Auotmatisierungstechnik halten: Dynamische Speicherverwaltung streichen oder einschränken,  Vererbung einschränken, Polymorphismus einschränken...  Im Prinzip würde es schon helfen, wenn man einfache statische Objekte mit Methoden ohne Vererbung hätte.  Dann wäre auch die Abarbeitungszeit wieder deterministisch. Nicht einmal eine einfache Vererbung würde dem entgegenstehen. Oder ?

[/url]


----------



## Ralf

<Klugscheissmodus an>
Da magst Du Recht haben, ich hatte jetzt meine Info von einer Seite eines Herstellers, die ESD Schutzkleidung produziert. Die ist allerdings auch wenn Deine Information richtig ist nicht gegen discharge impregniert, sondern wird (bevor man die devices berührt) :lol: discharged
<Klugscheissmodus aus>
_Ibi tacuisse_

Ich freue mich zwischen den Zeilen zu erkennen, daß Du endlich mal Deine <Klugscheissmodus aus> Taste drücken möchtest.


> wenn man einfache statische Objekte mit Methoden ohne Vererbung hätte. Dann wäre auch die Abarbeitungszeit wieder deterministisch.


Da meinst Du sicherlich FBs, ja die gibt es.

Einen Teil Deiner Ideen kann ich hier ja sogar nachvollziehen, ich schätze, daß Du frisch der akademischen Welt entstiegen bist; ein Junginformatiker / Jungingenieur (letzteres war ich auch mal), der versucht sein überproportional vorhandenes Fachwissen (gerade gelerntes Wissen hat eine sehr kurze Halbwertzeit) gegen gewachsenes Wissen auszuspielen. Vor 8 Jahren habe ich mein Diplomzeugnis überreicht bekommen, vor 17 Jahren meinen Führerschein. Ich habe es kürzlich ausprobiert, durch eine Führerscheinprüfung würde ich durchfallen – und das bei den 60.000km, die ich im Jahr zurücklege.

Einen guten Automatisierer macht aus, daß er Prozesse kennt, die er letztlich automatisiert, daß er Lösungen für Prozesse und Prozessbediener (den Werker, der mit der Technik Tag für Tag konfrontiert ist) schafft, selbstverständlich muß er sich dann auch mit seinen Werkzeugen auseinandersetzen, nur bestimmen kann er diese kaum. Er nimmt die Werkzeuge, die für ihn und die Problemlösung die Sinnvollsten sind. Mir erschien hier selten ein Werkzeug als geeignet, daß sich nicht schon an anderer Stelle bewährt hatte; arg konservativ. Ich habe allerdings (da unser Unternehmen fast ausschließlich Unikate herstellt) nicht die (teilweise unverschämten) Testmöglichkeiten der Softwareindustrie, die nun mal Serienfertigung betreibt. Anlagen gibt es nun mal nicht als Beta-Release und niemand wäre bereit, vierteljährliche Service Packs zu bezahlen


----------



## drfunfrock

> Einen Teil Deiner Ideen kann ich hier ja sogar nachvollziehen, ich schätze, daß Du frisch der akademischen Welt entstiegen bist; ein Junginformatiker / Jungingenieur (letzteres war ich auch mal), der versucht sein überproportional vorhandenes Fachwissen


Nee, ich bin noch schlimmer. Ich habe eine Menge Berufserfahrung und meine immer noch, das Theorie nicht gegen Erfahrung ausgespielt werden darf. Im Prinzip ergänzt sich Erfahrung mit Theorie ganz gut, denn beide ermöglichen die Weiterentwicklung. Nicht jeder hat dazu Lust, sich auf Risiken einzulassen und das ist OK. Ich schon.  Die nächste Herausforderung werden die Schaltschränke für die SPS sein. Das Chaos, das wir haben funktioniert zwar, ist aber höchst anfällig. Ich erzähl es lieber nicht.


> (gerade gelerntes Wissen hat eine sehr kurze Halbwertzeit) gegen gewachsenes Wissen auszuspielen. Vor 8 Jahren habe ich mein Diplomzeugnis überreicht bekommen,


Ich habe 84 angefangen Assembler zu programmieren. 92 habe ich Datenbanken mit einer 4GL-Sprache  programmiert, um dann festzustellen, dass das zu langweilig ist. Mittlerweile kann ich die Zahl der erlernten Sprachen nicht mehr erfassen. Ich habe dann unter anderem Elektronik für Schrittmotoren entwickelt und die Produktion dieser Entwicklungen überwacht. Nun bin ich in ruhigeren Gewässern und bin nur noch für die technische Fortentwicklung der Produktion verantwortlich. Im Prinzip fehlen mir noch rudimentäre Installationskenntnisse von Elektroanlagen. Das fängt damit an, wie ich Erdpotentialschienen montiere und hört mit dem Schaltschrank auf..


> Er nimmt die Werkzeuge, die für ihn und die Problemlösung die Sinnvollsten sind. Mir erschien hier selten ein Werkzeug als geeignet, daß sich nicht schon an anderer Stelle bewährt hatte; arg konservativ.


Ich habe lange mit Software arbeiten müssen, die in Teilen stark fehlerhaft und doch benutzbar war. Das schafft eine etwas andere Mentalität und ich muss mich zur Zeit daran gewöhnen, das Betriebssicherheit vorgeht. Ich wähle genauso wie du die geeigneten Werkzeuge aus. Gute Ausbildung schafft dafür die Vorraussetzung. Das einzige was ich nicht akzeptiere, sind Aussagen, wie das es schon immer so gewesen sei.


> Ich habe allerdings (da unser Unternehmen fast ausschließlich Unikate herstellt) nicht die (teilweise unverschämten) Testmöglichkeiten der Softwareindustrie, die nun mal Serienfertigung betreibt. Anlagen gibt es nun mal nicht als Beta-Release und niemand wäre bereit, vierteljährliche Service Packs zu bezahlen



Nein, sicherlich nicht. Da wird die Strategie auch etwas solider als bei uns sein müssen. Ich weiss ja nicht,wie es mit den Simulationsmöglichkeiten steht? Man wird sicherlich keine Anlage 100% simulieren können, aber wichtige konzeptionelle Fehler aufzudecken wäre schon ein Gewinn. Im übrigen, wenn ich hier für meine Arbeit gute Noten bekomme, heisst dass noch lange nicht, dass diese gut , im Sinne eines erfahrenen Automatisierers. Es ist leicht zu Punkten, wenn man aus dem tiefen Tal kam. 

Und nun doch noch etwas zum objektorientierten Programmieren:

Wieso bist du der Meinung, dass FBs als Objekte angesehen werden können? Sicher man kann Daten in ihnen ablegen und diese damit privat halten, hat aber letztlich nur eine Funktion? Memberfunktionen über einen Parameter abzubilden ist meiner Meinung nach etwas unschön. Ich habe so etwas mal mit C gemacht, um es etwas leichter zu haben. Dachte ich, aber der Code war schlimmer, als wenn ich es ohne gemacht hätte.


----------



## Ralf

@drfunrock
Nunja, geht doch, aber diesmal wesendlich friedlicher. (Ich schütze jetzt mal, daß Deine Situation – Wir müssen die WASAUCHIMMER Anlage ans Laufen bringen ) Dich etwas aus dem Konzept warf.

Daher nun mal in Deinem sachlichen und freundlichen Beitrag von hinten nach vorne:


> Wieso bist du der Meinung, dass FBs als Objekte angesehen werden können? Sicher man kann Daten in ihnen ablegen und diese damit privat halten, hat aber letztlich nur eine Funktion? Memberfunktionen über einen Parameter abzubilden ist meiner Meinung nach etwas unschön. Ich habe so etwas mal mit C gemacht, um es etwas leichter zu haben. Dachte ich, aber der Code war schlimmer, als wenn ich es ohne gemacht hätte


Im Endeffekt sind  Objekte ja auch nur eine Sammlung von ‚Eigenschaften’ – sprich Speichervariablen und ‚Methoden’ – Subroutines, die jetzt dem Objekt zugeordnet werden. Die Objektorientiertheit, (ein riesiges Modethema dank Java und jetzt auch noch .NET) wurde auch nur durch die Instanzierbarkeit zum Hype. Der Rest ist auch in 1st Level Sprachen einfach zu realisieren.


> Nein, sicherlich nicht. Da wird die Strategie auch etwas solider als bei uns sein müssen. Ich weiss ja nicht,wie es mit den Simulationsmöglichkeiten steht? Man wird sicherlich keine Anlage 100% simulieren können, aber wichtige konzeptionelle Fehler aufzudecken wäre schon ein Gewinn.


Wir tun, was wir können – jedoch arbeiten wir im Gebiet der Thermodynamik – da wird’s mit der Simulation immens schwierig. Letztlich sieht es so aus
1.	Modellbildung - Planung
2.	Anlage im ‚Probebetrieb’
3.	Anpassung des Modells an die Realität (gar nicht mal die Steuerung -  Regelungstechnik ist das Hauptproblem)
4.	Begleitende Produktion ... Optimierung


> Die nächste Herausforderung werden die Schaltschränke für die SPS sein. Das Chaos, das wir haben funktioniert zwar, ist aber höchst anfällig. Ich erzähl es lieber nicht.





> Im Prinzip fehlen mir noch rudimentäre Installationskenntnisse von Elektroanlagen. Das fängt damit an, wie ich Erdpotentialschienen montiere und hört mit dem Schaltschrank auf..


Nirgendwo auf der Welt werden so grauenhafte Fehler gemacht, wie im Erdungskonzept von Anlagen. Letztlich wird es bei Dir vermutlich um die Datenübertragungsmedien gehen. Ein BUS ist ja ein binäres System und reagiert auch so – er funktioniert immer, nur wenn er absolut nicht ausfallen darf tut er auch das...
Du solltest diese Schwachstellen der Anlage von (hierauf) geschulten Leuten untersuchen lassen (dies erspart viel graues Haar)


----------



## Ralf

@drfunrock
.... wollte noch was von Dir .....
Du kennst Dich mit Schrittmotoren aus? Ich hab nämlich gerade ein Problem, bei dem ein Schrittmotor eine gravierende Rolle Spielt. Die konkrete Frage folgt am Montag.


----------



## drfunfrock

Ralf schrieb:
			
		

> @drfunrock
> Nirgendwo auf der Welt werden so grauenhafte Fehler gemacht, wie im Erdungskonzept von Anlagen. Letztlich wird es bei Dir vermutlich um die Datenübertragungsmedien gehen. Ein BUS ist ja ein binäres System und reagiert auch so – er funktioniert immer, nur wenn er absolut nicht ausfallen darf tut er auch das...
> Du solltest diese Schwachstellen der Anlage von (hierauf) geschulten Leuten untersuchen lassen (dies erspart viel graues Haar)



Ich weiss. Nur bevor ich damit zu einem Fachmann laufe, muss ich meine eigenen Wünsche artikulieren können, allein schon um grob abschätzen zu können, wie hoch der Aufwand wird. Ich weiss noch aus meiner Zeit als Radio- und Fernsehtechniker, dass wir - auf Weisung des Chefs - desöfteren bei kalten Lötstellen ganze Bauteile getauscht haben, weil er glaubte, die Kunden wollen den Aufwand für Anfahrt nicht auf der Rechnung sehen. Damit mir so etwas vergleichbares nicht passiert,  werde ich mich zwangsläufig in die Materie hineinarbiten müssen.


----------



## Oberchefe

> Ich weiss noch aus meiner Zeit als Radio- und Fernsehtechniker, dass wir - auf Weisung des Chefs - desöfteren bei kalten Lötstellen ganze Bauteile getauscht haben,



Was durchaus Sinn macht, beispielsweise bei Impulskondensatoren in der Horizontalablenkung. Diese werden nämlich durch das Aussetzen überstrapaziert und fallen deshalb oft früher oder später aus. Ein seriöser Reparaturbetrieb wird diesen möglichen Ausfall wegen eines Bauteilewerts von ein paar Euros nicht in Kauf nehmen.


----------



## sps-concept

*Respekt*

na langsam scheint ja wieder Respekt vor der Arbeit anderer einzuziehen. Ich finde dass Leute die aus Hochsprachen kommen viel zu schnell Wertungen vornehmen. Es ist in der Automatisierungstechnik nicht umsonst so wie es ist. Wegen der Teileverfolgung: zumindest sollte eine Kennung der Gehängenummer mitfahren. Die dazugehörigen Daten können in der SPS verwaltet werden. Vor jeder Weiche und Bearbeitungsstation wird ausgewertet "was steht hier? wird was gemacht? was wird gemacht? wo will er hin?" Dann wird noch dies und das eingetragen. Das ganze sollte schon so konzipiert sein dass nicht sämtliche Kennungen "durchgeschoben" werden. Sowas ist meiner Meiung nur für Visualisierungen akzeptabel, aber nicht für Sachen wo der Produktionsprozess dranhängt, Crashs durch falsche Typkennungen passieren können usw. Und auch solche Sachen wie Chargenkennungen sollten sicher sein.

@Ralf  welches Coupe haste denn da ins Auge gefasst?

MfG
André Räppel


----------



## Ralf

@SPS Concept
als Firmenwagen 'nen A4 Diesel - fürs gleiche Geld gibt (aua, war das ein Rechtschreibfehler, daher editiert) aber beim gleichen Hersteller 'nen TT - damit kann man

a - Zügiger um die Kurve kommen
b - Besser vor den Frauen renomieren

Die Karre paßt nur nicht in unsere Firmenwagenrichtlinie ...    :wink:


----------



## sps-concept

*Coupe*

@Ralf

schön und gut son TT, aber is nichmal im Notfall für 4 Mann. Zügiger in den Kurven OK. nen erhöhten Babefaktor hats auch. Hatte auch mal sowas ins Auge gefasst aber wieder verworfen.

André


----------



## drfunfrock

Oberchefe schrieb:
			
		

> Was durchaus Sinn macht, beispielsweise bei Impulskondensatoren in der Horizontalablenkung. Diese werden nämlich durch das Aussetzen überstrapaziert und fallen deshalb oft früher oder später aus. Ein seriöser Reparaturbetrieb wird diesen möglichen Ausfall wegen eines Bauteilewerts von ein paar Euros nicht in Kauf nehmen.



Oh nein, es waren nur simple Dioden. Das war damals bei den alten Telefunken Geräten ein Standart-Problem.


----------



## drfunfrock

*Re: Respekt*



			
				sps-concept schrieb:
			
		

> Wegen der Teileverfolgung: zumindest sollte eine Kennung der Gehängenummer mitfahren. Die dazugehörigen Daten können in der SPS verwaltet werden. Vor jeder Weiche und Bearbeitungsstation wird ausgewertet "was steht hier? wird was gemacht? was wird gemacht? wo will er hin?" Dann wird noch dies und das eingetragen. Das ganze sollte schon so konzipiert sein dass nicht sämtliche Kennungen "durchgeschoben" werden. Sowas ist meiner Meiung nur für Visualisierungen akzeptabel, aber nicht für Sachen wo der Produktionsprozess dranhängt, Crashs durch falsche Typkennungen passieren können usw. Und auch solche Sachen wie Chargenkennungen sollten sicher sein.



Ich mach es so simpel wie möglich. Einfach alle Prosesse zu einem Produkt in einem Array speichern.  Eine Station hat dann eben nur ein Element, aber max. 3 Prozesse in der Liste.  Jeder Wagen wird natürlich nummeriert., allerdings nur in der Startstation. Ein Barcodeleser auf jeder Station wäre IMHO etwas zu viel gewesen. Wird der Betrieb unterbrochen kann ich die Wagen jederzeit ein 2. mal durch die Anlage schicken, weil die Information über den nächsten Prozessschritt da ist.


----------



## zotos

http://de.wikipedia.org/wiki/STEP_7    :?:



> STEP 7 beherrscht in der Basisversion die nach DIN EN 61131 genormten Programmiersprachen Anweisungsliste (AWL), Kontaktplan (KOP) und Funktionsplan (FUP). Der Erweiterungsteil (Engineering Tools) enthält weitere Programmiersprachen sowie Software zur Diagnose und Simulation. Die aktuelle Version erlaubt objektorientierte Programmierung.



Der Letzte Satz  :?:  :?:  :?:


----------

