# Android versus SPS



## standroid (15 August 2012)

Hallo Forums-Mitglieder.

Ich versuche seit kurzem heraus zu finden, ob sich Steuerungen in Sachen Entwicklung/Implementierung/Wartung modernisieren lassen.
Dazu habe ich unter standroid.de eine Weiterleitung zu einem Blog eingerichtet, in dem ich dieser Angelegenheit nachgehe.
Es geht dabei nicht um ein fertiges Produkt.
Viel mehr wuensche ich mir dort einige Meinungen von Euch, um heraus zu finden, ob das Vorhaben Sinn macht.


Mit Gruss
D. Steuten


----------



## Gerhard Bäurle (15 August 2012)

Hallo,

ich möchte hier nicht den Miesmacher spielen, aber: 

Passt der Vergleich? Das ist für mich wie "Elektroantrieb versus Auto"

Auf der einen Seite haben wir eine Komponente (das Betriebssystem),
auf der anderen Seite ein Komplettsystem aus Hardware, Runtime, 
Kommunikationstechnologie und Engineeringtools.

Natürlich spricht grundsätzlich nichts dagegen, die Möglichkeiten
von Android in der Automation auszuloten, keine Frage.

Was wären den die Vorteile von Android als Steuerung?


----------



## standroid (15 August 2012)

Hallo Herr Bäurle.
die erste Reaktion und die auch schon am frühen Morgen. Niemand ist für michein miesmacher, da ich ja eben das Interesse dazu erfahren möchte.
 Im allgemeinen werden beide Begriffe als Synonyme für die Dreifaltigkeit aus Hardware, Software und Entwicklung verwendet.  Ein Titel wie: Speicherprogrammierbare Steuerung in der konventionellen Ausführung gegen Speicherprogrammierbare Steuerung in der Ausführung: Android-gerät, ioio-board, Android-sdk und eclipse.
das fand ich aber wenig griffig.

die Vorteile habe ich versucht in dem Blog darzulegen.


----------



## Blockmove (15 August 2012)

Also ich habe mir deinen Blog gerade durchgelesen.

In ähnlicher Form findest du das hier alle 14 Tage.
Ich kenne diese Diskussionen um die Ablösung der SPS seit Ende der 1980er.

Am ehesten haben sich SPS-Systeme auf PC-Hardware durchgesetzt (z.B. Beckhoff).
Die ganzen Versuche die SPS als solches, also zyklische Programmbearbeitung und Programmiersprachen KOP,FUP,AWL, abzulösen sind gescheitert und werden auch weiterhin scheitern.
Im Gegenteil:
Du beschreibst in deinem Blog die Vorzüge der Eventbearbeitung im Gegensatz zur klassischen zyklischen Bearbeitung.
Tja hier sieht die Wirklichkeit anders aus. Eventbearbeitung ist im Bereich Gebäudetechnik stark vertreten. Doch immer mehr Systeme werden hier durch SPS abgelöst.
Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik deutlich besser.

Und selbes gilt genauso für die Programmiersprachen.
Die Vielzahl von Aufgaben, die heute mit einer SPS gelöst werden müssen, kann man nicht sinnvoll mit einer Sprache abdecken!
Du benötigst für jede Aufgabenstellung das richtige Werkzeug / die  richtige Sprache.
Anstelle von weniger Sprachen werden es - glücklicherweise - sogar mehr.
Gab es früher nur KOP, FUP, AWL, so kann ich heute z.B. Schrittketten in Graph / AS, Datenbearbeitung in SCL / ST und Reglungen in CFC programmieren.
Wo soll der Vorteil sein, dies alles in Java zu tun?


Mein Fazit:
Android ist ein schönes System und ich freue mich auf schöne HMI-Systeme auf Android-Basis, aber die klassische SPS werd ich noch bis zur Rente (in max. 20 Jahren) programmieren können.

Gruß
Dieter


----------



## M-Ott (15 August 2012)

