Android versus SPS

Zuviel Werbung?
-> Hier kostenlos registrieren
Meiner Meinung nach ist es zwar ne Gute Idee, aber wie schon vorher erwähnt die Industrie lässt sich selten auf neues ein lieber etwas älter aber für jeden halbwegs intressierten Instandhalter zu bewältigen.

Natürlich ist die Innovationsfreude in der Automatisierungstechnik geringer. Aber das ist auch verständlich bei Maschinenlebensdauern von 15 Jahren und länger.
Es gibt aber durchaus Innovationen, die sich durchsetzen. Beispiel sind SCL / ST oder CFC oder HMI-Scriptsprachen.
Doch was eigentlich immer noch fehlt und was uns wirklich was bringen würde, wären leistungsfähige Entwicklungsumgebungen.
Allein schon eine vernünftige Integration von mech. CAD, elektr. CAD und SPS-Entwicklungsumgebung würde es uns allen erleichtern.
Und was wurde uns von den Marketingleuten versprochen. Ich höre da noch Sprüche von vor 10 Jahren ala "Unser System ist XML basierend. Da wird der Datenaustausch zum Kinderspiel!" Und was ist passiert? Letzlich alles Marketing-Dampfplauderer! Aber vielleicht klappt es ja mit Android :ROFLMAO:

Gruß
Dieter
 
Es gibt Ideen, die von vornheirein schon Schnulli sind. Das wäre so, als würde jemand ein Studie erstellen Achteckige Räder ans Fahrrad zu bauen.

Mir reicht schon diese "Idee" alles und jedes mit FLASH, DotNet und JAVE vollzumüllen. Wenn ich in meine Postfach will, da muß ich erst mal die neueste Flash installieren - krank sowass.


Frank

Die Idee ne S7 oder was auch immer mit nem Android System zu Tauschen wird sich sowieso nicht Durchsetzen.
Okay der Herr ist Elektroinstallateur und Dipl.Ing Technische Informatik wenn ich das Richtig aus dem Blog gelesen habe,
er hatte ne Idee und die will er jetzt gerne realisieren ich wage aber zu bezweifeln das er weiß wie Nervenaufreibend eine IBN oder eine Fehlersuche in einem unbekannten Programm was man nicht selber geschrieben hat sein kann.

Ich persönlich finde wie schon erwähnt die Idee okay aber ehrlich gesagt möchte ich damit auch nichts zu tun haben.

Ich bin zufrieden mit dem was der Markt hergibt damit kann man so ziemlich alles realisieren was das Herz bzw. der Kunde wünscht

So meine Meinung dazu
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Seit euch versichert, dass ich die Buzzwords, mit denen ich um mich schmeisse, kenne und zum Dipling auch gelernt habe.
Ebenso kenne ich kleine, grosse und/oder schlechte Programme aller Stilrichtungen von Anderen, sowie auch von mir. ;) Allein diese Quelltexte aergern mich so, dass ich etwas dagegen tun moechte.

Das bei der klassischen SPS auf Interrupts von der Mehrheit nicht geachtet wird, ist nicht ernsthaft zu bestreiten. Ich bezweifel auch, das eine Grosszahl der Entwickler jemals etwas davon gehoert haben. Das sie in der SPS anzutreffen sind, ist aber gegeben.
Nach einem Zyklus ein neues Speicherabbild durch die Zustaende der Sensoren/Endschalter zu erzeugen und den Zyklus von Neuem zu beginnen, ist die klassische Aufgabe eines Interrupts. Duch ein definiertes Ereignis Register retten, Interrupt bearbeiten, Register zurueckschreiben. In diesem Fall wird nur einer verwendet und eben auch nicht so genannt.
Wie reagiert denn der klassische SPSler auf Ereignisse die sich waerend der Zykluszeit ereignen? Die entgehen ihm im Normalfall und er hat das selbe Dillemma.
Den Umgang mit Deadlocks kann man auch lernen. Der Gewinn ist in der Regel eine wesentlich bessere Auslastung der CPU.


Was mich freut ist, dass die Diskussion doch noch Fahrt aufgenommen hat und einigen Beitraegen danke ich explizit. Was einige verkennen, ist das ich kein gluecksseeligmachendes Produkt in der Tasche habe und dieses morgen mit schoenen Zitaten von euch auf "den Markt" werfen werde. Es gibt nur diese eine Idee und so diffus wie sie noch existiert, taugt sie sicherlich zum bashing und damit muss ich leben. Was ich mir aber verbitte, ist eine Charakterstudie ueber meine Person, inklusive Aussagen ueber mein Wissen und Koennen.

Gruss
Dieter
 
Das bei der klassischen SPS auf Interrupts von der Mehrheit nicht geachtet wird, ist nicht ernsthaft zu bestreiten. Ich bezweifel auch, das eine Grosszahl der Entwickler jemals etwas davon gehoert haben. Das sie in der SPS anzutreffen sind, ist aber gegeben.
Nach einem Zyklus ein neues Speicherabbild durch die Zustaende der Sensoren/Endschalter zu erzeugen und den Zyklus von Neuem zu beginnen, ist die klassische Aufgabe eines Interrupts. Duch ein definiertes Ereignis Register retten, Interrupt bearbeiten, Register zurueckschreiben. In diesem Fall wird nur einer verwendet und eben auch nicht so genannt.
Wie reagiert denn der klassische SPSler auf Ereignisse die sich waerend der Zykluszeit ereignen? Die entgehen ihm im Normalfall und er hat das selbe Dillemma.
Den Umgang mit Deadlocks kann man auch lernen. Der Gewinn ist in der Regel eine wesentlich bessere Auslastung der CPU.

Ehrlich gesagt ist das schlichtweg falsch was du hier schreibst.
Das Erzeugen des Prozessabbildes hat überhaupt nichts mit Interrupt zu tun. Es wird am Anfang des Zyklus eingelesen bzw. geschrieben. Letzlich läuft ein "normales" SPS-Programm in einer Endlosschleife durch und das Aktualisieren des PA ist ein Teil davon.
Im Bereich Interrupt-Handling ist eine SPS mindestens genauso flexibel wie die Android-Basis Linux. Du hast Hardware-, Zeit- und Systeminterrupts. Und damit kannst du sehr wohl auf Ereignisse während des Zyklus reagieren.
Die bessere Auslastung einer CPU ist völlig uninteressant! Was wichtig ist, ist eine gleichmässige Auslastung der CPU. Man will oder besser gesagt man braucht konstante Reaktions- bzw. Zykluszeiten. Im Bereich Regelungstechnik arbeitet man deshalb eben mit den Zeitinterrupts der SPS um eine konstante Abtastung und somit Regelung zu erreichen.

Aber jetzt mal andersherum:
Wie stellst du dir ein System auf Android-Basis vor?
Wie soll das IO-Handling funktionieren?
Wie die Programmbearbeitung?
Wie das interne Signalhandling?
Wie das Debugging im laufenden Betrieb?
Wie Code-Änderungen im laufenden Betrieb?

Skizziere doch mal bitte folgenden Ablauf in deinem System:

Code:
Aktion: Spannvorrichtung schliessen
Transition: Spannvorrichtung geschlossen
Aktion: Bohren ein und Bohren ab
Transition: Bohren unten
Aktion: Wartezeit starten
Transition: Wartezeit Ende
Aktion: Bohren auf
Transition: Bohren oben
Aktion: Bohren aus
Ablauf Ende

Permanente Operation:
Abfall Spannung -> Not-Halt des Bohrantriebs

Also eine ganz einfacher sequentieller Ablauf ohne Betriebsarten, Hand- und Rüstfunktonen.

Vielleicht hast du ja wirklich gute neue Ideen, die keiner von uns bisher gesehen hat.

Gruß
Dieter
 
Nach einem Zyklus ein neues Speicherabbild durch die Zustaende der Sensoren/Endschalter zu erzeugen und den Zyklus von Neuem zu beginnen, ist die klassische Aufgabe eines Interrupts. Duch ein definiertes Ereignis Register retten, Interrupt bearbeiten, Register zurueckschreiben. In diesem Fall wird nur einer verwendet und eben auch nicht so genannt.
Wie reagiert denn der klassische SPSler auf Ereignisse die sich waerend der Zykluszeit ereignen? Die entgehen ihm im Normalfall und er hat das selbe Dillemma.
Den Umgang mit Deadlocks kann man auch lernen. Der Gewinn ist in der Regel eine wesentlich bessere Auslastung der CPU.
Wie stellst du dir das mit Interrupts vor, bzw. was wäre hier "besser"?