Ich habe es mir auch durchgelesen und muss sagen, dass viele der vermeintlichen Vor- oder Nachteile entweder faktisch nicht vorhanden sind (die Sicherheit der SPS gegen Virenangriffe ist wahrscheinlich höher ist definitiv höher als bei Android, da es deutlich weniger Interesse daran und deutlich weniger Menschen mit dem entsprechenden Wissen gibt) oder Vorteile zu Nachteilen uminterpretiert werden ("sequentielle" (zyklische) Programmbearbeitung.)


----------



## standroid (15 August 2012)

Hallo Namenvetter!

Frei nach Kaestner: "Es  gibt nicht Gutes, außer man tut es.", kann ich die Frustration  verstehen, die Ensteht, etwas Neues vorzustellen und dieses nie zu  verwenden. Die Abloeseversuche der SPS seit Ende der 80er ist ein gutes  Beispiel dazu. 
Dass sich dies doch ein wenig auf PC-Basis  durchgesetzt hat, kann verschiedene Gruende haben. Es macht aber mehr  her, wenn kein vollwertiger PC fuer Steuerungsaufgaben abgestellt werden  muss. Daher kann ich die schwache Marktdurchdringung schon verstehen.  Ein 30Dollar, USB-Stick grosser Android-Computer koennte das ganze auch  wieder anders aussehen lassen!

Ebenso verstehe ich den Reiz  mittels simpler Verknuepfungslogik grosse Gedankenkonstrukte zu  implementieren. Aber von Eventbearbeitung war bei mir nicht die Rede. -  Im Gegenteil: Die klassische zyklische Bearbeitung laesst sich auch  mittels der Objektorientierten Architektur realisieren. Ein Ablauf waere  dann ein Thread von Vielen. Den Vorteil, einen einzelnen Prozess der  nach dem zyklischen Dogma bearbeitet wird, kann ich bei dem heutigen  Stand der Technik leider nicht erkennen.

Ich wuerde mir wuenschen, wenn du ein Beispiel fuer die Behauptung: 
"Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang  einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine  klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik  deutlich besser." haettest. 
Die Programmierung mit "Events",  "Pipes", etc. ist in der Tat ein schwieriges Feld. Diese Schlagworte  treten aber eher im Zusammenhang mit GUI-Programmierung auf, und waren  (wie oben erwaehnt) nicht mein Thema. Einen Diskurs ueber Interrups,  Polling und DMA haette ich an dieser Stelle eher erwartet.

Ein  weites Feld sind auch die Programmiersprachen. Bei diesem Thema moechte  ich auch keinen Grabenkrieg ausloesen.  Was mir in diesem Zusammenhang  nur wichtig ist, ist zum einen die primaer fehlende  "Objektorientierbarkeit" von KOP/FUP/AWL/Graph, zum anderen  das fuer diese Techniken keine einheitliche Entwicklungsumgebung  existiert. Obwohl ich freimuetig zugebe, dass es mit TIA-Portal in die  richtige Richtung zeigt.

Gruss
Dieter


----------



## Ralle (15 August 2012)

Wenn ich eine SPS programmiere, dann will ich den Code, den ich implementiere, auch in der SPS laufen sehen. (ok, ist selbst bei Siemens nicht komplett so). Zumindest muß alles nachvollziehbar sein. Wenn man in große Programmiersysteme, wie MS-Visual u.ä. reinschaut, dann weiß man nicht mehr, was da wirklich zum Schluß im Prozess alles passiert, was also genau für ein Code generiert wird. Genauso geht es einem dann beim Debuggen, es gibt Fehler, die man kaum nachvollziehen kann. Ich zumindest will das in einer Steuerung nicht haben, weil bei Fehlfunktionen viel zerstört werden kann und ich für mein Programm die Verantwortung trage. Daher ziehe ich in jedem Falle die normale, einfache sequenzielle Programmabarbeitung der multi-irgendwas vor.


----------



## standroid (15 August 2012)

Hallo Michael.

Die Sicherheit von System dadurch zu  klassifizieren, dass es wahrscheinlich weniger kriminelle Energie mit  dem notwendigen Knowhow gibt als bei anderen Systemen, halte ich fuer  sehr Gefaehrlich! 