Die zyklische Bearbeitung der Prozessabbilder hat auch den praktischen Grund der Kommunikation in der Feldebene. Ein Feldbussystem sorgt für den Datenaustausch, indem alle Teilnehmer per Telegramm Updates in einer definierten Zeitspanne erhalten. Sowohl das Datenaufkommen als auch die Updatezeit ist vorhersehbar => Echtzeitfähigkeit.
Man kann die Abtastrate durch kürzere Zykluzeiten verbessern, oder mittels Eventpuffer oder Timestamp (in der Hardware).

Prozessdatenaustausch nach Interrupts über den Feldbus? Sowas wird z.B. bei LON gemacht und hat den Effekt, dass theoretisch alle Teilnehmer zur gleichen Zeit senden könnten => unkontrollierbare Netzwerkauslastung => Echtzeitfähigkeit ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie der Zufall es will: Wegen schlechter Steuerung 2 Tage nicht verfügbar.

"Das Erzeugen des Prozessabbildes hat überhaupt nichts mit Interrupt zu tun."
Dann habe ich mich falsch ausgedrückt. Was letztendlich in einer Interrupt-Routine abgearbeitet werden soll, war nicht der Zweck meiner Aussage. - Eher ein Beispiel. Bitte konkretisiere selber einmal, wie ein 'normaler' Durchlauf in Endlosschleife bei der SPS aussieht. Was mach dessen CPU, wenn sie an der letzten Speicherstelle des Programms angelangt ist? Durch was kommt sie wieder zur Ersten? Alleinige Willenskraft kann es nicht sein. ;)
Die Weisheit habe ich nicht mit Löffeln gefressen und belehren lass ich mich ab und an auch ganz gerne.

'Belehren' ist auch das passende Stichwort:
Wie du letztendlich dein Programm haben bzw. benennen willst, in Scriptform, als Sequenz, als Schrittkette, etc. bleibt völlig dir überlassen! Wenn deine Untersuchung herausgestellt hat, dass die Anlage nur funktioniert, dass sie zuerst den Bohrer schließt, dann senkt, dann wartet, ...dann ist das so. - Ohne wenn und aber.
Die Objektoriente Architektur, die mir dabei vorschwebt und auf die ich mich einlassen möchte, ist eher in diesem Pseudocode für den Bohrer widerzufinden. Und könnte bestimmt ne ganze Ecke eleganter aussehen.

Code:
class Bohrer {
 final static int position_up = 1;
 final static int position_down = 2;
 final static int state_open = 1;
 final static int state_closed = 2;
 final static int state_fail= 0;

 Bohrer(){}

 setPosition(int position){
  switch(position){
   case position_up: //setze Ausgang/Pin/... auf 1
  [...]  
  }
 }
 setState(){...}

  getPosition(){..}
 getState(){...}
}

"Wie stellst du dir ein System auf Android-Basis vor?" - Das wäre bei mir ein Verbund aus Tablet/Mini-PC/RasberryPi/... und IOIO-Board/Arduino.
"Wie soll das IO-Handling funktionieren?" - Polling der Eingänge, Threadgesteuert in einem festen Zeitintervall (falls gewollt) oder so schnell als möglich
"Wie die Programmbearbeitung?" / "Wie das Debugging im laufenden Betrieb?" - Zielt die Frage darauf ab, welche IDE ich verwende und wie diese zu benutzen ist? Oder wie die Anlage im laufenden Betrieb technisch beobachtet wird?
"Wie Code-Änderungen im laufenden Betrieb? " - Wie machst du das denn 'im laufenden Betrieb'? Ein erneutes Hochladen ist ja bei der klassischen SPS auch von Nöten. Ob ich in dieser Zeit das Programm neu kompiliere, sollte keinen Unterschied machen.
"Wie das interne Signalhandling?" - Das ist in der Tat kniffliger als ich es anfangs gedacht hatte. Da werde ich über ein gutes Verfahren noch einmal nachdenken müssen.

"Vielleicht hast du ja wirklich gute neue Ideen, die keiner von uns bisher gesehen hat."
Das ist möglich, maße ich mir aber nicht an.


Gruß
Dieter
 
Hallo trinitaucher!

"Ein Feldbussystem sorgt für den Datenaustausch, indem alle Teilnehmer per Telegramm Updates in einer definierten Zeitspanne erhalten. Sowohl das Datenaufkommen als auch die Updatezeit ist vorhersehbar => Echtzeitfähigkeit."
- Das beschreibt die 'weiche Echtzeitfähigkeit' und die ist durch viele Mittel zu realisieren.

Eine 'harte Echtzeitfähigkeit' ist nur dann gegeben, wenn eine Bearbeitung unmittelbar auf ein ein Ereignis (idR Interrupt) geschieht. Und die CPU stoppt, falls die Aufgabe nicht in der Zykluszeit rechtzeit verarbeitet werden kann. Bei der 'weichen' wäre das nicht unbedingt ein Fehler.

Wie ich in der vorherigen Antwort erwähnt hatte, ist das interne Signalhandling bei Android doch eine andere Hausnummer. Zu deinem Thema kann ich also nicht mit bestimmtheit sagen, wie schnell und in welcher Güte ich Eingangszustände weiterverarbeiten kann. - Das nehme ich mir als Hausaufgabe nochmal mit.


Gruß
Dieter
 
Hallo trinitaucher!

"Ein Feldbussystem sorgt für den Datenaustausch, indem alle Teilnehmer per Telegramm Updates in einer definierten Zeitspanne erhalten. Sowohl das Datenaufkommen als auch die Updatezeit ist vorhersehbar => Echtzeitfähigkeit."
- Das beschreibt die 'weiche Echtzeitfähigkeit' und die ist durch viele Mittel zu realisieren.

Das ist nicht richtig. Ich kann einer SPS sehr wohl sagen, wie schnell sie auf ein Ereignis reagieren soll und muss. Dazu gibt es die maximale Zykluszeit. wenn die überschritten wird, wird ein Fehler generiert. Ob jetzt die CPU in Stopp geht oder der Programmierer erstellt eine reaktion auf den Fehler sei dahingestellt.

Eine 'harte Echtzeitfähigkeit' ist nur dann gegeben, wenn eine Bearbeitung unmittelbar auf ein ein Ereignis (idR Interrupt) geschieht. Und die CPU stoppt, falls die Aufgabe nicht in der Zykluszeit rechtzeit verarbeitet werden kann. Bei der 'weichen' wäre das nicht unbedingt ein Fehler.

Wie ich in der vorherigen Antwort erwähnt hatte, ist das interne Signalhandling bei Android doch eine andere Hausnummer. Zu deinem Thema kann ich also nicht mit bestimmtheit sagen, wie schnell und in welcher Güte ich Eingangszustände weiterverarbeiten kann. - Das nehme ich mir als Hausaufgabe nochmal mit.


Gruß
Dieter

Ich bezweifele das das Android leisten kann (so ganz ohne Systemverbiegen ala Soft-SPS). Ich bin grundsätzlich für alles neue zu haben. Allerdings muss es auch so funktionieren. Ansonsten ist das alles hinfällig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"Ein Feldbussystem sorgt für den Datenaustausch, indem alle Teilnehmer per Telegramm Updates in einer definierten Zeitspanne erhalten. Sowohl das Datenaufkommen als auch die Updatezeit ist vorhersehbar => Echtzeitfähigkeit."
- Das beschreibt die 'weiche Echtzeitfähigkeit' und die ist durch viele Mittel zu realisieren.

Eine 'harte Echtzeitfähigkeit' ist nur dann gegeben, wenn eine Bearbeitung unmittelbar auf ein ein Ereignis (idR Interrupt) geschieht. Und die CPU stoppt, falls die Aufgabe nicht in der Zykluszeit rechtzeit verarbeitet werden kann. Bei der 'weichen' wäre das nicht unbedingt ein Fehler.
Über die Definition von Echtzeitfähigkeit kann man streiten, aber in der Automatisierungstechnik bedeutet es i. d. R., dass eine Reaktion auf ein Ereignis in einer definierten Zeit erfolgen muss. Ist die maximale Reaktionszeit mit 10 Millisekunde festgelegt, ist das System echtzeitfähig, wenn die Reaktionszeit gleich oder besser ist.
Die Reaktion muss nicht zwingend "unmittelbar" erfolgen. Und selbst wenn doch, so gibt es doch immer Verzögerungszeiten. Und wenn man für die "unmittelbare" Reaktion (1 ms, 1 µs, 1 ns ...?) schon Mindestmaße definiert, kann man auch gleich meine o. g. Definition nehmen.