Es macht einen Unterschied, ob sich eine  10tonnen -Anlage sich unkontrolliert bewegt oder ob meine Emailkontakte  sich im freien Umlauf befinden. Die unkontrollierte Verbreitung von  Steuerung-Knowhow ist ebenfalls ein Schaden der sich auf die schon  existierende Anlage auswirkt. Meistens durch die Weiterverwendung von  Dritten, bedingt durch den Auftraggeber, indem er einen Auftrag neu  vergibt oder durch Spionage. - Gerne haette ich dazu genaue Zahlen, die  ich dann hier dargestellt haette.

Gruss 
Dieter


----------



## Markus Rupp (15 August 2012)

ist das sps-forum neuerdings als marktforschungs-spielplatz anerkannt?

Ich stimme Ralle völlig zu, was die Debugging-Fähigkeiten angeht.

Man kann mit lüftungsanlagen Gebäude zerstören und mit Kesselanlagen selbige abbrennen, hier sind Aspekte an Sicherheit gefordert, speziell im Maschinenbau sollte das Berücksichtigt werden, die eine echte PC-gestützte Cross-Compiler-Umgebung nicht bieten kann. Wenn ich also hergehe und auf Basis eines Betriebssystems welches per Definition ja nicht dafür konzipiert ist solche Aufgaben auszuführen anfange dann gehe ich damit als SI bzw. Dienstleister ein Risiko ein. Zudem ist die Marktakzeptanz hierfür viel ausschlaggebender als die mögliche Technik. Automobilhersteller wollen zum Beispiel gar nicht damit konfrontiert werden. Hier wird klar wert auf "bewährtes" gelegt.


----------



## standroid (15 August 2012)

Hallo Ralle.

Ich glaube deine Schilderung ist des Pudels Kern. - Die Angst davor, nicht mehr Latein sondern Englisch zu sprechen, um dann eventuell nicht verstanden zu werden.
Diese Angst halte ich auch fuer voellig begruendet, zumal sie real mit der Verantwortung ueber eine Anlage existiert. 
Die Uebersichtsgewinn steigt mit der Uebung. Keiner kann erwarten neue Umgebungen und Sprachen sofort zu durchdringen.