Die "weiche" Echtzeit ist eher ein Begriff aus der IT-Welt, wo es gewisse Toleranzen gibt, bzw. aus Anwendersicht ein gewisses Toleranzmaß geduldet wird und nicht sofort zu Fehlern oder Ausschuss in der Produktion führt.
 
Danke für deinen Pseudocode.
Wenn ich diesen anschaue, dann kannst du diesen heute schon fast so auf einer normalen SPS umsetzen.
Schau dir mal Codesys 3 oder das aktuelle Twincat an. Dort findest du Objektorientierung.
Selbst auf einer S7 kann ich mit entsprechender Verwendung von UDTs und Strukturen quasi in diesem Stil programmieren.

Du kannst dir auch mal das Microsoft Robotics Development Studio anschauen. Dort sind auch manche deiner Ideen zu finden.
Aber nicht erschrecken, da geht auch viel mit der grafischen Programmierung.

Ebenso kannst du dir Anregungen bei S7-Higraph holen. Damit wird ein SPS-Programm durch das Modellieren Zustandsgraphen erzeugt.

Einen ebenfalls recht interessanten Ansatz bietet das Qt-Framework. Das interne Messaging findet durch Signals und Slots statt. Dieses Konzept liese sich vielleicht auch in die Automatisierungstechnik übertragen.

Die Jungs von IP-Symcon haben ein System auf PHP-Basis. Dies nutze ich für meine Homeautomation. Vielleicht kannst du auch darauf mal einen Blick werfen.

Und wenn du ein System zum "Üben" willst, dann hol dir einen Wago 750-860-Controller. Dieser läuft unter einem Linux-Betriebssystem (wie dein Android) und du kannst deine Vorstellungen auf einer realen Hardware umsetzen.

Aber trotz aller deiner Ausführungen, habe ich nach wie vor den Eindruck, dass du eigentlich gar nicht weißt, wie man mit einer SPS heute programmieren kann.
Du kennst viele schlechte Programme (wie die meisten von uns hier), aber kennst du auch richtig gute Programme?

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich möchte hier auch ganz klar die Qualität dieser Diskussion unter folgendem Gesichtspunkt in Frage stellen:

Das was du vorhast ist weder neu noch wirklich Innovativ.

Ich kann mit jedem beliebigen Betriebssystem, einem Compiler sowie dem nötigen Programmieraufwand die Aufgaben einer SPS übernehmen, das ist genauso wenig die Kunst wie eine SPS zu programmieren (ich rede jetzt von mir und nicht ins Allgemeine, nicht jeder Programmierer kann mit einer SPS umgehen).

Wie Dieter aber richtiger weise geschrieben hat:

Hast du jemals ein "richtig gutes" SPS-Programm gesehen?

Wenn ja wirst du feststellen das sich ein richtig gutes Programm (egal auf welcher Plattform oder mit welcher Programmiersprache es erstellt wurde) sich nicht dadurch auszeichnet, wie viele Interrupts, Subroutinen, Vererbungen oder Objekten und Strukturen auszeichnet.

Ein richtig gutes Programm zeichnet sich vielmehr dadurch aus, das wenn ich es öffne und versuche es zu verstehen, eine entsprechende Kommentierung habe, das Funktionen oder Strukturen so sind das Sie tatsächlich nach 10 Jahren noch jemand versteht ohne an der Planung/Umsetzung der Anlage beteiligt war, und der WOW-Effekt kommt bei einem "richtig guten" Programm davon, das es möglichst simpel aber technologisch korrekt ist.

Das ist meine Definition eines "richtig guten Programms"

Die Variante über Android (was wie bekannt ist kein Betriebssystem sondern eine um den Linux-Kernel herumgebaute Anzahl an definierten Funktionen darstellt) über diverse Bibliotheken und Treiber auf IO-Boards zuzugreifen widerspricht "meiner" Definition eines "richtig guten Programms" den der programmierische Overhead im Bereich "Fehlersuche im Gesamtsystem" ist nicht zu unterschätzen. Hier erweitern wir die eh schon unzähligen Ursachen nochmals um eine undefinierte Anzahl Möglichkeiten. Hinzu kommt bei solchen Programmiervarianten wie C und Co. die Tatsache das der Code nicht im Real-Format (also durch Erstellersprache) gedebbuged werden kann, was ich im Bereich Automation als unzulässig empfinde da der Hardware-Fehler meist nicht dort liegt wo das Programm den Fehler generiert. Oftmals sind es Kombinationen aus vielfältigen Faktoren (Regelkreis hat ja schonmal 3, Regelkaskade einer Lüftung hat mindestens 5, meist noch mehr Faktoren nur in der Software, die Hardware-Meldungen noch nicht berücksichtigt) die zum Fehler "Temperatur passt nicht" führen.
 