Ich kann aber mit einem Beispiel beweisen, dass sich der Blick ueber den Tellerrand lohnt. Bei deinem Szenario "Fehler", gibt es die Erungenschaft der "exceptions" bzw. "try/catch" in C++/Java/Python/...
(aus Wikipedia

try {     funktion1();     funktion2();    ... } catch (const std::invalid_argument &e) {     std::cerr << "Falsches Argument:"  << e.what() << std::endl; } catch (const std::range_error &e) {     std::cerr << "Ungültiger Bereich:" << e.what() << std::endl; } catch (...) {     std::cerr << "Sonstige Exception" << std::endl; }

... und lassen Fehler glassklar benennen und wiederfinden.

Gruss
Dieter


----------



## Markus Rupp (15 August 2012)

ich programmiere selbst tag täglich mit hochsprachen genau so wie mit spsen, und glaube mir das ein "catch ex" nicht das selbe ist wie die prüfung des eigentlichen codes, dein catch ex gibt laufzeit-fehler der anwendung zutück, hier reden wir allerdings davon die fehler eines prozesses, welche üblicherweise in einer logischen verkettung von aktorik zu sensorik steht im ursprungscode zu finden. das die sps die programmierte aufgabe wunschgemäß ausführt darf unter einhaltung der spezifikationen selbiger ja vorrausgesetzt werden. bei einem selbst geschriebenen programm in einer hochsprache sieht die welt anders aus, da man deutlich mehr damit beschäftigt ist die anwendung auf funktion zu überwachen, wie dein beispiel mit dem "catch ex" beweist


----------



## standroid (15 August 2012)

Hallo Rupp.

Ein Betriebsystem ist der Boden einer jeden EDV-Anlage. Auch einer SPS, selbst wenn man es nicht sieht und auch sonst nicht damit in Kontakt kommt. 
Zum Thema Verfuegbarkeit, welches meistens gleich gestellt wird zu den Begriffen: Altbewaehrtes oder Robustheit, moechte ich diesen diffusen Kritikpunkt gerne konkretisieren.
Jedes EDV-System ist zu einer Verfuegbarkeit von 99,9%  zu haben! Das kann also den Unterschied zwischen den System nicht ausmachen. 
Bei der Thematik gibt es aber die nicht zu unterschaetzenden Punkte: "Sicherheitskritischer Zustand" und "Wiederanlauf im Fehlerfall". Das sind in der Tat Dinge, die als Konzepte in der SPS bestehen. - Wobei man hier auch sehr viel "Kaputt-programmieren" kann.
Ich denke aber, das sich diese Erungenschaft in andere Systeme retten laesst. Stichworte: Echtzeitsysteme und Interrupts.

Gruss
Dieter


----------



## standroid (15 August 2012)

Einen sauberen Code zu schreiben ist hoechste Programmiererpflicht! Wer Mumpitz programmiert, dem kann auch das tollste System, egal in welcher Sprache, nicht belehren. Und das ein Programm die gewuenschte "Verknuepfung" von Sensoren und Aktoren ausfuehrt, sollte auch staendig gegeben sein. - Getreu dem Motto: "Computer machen keine Fehler."

Was spricht denn dagegen mein Programm auf die Funktionen hin zu ueberwachen? Ist dies doch mein primaeres Ziel, dass die Anlage nach meinen Funktionen agieren soll.

Richtig ist deine Klarstellung, das Exceptions nur waerend der Laufzeit geworfen werden. Welche das sind, kann aber immer noch der Programmierer definieren. Fehler sind auch meines Erachtens nur waerend der Laufzeit zu erkennen. Testen, testen und nochmal testen, sollte eine Selbstverstaendlichkeit sein, am besten an der realen (verbauten) Steuerung.
Das schoenste Programm nuetzt wenig, wenn es nur auf dem Schreibtisch liegt.


----------



## Blockmove (15 August 2012)

standroid schrieb:


> Ebenso verstehe ich den Reiz  mittels simpler Verknuepfungslogik grosse Gedankenkonstrukte zu  implementieren. Aber von Eventbearbeitung war bei mir nicht die Rede. -  Im Gegenteil: Die klassische zyklische Bearbeitung laesst sich auch  mittels der Objektorientierten Architektur realisieren. Ein Ablauf waere  dann ein Thread von Vielen. Den Vorteil, einen einzelnen Prozess der  nach dem zyklischen Dogma bearbeitet wird, kann ich bei dem heutigen  Stand der Technik leider nicht erkennen.
> 
> Ich wuerde mir wuenschen, wenn du ein Beispiel fuer die Behauptung:
> "Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang  einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine  klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik  deutlich besser." haettest.
> ...



Sorry, aber ich habe den Eindruck du wirfst hier mit Begriffen und BuzzWords um dich ohne die richtigen Funktionalitäten überhaupt zu kennen.

Gerade mit der einfachen zyklischen Bearbeitung spart man sich das ganze Theater mit Events, Pipes, Interrupts. Und diese Schlagworte sind eben nicht nur Bestandteil der GUI-Programmierung, sondern eben auch der Programmierung von Anlagen!

Wie handelst du lt. deinen Ideen z.B. das Erreichen eines Endlagenschalters oder das Umschalten einer Betriebsart?
Üblicherweise sind dies doch Events, die durch Interrupts ausgelöst werden, oder?
Wenn nicht, dann musst du den Zustand von IOs durch Polling ermitteln und dann aus den Zustandsänderungen Events erzeugen.
Wie geht es dann mit den Events weiter?
Zentraler Eventhandler, Messagequeue? Wie werden deine Objekte mit den notwendigen Zustandsinformationen versorgt?
Wie stellst du Verriegelungen sicher? Semaphoren? Dann aber schön auf Deadlocks achten!

Also ich bleibe dabei:
Die Funktion einer klassischen SPS ist für die Automatisierungstechnik besser geeignet.

Achja Stichwort: Objektorientierung:
Dies hat rein gar nichts mit der Arbeitsweise einer SPS zu tun.
Du kannst wunderbar KOP/FUP mit Obejektorientierung erweitern. Beckhoff und Codesys zeigen es.
Wo jetzt im SPS-Programm steht:


```
U E100.0
U M10.0
= A40.1

steht halt nachher:

U Spanner.Geschlossen
U Station1.Bearbeitungsfreigabe
= Vorschub.Ausfahren
```

Gruß
Dieter


----------



## LowLevelMahn (15 August 2012)

*Unterschied zwischen PC/Android + Hochsprachen und SPS + Sprachenwelt*

Was man nie vergessen darf bei allen diesen lustigen Vergleichen:

Wildes Szenario: Atomreaktor-Steuerung

SPS (wenn in Hardware):

lange Verfügbakeit der 100% kompatiblen Hardware (teilweise >10 Jahre) - ein Hardware-Austausch macht dort weit weniger Kopfschmerzen
klar definierte Bereichsgrenzen in Geschwindigkeit und Temperatur - Wie schnell kann sie - und geht das auch bei +65 Grad?
(soweit ich weiss) Harte Echtzeit - Wenn der Code die Zykluszeit überschreitet geht die SPS in Stop
die obigen Punkte sind nur sehr schwer für eine Android-Umgebung zu erreichen - einer der Hauptgründe warum SPSen immer noch so existieren

(zu Soft-SPS: die Beckhoff-Leute haben ihre Industrie-PCs mit Verfügbarkeit usw. und Echtzeit in ihrem Softwarekern)

Programmiersprachen

Die fehlenenden Möglichkeiten in der SPS-Programmierumgebung führen (im Normalfall) zu einfacheren Programmen - die starken Einschränkungen erlauben
nur eine sehr dezidiert Behandlung der Anforderungen. Damit ist ein SPS-Programm in vielen Fällen per-se laufzeitstabiler als jedes Hochsprachenprogramm auf Basis von C,C++,Java oder auch C#

(Beckhoff kann auch C++ in TwinCat 3 - aber man kommt damit nicht aus dem Kern raus und kann nicht wild Win32, Datenbanken und sonstiges anzapfen)

Ich selbst bin kein SPS-Programmierer - viele Jahre C++ im Steuerungsbereich, Embdedded-Entwicklungs usw. - auch Java und C# - also Fehler zu SPS Aussagen bitte korrigieren


----------



## IBFS (15 August 2012)

standroid schrieb:


> Ich kann aber mit einem Beispiel beweisen, dass sich der Blick ueber den Tellerrand lohnt. Bei deinem Szenario "Fehler", gibt es die Erungenschaft der "exceptions" bzw. "try/catch" in C++/Java/Python/...
> (aus Wikipedia
> 
> try {     funktion1();     funktion2();    ... } catch (const std::invalid_argument &e) {     std::cerr << "Falsches Argument:"  << e.what() << std::endl; } catch (const std::range_error &e) {     std::cerr << "Ungültiger Bereich:" << e.what() << std::endl; } catch (...) {     std::cerr << "Sonstige Exception" << std::endl; }
> ...



Wenn ich das alles so lese, dann kann ich mir nicht vorstellen, das du jemals eine größere SPS-gesteuerte Anlage mit 500 - 1000 EAs programmiert hast.

Bei der SPS-Programmierung ist ONLINE-Beobachtbarkeit voin Schrittketten, Vernüpfungen usw. oberste Plicht.

Zeige mir bitte ein Projekt in deinem EVENT-Stile z.B. einen Rundschalttisch mit zwanzig Station und fünfzehn elektischen Achse, Messegeräten usw. 

Gutes Gelingen.

Frank


----------



## Ralle (15 August 2012)

standroid schrieb:


> Hallo Ralle.
> 
> Ich glaube deine Schilderung ist des Pudels Kern. - Die Angst davor, nicht mehr Latein sondern Englisch zu sprechen, um dann eventuell nicht verstanden zu werden.
> Diese Angst halte ich auch fuer voellig begruendet, zumal sie real mit der Verantwortung ueber eine Anlage existiert.
> ...



Ich hab nun auch viele Jahre lang SPS und u.a. Delphi unter Windows programmiert. Mit Delphi und libnodave hab ich eine Maschinendatenerfassung programmiert. Kleine Änderungen am Delphicode konnten große Auswirkungen haben, die ich vorher nicht einmal erahnen konnte, bis hin zu Komplettabstürzen des PC, man mußte Speicher reservieren, wieder freigeben, umkopieren usw. Sicher hab ich da nicht sauber programmiert denke ich, aber es ist wie immer, was geht wird auch gemacht und was nicht getestet ist funktioniert auch nicht. Daher sind gewisse Beschränkungen nicht immer nur ein Mangel und um meine Maschinen zu steuern fehlte mit bisher nichts.


----------



## rostiger Nagel (15 August 2012)

nicht umsonst halten die IPC Hersteller ihre Betriebssyteme ganz flach und weisen
extra darauf hin am besten so wenig wie möglich darauf zu installieren. 
Ich stelle mir mal gerade vor wenn so ein Virus mal das Android BS befällt, dann heißt
es nicht mehr in der Endlage Stop, sondern freie Fahrt.


----------



## Licht9885 (15 August 2012)

So wie ich das bisher verstanden habe nützt das eh nichts was wir hier vorbringen er möchte seine Feldstudie oder was auch immer es sonst sein soll durchführen ist okay lassen wir ihn. 
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.


----------



## IBFS (15 August 2012)

Licht9885 schrieb:


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



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


----------



## Blockmove (15 August 2012)

Licht9885 schrieb:


> 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 

Gruß
Dieter


----------



## Licht9885 (15 August 2012)

IBFS schrieb:


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



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


----------



## standroid (15 August 2012)

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


----------



## Blockmove (15 August 2012)

standroid schrieb:


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


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


----------



## trinitaucher (17 August 2012)

standroid schrieb:


> 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 ?*


----------



## standroid (17 August 2012)

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.


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


----------



## standroid (17 August 2012)

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


----------



## repök (17 August 2012)

standroid schrieb:


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



standroid schrieb:


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



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.


----------



## trinitaucher (17 August 2012)

standroid schrieb:


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


----------



## Blockmove (17 August 2012)

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


----------



## Blockmove (17 August 2012)

Achja Echtzeitfähigkeit:
Eigentlich ist Android "nur" ein Aufsatz auf einem Linux-Kernel. Und für Linux gibt es Kernelerweiterungen für harte Echtzeit.

Gruß
Dieter


----------



## Markus Rupp (17 August 2012)

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.


----------



## repök (17 August 2012)

Blockmove schrieb:


> Achja Echtzeitfähigkeit:
> Eigentlich ist Android "nur" ein Aufsatz auf einem Linux-Kernel. Und für Linux gibt es Kernelerweiterungen für harte Echtzeit.
> 
> Gruß
> Dieter



und wieder was gelernt....


----------



## Blockmove (17 August 2012)

Rupp schrieb:


> 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


----------



## Thomas_v2.1 (17 August 2012)

Blockmove schrieb:


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


----------



## martin1988 (17 August 2012)

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!


----------



## Blockmove (17 August 2012)

martin1988 schrieb:


> 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


----------



## martin1988 (17 August 2012)

Blockmove schrieb:


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



Oh, okay.
Dann hab ich nichts gesagt.


----------



## Markus Rupp (18 August 2012)

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


----------



## Blockmove (18 August 2012)

Rupp schrieb:


> 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


----------



## Markus Rupp (18 August 2012)

ich schliesse mich dem jetzt einfach mal geschlossen an.


----------



## Markus Rupp (18 August 2012)

Und ob ein Sysystem jetzt Event-orientiert oder zyklisch arbeitet ist reel Betrachtet gar nicht so wichtig.

Egal was man wie programmiert (und der vorteil bei zyklischer abarbeitung ist ebend das es sich ergibt) ist eine konstante und vorhersehbare CPU-Auslastung welche sich bei Regelungen ebend in Berechnungs-Zyklen bzw. bei Maschinen in Takte gliedert. Wie dies zu erreichen ist, ist doch im Kern als subjektives Wunschdenken zu betrachten.

Im Gegensatz zum echten leben zählt bei solchen Dingen doch in erster Linie das Ergebniss. Der Weg ist so vielfältig das es mühsig ist, "denn Weg", welchen es ebend nicht gibt, zu suchen.

Denn sogar in der boolschen Welt gibt es nicht nur 1 und 0, es gibt auch etwas dazwischen.

[OFFTOPIC]
So philosophisch sollte das jetzt gar nicht werden ;-)
[/OFFTOPIC]


----------



## Blockmove (18 August 2012)

Rupp schrieb:


> Denn sogar in der boolschen Welt gibt es nicht nur 1 und 0, es gibt auch etwas dazwischen.



Eben es gibt 10 Sorten Menschen:
Die die es verstehen und die die es nicht verstehen

Gruß
Dieter


----------



## standroid (18 August 2012)

Schoen, das die Diskussion weg vom Bashing geht und ihr auch einige positive Aspekte anerkennt. 
Vielleicht  bastel ich zu viel und deswegen liegt mir das naeher; aber gerade die  "guenstigen Gadgeds" habe ich oefters in den Haenden und kann ihnen mehr  brauchbares abgewinnen, als dem WinFlexMaster5000 fuer Fantastillionen  Scheine, wo ich mich auf blumiges Marketingsprech einlassen muss.
Diese Ansicht muss nicht jeder teilen.

Bis hierhin danke ich trotzdem allen Kommentatoren zu diesem Thema. Zwei / drei Dinge konnte ich schon mitnehmen.

Gruss
Dieter


----------



## Blockmove (18 August 2012)

standroid schrieb:


> Vielleicht  bastel ich zu viel und deswegen liegt mir das naeher; aber gerade die  "guenstigen Gadgeds" habe ich oefters in den Haenden und kann ihnen mehr  brauchbares abgewinnen, als dem WinFlexMaster5000 fuer Fantastillionen  Scheine, wo ich mich auf blumiges Marketingsprech einlassen muss.
> Diese Ansicht muss nicht jeder teilen.



Diese Ansicht teile ich mit dir.
Und da man ja SPS heute eigentlich nicht mehr lösgelöst von der Visualisierung / HMI betrachten kann, wäre es doch schon mal ein Einstieg, wenn du eine schöne Visualisierung für Android schreiben würdest.
Bislang ist der Markt da noch recht überschaubar und die wenigen verfügbaren Lösungen sind meist nicht für den professionellen Einsatz geeignet.

Gruß
Dieter


----------



## Flux (11 Januar 2015)

Blockmove schrieb:


> 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



Dann schau dir mal Comos von Siemens an. Es zielt darauf ab EINE gemeinsame Datenhaltung zu pflegen,  die immer konsistent und aktuell ist. Je nach dem welchen Editor du wählst, erhältst du eine andere Perspektive auf die Anlage (Geographie (ggf. 3D),  Prozessmodellierung, R&Is, elektrische Installationen, CFCs,...). Multiuser-fähig dank Server-Client-Architektur. Miner Meinung nach der richtige Ansatz, es steckt allerdings noch in den Kinderschuhen.

http://w3.siemens.com/mcms/plant-engineering-software/en/comos-overview/Pages/Default.aspx


----------



## IBFS (11 Januar 2015)

Flux schrieb:


> Dann schau dir mal Comos von Siemens an. ...... Meiner Meinung nach der richtige Ansatz, es steckt allerdings noch in den Kinderschuhen.



Für Firmen die Inhouse Serienmaschinen entwickeln und die über eine ordentliche IT-Truppe und genug Geld verfügen, mag das gut (und teuer) sein.
Für die breite Masse die nicht erst jede Schraube in die Datenhaltung einpflegen können um etwas danach überhaupt machen zu können schlicht 
unbrauchbar überzogen und unflexibel.  Ich habe mir vor Jahren mal einen Vortrag darüber angehört .. klingt gut, ist aber fern der realen Praxis.


----------



## pvbrowser (11 Januar 2015)

Android tablets/phones sehe ich eher als HMI displays an,
die als client an einem Visualisierungsserver hängen.
(Der Produktzyklus der Dinger ist viel zu schnell für die Automation)

Im Schaltschrank kann man dann einen embedded Server (Hutschinenmontage) haben,
auf dem der Visualisierungsserver läuft (siehe: http://pvbrowser.org ,den Client gibt es für Android) .

Wenn dieser embedded Server noch Ressourcen frei hat,
kann er evtl. eine separate SPS überflüssig machen.
Es reichen unter Umständen die vorhandenen GPIOs oder man hängt z.B. Modbus da dran.


----------