Ein richtig gutes Programm zeichnet sich vielmehr dadurch aus, das wenn ich es öffne und versuche es zu verstehen, eine entsprechende Kommentierung habe, das Funktionen oder Strukturen so sind das Sie tatsächlich nach 10 Jahren noch jemand versteht ohne an der Planung/Umsetzung der Anlage beteiligt war, und der WOW-Effekt kommt bei einem "richtig guten" Programm davon, das es möglichst simpel aber technologisch korrekt ist.

Das ist meine Definition eines "richtig guten Programms"

Treffender hätte ich es auch nicht beschreiben können.

Es gibt eine berühmte Buchreihe "The Art of Computer Programming" von Donald E. Knuth. Dort gibt es eine Aussage (ich hoffe dass ich richtig zitiere) "Nur ein schöner Code ist guter Code". Und ich denke dies trifft auf jede Sprache zu.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Treffender hätte ich es auch nicht beschreiben können.

Es gibt eine berühmte Buchreihe "The Art of Computer Programming" von Donald E. Knuth. Dort gibt es eine Aussage (ich hoffe dass ich richtig zitiere) "Nur ein schöner Code ist guter Code". Und ich denke dies trifft auf jede Sprache zu.

Und Schönheit liegt immer im Auge des Betrachters, darum lässt sich das als Qualitätsaussage für ein Programm nicht heranziehen.
Denn es gibt auch Programmierer die Schmiermerker schön finden.
 
Naja glaub da geht es sich eher um bewusste verwirrung bzw. Auf- / Nachtragssicherung ... Ist das selbe mit Programmen ohne Symbolik und DB's nur voll mit Arrays.

Ein schönes Programm machst du auf und oben steht genau was der Baustein macht und jede Unterfunktion ist kommentiert!
Frisst zwar die meiste Zeit aber es ist es Wert!

Zu der Diskussion hier:
Kann man über nen C-Editor, obgleich bei so nem Androidsystem oder irgend ner anderen Soft-SPS überhaupt "beobachten" wie es bei jeder SPS ohne Probeme geht?
Wenn ich mich an meine Mikrokontrolerunterricht erinner war das immer ne faas.
Und ohne diese Möglichkeit finde ich jedes andere System eigentlich hinfällig und indiskutabel weil manche Fehler stecken einfach im Detail und man findet sie durch einfaches Code-anstarren nicht!
 
Zu der Diskussion hier:
Kann man über nen C-Editor, obgleich bei so nem Androidsystem oder irgend ner anderen Soft-SPS überhaupt "beobachten" wie es bei jeder SPS ohne Probeme geht?

Kurze Antwort:
Ja man kann. Und teilweise sgar noch besser als bei SPS.
Hängt von der Entwicklungsumgebung und den Compileroptionen ab.

Gruß
Dieter
 
aber ebend nicht bei den für android zur verfügung stehenden subsystemen

Stimmt. Aber Android als Softwarebasis für die "SPS 2.0" kann man sowieso nicht ernst nehmen.
Was man Android zu Gute halten muss, dass eine Vielzahl guter und günstiger Hardware auf den Markt kommt. Und durch den Linux-Unterbau können viele Gadgets "zweckentfremdet" werden.
Dass der Sprachumfang der SPS modernisiert werden muß, ist wohl auch klar. Durch SINNVOLLE objektorientierte Spracherweiterungen kann man sicherlich viel Programmierzeit sparen. Zumal wir ja in der Realität alle mit Objekten arbeiten. Ich rede hier nicht vom Vererbung und Überladen von Operatoren, sondern eine simple Klassendefinition mit Methoden, Eigenschaften, öffentlichen und privaten Variablen wäre schon ein Fortschritt. Dazu noch eine gute Kopplung zu CAD und HMI und ich wäre zufrieden.

Gruß
Dieter
 
Zurück
Oben