# Wie seht ihr die C und C++ Programmierung gegenüber der IEC?



## DJchris81 (24 Dezember 2009)

Hallo zusammen

Vielleicht könnt ihr mal eure Erfahrungen aus der AT mit C oder Visonen zum neuen TwinCAT 3 posten.

Scheinbar läutet Beckhoff wieder eine "kleine" Revolution in der AT ein.

Siehe Video mit Herrn Beckhoff

http://www.computer-automation.de/n...me/22762/ae3fddee-c9ff-11de-be92-001ec9efd5b0

Gruß


----------



## zotos (24 Dezember 2009)

Ich bin überzeugter IEC61131 Fan. Gerade die Mischung der IEC Sprachen stellt für mich einen riesigen Vorteil dar. Grafische Schrittketten (AS) und grafische Bitverknüpfungen (KOP/FUP/CFC) so wie Text basierendes Datenhändling und Rechenaufgaben (ST/AWL). Nach dem der Schritt nun auch noch hin zur Objektorientierung hingeht sehe ich da auch viel Potential.

Klar bietet C/C++ ein breites Spektrum an Möglichkeiten und auch viele Programmierer beherrschen diese Sprache bereits. Für mich stellt sich jedoch die Frage wenn jemand so gut in C/C++ ist das man ihn auf eine Produktionsanlage los lässt dann sollte man von ihm auch erwarten können das er mit der IEC61131 klar kommt. Branchen spezifische Programmiersprachen gab es schon immer und einige Firmen erfinden sogar ihre eigenen Sprachen (z.B. SAP mit ABAB). Gerade die grafischen Darstellungen von Programminhalten haben IMHO Vorteile z.B. bei Schrittketten. Auch Datenflussmodelle wie bei Labview haben ihre Vorzüge. 

Wenn man Maschinen und Anlagen nur in C/C++ Programmieren will halte ich das für einen Rückschritt das mag eine Revolution sein aber in die falsche Richtung wenn man gewisse Bestandteile besser in C/C++ lösen kann und die optional einsetzt mag es eine Bereicherung sein.

Egal wie ich die Sache heute sehe, wenn mein Chef eines Tages kommt und mir sagt das ab heute C/C++ das Maß aller Dinge ist werde ich die Maschinen eben in C/C++ programmieren.


----------



## Bührer (24 Dezember 2009)

IEC für einmalige Anlagen oder für einfache Anlagen die nicht gross ändern.

C und C++ für komplexe Anlagen und sehr stark ändernde Anlagen.

Für mich kann kein grafische Programmierung je an eine Text basierende Lösung ran kommen. Mit der Text basierten Lösung kann man mehr machen. Dafür ist die Grafische verständlicher für die meisten Menschen.

Gruss
Thomas


----------



## drfunfrock (24 Dezember 2009)

Anscheinend wird Twincat 3 mit der Sprache C,  Code für die Runtime-Engine generieren können. Das Marketing-Argument dafür ist, dass es mehr C-Programmierer gibt, als Automatisierungsings. Das ist soweit wahr. Realistisch gesehen, wird wohl die Hürde kleiner sein, sich mal mit TwinCat zu beschäftigen, aber die eigentlichen Hürden wie die quasi-parallele Ausführung von Programmteilen sind damit natürlich nicht genommen. Das macht aber auch nichts. Die Anforderungen an den Automatisierer werden nicht kleiner. 

Beckhoff versucht offenbar aus der Spezialistenecke herauszukommen, indem TW allen mit Visual Studio zugänglich gemacht wird und sprach im Interview speziell China an. Die Hürden für den Einsatz des Produktes werden kleiner. Dort ist der Markt riesengross und je einfach man es man dem Kunden mit dem ersten Schritt macht, desto besser wird Beckhoff später seine Anteile am Markt holen können.


----------



## DJchris81 (24 Dezember 2009)

Danke für eure ersten Antworten.

ich find es absolut reizvoll, dass man IEC und C parallel fahren kann.
Somit können die Bestandsanlagen und "normalen" Anlagen weiter in der IEC programmiert werden und zu gleich können alle unlösbaren Programmteile z.B. dynamische FBs bzw. Objekte in C umgesetzt werden.

Den Schritt zu Visual Studio ist sicherlich auch genial. Somit können die Scadas und HMIs mit einem Editor bearbeitet werden. Und welcher heutige fertigwerdende Ing. oder Techniker hatte noch keinen Kontakt zum VStudio?

Ich könnte mir auch vorstellen, dass ähnlich wie im SystemManager die verschiedenen Hardwarekommunikation einfach gelöst sind, die Kommunikation zwischen den verschieden Softwaresprachen gehandelt werden könnte. (Webservice, OCX, etc.)

Gruß, Frohe Weihnachten


----------



## Blockmove (24 Dezember 2009)

Eigentlich ist es der falsche Ansatz!
Warum C und C++ Programmierung *gegenüber *der IEC?

IEC beinhaltet mehrere Sprachen. C++ könnte einfach eine weitere sein.
Ich vertrete ganz einfach die Auffassung, dass die Aufgabe und die Sprache zusammen passen müssen.
Eine Schrittkette kann ich in jeder Sprache programmieren, aber grafisch ist es nun mal einfachsten und am übersichtlichsten.
Eine Lagerwaltung kann ich auch in FUP programmieren, aber hier wäre C++ einfach geeigneter.

Just my 2Cents

Gruß
Dieter


----------



## Neals (24 Dezember 2009)

Zum Thema, es gibt ja so viele C-Programmierer:

Man muss sich trotzdem vor Augen halten, dass C nicht zur Programmierung von SPS'en entwickelt wurde. Mit C++ ist es noch einfacher möglich, schwerwiegende Fehler zu programmieren.

Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt. Auf einer SPS wird das Programm alle x ms neu gestartet. Das ist einem normalem Ing nicht bewusst! Zumindest weiß er nicht, solch ein Programm zu entwickeln.

Ein normaler Kommunikationsaufruf, Zugriff auf die Festplatte oder ähnliches kann zu schweren Fehlern führen und die x ms deutlich überschreiten. Das wäre ein arges Problem, wenn das Programm auf einer Anlage läuft.


----------



## drfunfrock (24 Dezember 2009)

Neals schrieb:


> Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt.



Sicher nicht. Das Problem kann man aber auch mit ST produzieren (mir schon passiert), auch wenn man Experte ist. Dummerweise reagierte Twincat bisher mit einem Bustimeout auf Ethercat oder z.B. Profibus. Da fängt dann der Ärger für den Anfänger so richtig an. 

Ob man C oder ST oder sonstwas auch immer nimmt, der Fortbildungsbedarf ist immer da. Die Programmiersprache sollte immer von der Anwendung abhängen. Ich sehe keinen wesentlichen Unterschied zwischen dem Pascal-Abkömling ST und C. Es wird viel interessanter, wie das umgesetzt wird.


----------



## RobiHerb (24 Dezember 2009)

*Naja, sagen wir mal, man lernt nie aus*



Neals schrieb:


> Zum Thema, es gibt ja so viele C-Programmierer:
> 
> Man muss sich trotzdem vor Augen halten, dass C nicht zur Programmierung von SPS'en entwickelt wurde. Mit C++ ist es noch einfacher möglich, schwerwiegende Fehler zu programmieren.



C ist schon lange tot, ich wage aber die Behauptung, dass die meisten heute eingesetzten SPS per C++ überhaupt erst entwickelt worden sind.



Neals schrieb:


> Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt. Auf einer SPS wird das Programm alle x ms neu gestartet. Das ist einem normalem Ing nicht bewusst! Zumindest weiß er nicht, solch ein Programm zu entwickeln.



Ich denke mal auch einem SPS Programmierer fehlt gelegentlich der Überblick, wie komplexe professionelle Programme geschrieben werden. Dagegen sind die zyklisch periodischen Tasks der SPS noch Spielen im Sandkasten. In einem grösseren technischen Programm laufen eine Menge von Threads und Prozessen, die synchronisieren sich gegenseitig, die können auf Ereignisse warten an bestimmten Punkten, die können wieder neue Tasks und Threads starten, die können einzelne Aufgaben auf bestimmte Prozessor Kerne auslagern etc...


----------



## trinitaucher (25 Dezember 2009)

Wenn man bedenkt, dass Beckhoff gerade stärker in den Bereich "Scientific Automation" und Messtechnik hinein möchte, wofür sie schon E/A-Komponenten ("XfC") und Software haben (z. B. "Condition Monitoring"), dann ist die Einbindung von weiteren Sprogrammiersprachen wie C/C++ ja nur der logische Schritt.
Für uns Steuerungs-Programmierer klingt es vielleicht komisch, dass wir nun auch C/C++ für die SPS nutzen können/sollen, aber denkt mal an die Kollegen aus der Messtechnik oder an Entwickler aus dem Forschungs-Bereich.
Die haben eher wenige Kenntnisse in Sachen IEC61131. Und wenn die nun plötzlich "herkömmliche" SPSen, statt sündhaft teuren und aufwendig zusammengestelltes Labor-Steuerungen nutzen können, kann das für die plötzlich ein richtiger Segen sein, wenn die direkt Teile von z.B. Messprogrammen 1:1 weiter nutzen können. Es wurde auf der Messe ja auch von Einbindung von Matlab/Simulnk gesprochen. Mit Simulink kann man z.B. komplizierteste Regelkreise grafisch erstellen und bekommt später C-Code raus. Diesen könnte man direkt ins TwinCAT 3 packen und braucht dann keine teuer Realtime-Hardware mehr.
Ich weiß noch aus meinem Studium, wo man krampfhaft versuchte, einen im Labor´entwickelten Regelkreis mit Spezial-PC-Hardware als "Echtzeit"-Programm ablaufen zu lassen... und dann brauchte man noch I/O-Karten usw. ... für sowas gibt's spezialisierte Hersteller, die sich das auch fürstlich bezahlen lassen.
... und bald könnten dann "Rapid Prototyping" und "Hardware in The Loop" -Simulationen (HIL-Simulation) in "Standard-SPSen" laufen.... 

.. wir reden dann nicht mehr von unseren bekannten Anwendungsfällen wie der Anlagen- und Maschinenprogrammierung.
Ich denke schon dass hier ein risieger Markt exisitert, den wir aber gar nicht kennen.


----------



## drfunfrock (26 Dezember 2009)

trinitaucher schrieb:


> .. wir reden dann nicht mehr von unseren bekannten Anwendungsfällen wie der Anlagen- und Maschinenprogrammierung.
> Ich denke schon dass hier ein risieger Markt exisitert, den wir aber gar nicht kennen.



Bei uns werden z.B. die Steuerungsschränke mit Octave (Opensource Matlab-Ersatz) kalibriert. Wir haben massenhaft Messgeräte, die mit Gpib angesteuert werden, für das es bis Heute bei Beckhoff nichts gibt. Es gibt im Bereich der Messgeräte standadisierte Ethernetprotokoll, so dass auch diese genutzt werden könnten. 

Bis Heute werden an vielen Unis für Realtime FPGAs oder DSPs eingesetzt. Die Zeit vom Entwurf bis zum Betrieb ist dementsprechend gross. Da könnte ein C-Interface zu externen Geräten  gewaltig helfen. 

Doch Beckhoff meint etwas anderes mit C. Die wollen ihren Bytecode nicht nur mit ST oder FUP erzeugen können, sondern mit C oder C++. Das ist etwas grundlegend anderes. Oder habe ich das falsch verstanden?


----------



## MasterOhh (26 Dezember 2009)

Ich glaube auch das man C++ für die "herkömmlichen" Automatisierungsaufgaben nicht unbedingt braucht. Immerhin bekommt man im Studium beigepaukt wie man komplexe Systeme auf so kleine Teilschritte runterbrechen kann, das man da locker mit ST, AS, AWL, FUP auskommt um sie zu realisieren. 

Die Erweiterung macht aber Sinn, wenn Beckhoff wirklich das Einsatzportfolio ihrer Steuerungen auf Bereiche außerhalb der traditionellen SPS Domänen ausbreiten will.

Ich glaube hier in Deutschland werden wenige Automatisierer auf diese neuen Möglichkeiten zurückgreifen. 
Hier regiert leider immernoch Siemens (wie ich auch in meinem Studium scherzhaft feststellen muss), und da bewegt sich erfahrunggemäß so schnell nichts.


----------



## KGU (7 Januar 2010)

drfunfrock schrieb:


> Bis Heute werden an vielen Unis für Realtime FPGAs oder DSPs eingesetzt. Die Zeit vom Entwurf bis zum Betrieb ist dementsprechend gross. Da könnte ein C-Interface zu externen Geräten gewaltig helfen.
> 
> Doch Beckhoff meint etwas anderes mit C. Die wollen ihren Bytecode nicht nur mit ST oder FUP erzeugen können, sondern mit C oder C++. Das ist etwas grundlegend anderes. Oder habe ich das falsch verstanden?


 
Beckhoff hat eine neue modulare Runtime. Diese stellt eine Umgebung zur Verfügung, in welcher TwinCAT Module ablaufen können. Diese Module können "SPSen", C/C++-Module, Motion Control-Module, in Matlab/Simulink oder C/C++ generierte Regler usw. sein. Die Funktionalität der Module ist somit frei skalierbar. Diese Module können über diese Schnittstellen zyklisch aufgerufen werden, sich gegenseitig aufrufen (z.B. als Funktionsbausteine), Daten austauschen usw. Ebenso kann man damit auch eine Anbindung an externe Geräte programmieren, welche dann echtzeitfähig mit anderen Modulen Daten austauschen können.


----------



## Blockmove (7 Januar 2010)

MasterOhh schrieb:


> Ich glaube auch das man C++ für die "herkömmlichen" Automatisierungsaufgaben nicht unbedingt braucht. Immerhin bekommt man im Studium beigepaukt wie man komplexe Systeme auf so kleine Teilschritte runterbrechen kann, das man da locker mit ST, AS, AWL, FUP auskommt um sie zu realisieren.
> 
> Die Erweiterung macht aber Sinn, wenn Beckhoff wirklich das Einsatzportfolio ihrer Steuerungen auf Bereiche außerhalb der traditionellen SPS Domänen ausbreiten will.
> 
> ...



C braucht sicherlich niemand in der AT. Mit C++ oder besser gesagt Objekt-Orientierung sieht es schon anders aus. Wenn du siehst welche Aufgaben heute mit einer SPS erledigt werden (müssen), da wäre es manchmal schon hilfreich, wenn du mit Objekten arbeiten könntest.
Wenn du Siemens genügend Geld gibst, dann kannst du auch schon heute S7 in C programmieren. Es gibt eine Art SDK mit dem du dann quasi deine eigenen Betriebssystem-Erweiterungen und -Funktionen für S7 schreiben kannst.

Gruß
Dieter


----------



## Rainer Hönle (8 Januar 2010)

Blockmove schrieb:


> Wenn du Siemens genügend Geld gibst, dann kannst du auch schon heute S7 in C programmieren. Es gibt eine Art SDK mit dem du dann quasi deine eigenen Betriebssystem-Erweiterungen und -Funktionen für S7 schreiben kannst.



Hast Du dazu weitere Infos oder einen Link?


----------



## rostiger Nagel (8 Januar 2010)

Rainer Hönle schrieb:


> Hast Du dazu weitere Infos oder einen Link?


 
Ich meine das geht nur mit den Soft-SPS'n, da wird der Baustein in 
hochsprache geschrieben und kann dann in das Step 7 projekt 
eingebunden werden. http://support.automation.siemens.c...us&objaction=cssearch&searchinprim=&nodeid99==


----------



## Bernard (8 Januar 2010)

*Hast Du dazu weitere Infos*

Es gibt für die soft-SPS Winac-RTX ein Open develepment Kit (ODK)  aktuelle Version 4.2.

ODK ist leider nicht umsonst

Anbei einen Link
http://support.automation.siemens.c...earch&searchinprim=0&nodeid0=10805055&x=0&y=0


----------



## Rainer Hönle (8 Januar 2010)

Das ODK kenne ich, ich dachte da gibt es was für die Hardware-SPSen.


----------



## vierlagig (8 Januar 2010)

Helmut_von_der_Reparatur schrieb:


> Ich meine das geht nur mit den Soft-SPS'n, da wird der Baustein in
> hochsprache geschrieben und kann dann in das Step 7 projekt
> eingebunden werden.



die leider abgekündigte M7 konnte das im schaltschrank, als 300er oder 400er baugruppe...


----------



## rostiger Nagel (8 Januar 2010)

vierlagig schrieb:


> die leider abgekündigte M7 konnte das im schaltschrank, als 300er oder 400er baugruppe...


 
dafür gibt es ja ersatz, die S7 - mEC http://www.automation.siemens.com/m...odular-embedded-controller/Pages/Default.aspx


----------



## vierlagig (8 Januar 2010)

Helmut_von_der_Reparatur schrieb:


> dafür gibt es ja ersatz, die S7 - mEC http://www.automation.siemens.com/m...odular-embedded-controller/Pages/Default.aspx



aber nur 300er ... das ist mal wieder nicht zu ende gedacht, der siemens-weg eben.

kennt einer einen, der einen kennt, der das ding mal irgendwo verbaut gesehen hat oder gar selber eingebaut hat?


----------



## rostiger Nagel (8 Januar 2010)

ich hab das ding mal in der Hand gehalten, setze aber nur die 
Panel bzw. Box PC von Siemens ein. Die eMC entspricht diesen geräten,
nur in ein anderen Gehäuse. 
Mit der Soft SPS von siemens bin ich sehr zufrieden, kann ich nichts
schlechtes darüber sagen.


----------



## Blockmove (8 Januar 2010)

Rainer Hönle schrieb:


> Das ODK kenne ich, ich dachte da gibt es was für die Hardware-SPSen.


Gibt es auch.
Aber nicht auf den normalen Vertriebswegen. 

Gruß
Dieter


----------



## RobiHerb (9 Januar 2010)

vierlagig schrieb:


> aber nur 300er ... das ist mal wieder nicht zu ende gedacht, der siemens-weg eben.
> 
> kennt einer einen, der einen kennt, der das ding mal irgendwo verbaut gesehen hat oder gar selber eingebaut hat?



Einmal so ein Ding im Projekt eingesetzt, das gute Stück produziert heute Tür und Fenster Griffe in Italien. 

Den Vorteil hat allerdings keiner mir erklären können. Eine Trennung PC und SPS ist bestimmt preiswerter und trennt auch die Verantwortlichkeiten zwischen PC Software und SPS klar.


----------



## rostiger Nagel (9 Januar 2010)

RobiHerb schrieb:


> Einmal so ein Ding im Projekt eingesetzt, das gute Stück produziert heute Tür und Fenster Griffe in Italien.
> 
> Den Vorteil hat allerdings keiner mir erklären können. Eine Trennung PC und SPS ist bestimmt preiswerter und trennt auch die Verantwortlichkeiten zwischen PC Software und SPS klar.


 
Dem kann ich nicht zustimmen, wenn wir jetzt z.b. mal bei Simens bleiben
sind die Soft-SPS'en das schnellste was Siemens zur Zeit hat. Die kleinen
also die PC's 427 bzw. 477 schlagen die große 400er SPS um längen, 
Siemens spricht von von faktor 10.
Wenn jetzt zusätzlich noch die HMI darauf läuft wird es auch noch wirklich
preiswert, im vergleich z.b. 317 bzw 319 mit MP377 geht das schon in
die 1000€ bis 2000€. Ein OPC server ist dann beim PC-Bundel auch immer
dabei. Mann kann dann mal schnell eine PC Aplikation mit auf dem PC
laufen lassen, wo sonst noch ein zusätzlicher PC erforderlich war.
Dadurch das alles auf einer Plattform läuft wird der Bus entlastet und
die Bedienung der HMI ist wirklich perfomant.

Wenn mann sich die zuwachsraten der Fa. Beckhoff anschaut scheint
die PC plattform eigentlich mehr die zukunft zu sein,


----------



## Chräshe (9 Januar 2010)

Hallo allerseits,


Helmut_von_der_Reparatur schrieb:


> Wenn mann sich die zuwachsraten der Fa. Beckhoff anschaut scheint
> die PC plattform eigentlich mehr die zukunft zu sein,


anscheinend hat auch Siemens bemerkt, dass es sowas wie Konkurrenz geben kann... 

Zurück zur ursprünglichen Frage:


DJchris81 schrieb:


> Vielleicht könnt ihr mal eure Erfahrungen aus der AT mit C oder Visonen zum neuen TwinCAT 3 posten.



Für Erfahrungen mit „TwinCAT 3" muss die Software erst freigegeben werden und entsprechende Hardware unterstützen. Meine Befürchtung ist, dass es anfangs abläuft wie bei Siemens mit WinCC. Das war auch eine Revolution *ROFL*

Was mich interessiert –> arbeitet „TwinCAT 3" dann mit „CoDeSys V3“?

Dazu konnte ich in den seitenlangen Diskussionen noch nichts finden...

Gruß
Chräshe


----------



## trinitaucher (9 Januar 2010)

RobiHerb schrieb:


> Den Vorteil hat allerdings keiner mir erklären können. Eine Trennung PC und SPS ist bestimmt preiswerter und trennt auch die Verantwortlichkeiten zwischen PC Software und SPS klar.





Helmut_von_der_Reparatur schrieb:


> Wenn mann sich die zuwachsraten der Fa. Beckhoff anschaut scheint
> die PC plattform eigentlich mehr die zukunft zu sein,


Ich sehe auch ganz klar den Trend in Richtung PC-basierte Steuerungen gehen.
Bei der Menge an Zusatzfunktionalitäten, die neben der SPS benötigt wird, ist es an der Zeit, die SPS in den PC zu holen oder umgekehrt, die Zusatzfunktionalitäten, die bisher der externe PC erledigte, von der PC-basierten Steuerung erledigen zu lassen.

Beckhoff will durch die bessere Einbindung von Hochsprachen diesem Trend noch mehr Schub verleihen, denke ich.

... Siemens hat das ganz klar verpennt, bzw. tut sich auch generell schwer dabei, den PC als Steuerungselement zu begreifen.
Schaut euch doch nur mal die "Automatisierungspyramide" oder die ganzen Grafiken von Siemens an. Da wird der PC immer noch fast ausschließlich in der Leitebene gesehen.


----------



## bike (9 Januar 2010)

trinitaucher schrieb:


> Ich sehe auch ganz klar den Trend in Richtung PC-basierte Steuerungen gehen.
> Bei der Menge an Zusatzfunktionalitäten, die neben der SPS benötigt wird, ist es an der Zeit, die SPS in den PC zu holen oder umgekehrt, die Zusatzfunktionalitäten, die bisher der externe PC erledigte, von der PC-basierten Steuerung erledigen zu lassen.


Bevor solche Thesen diskutiert werden, sollte geklärt sein wohin geht der "PC"?
Verpennt hat Siemens eigentlich nichts. Sie betreiben eben ihr Linie, ohne wenn und aber. Das macht es für den Anwender einfacher, da er nicht jedes Jahr eine neue, und ich mein neue, keine geänderte oder fehlerbereinigte Entwicklungsumgebung hat. 
Die Fälle von speziellen Funktionen die angesprochen wurden, kann auch mit den Bordmitteln von Siemens meist geleistet werde.
Wir haben zur Zeit die Freude mit Siemens 840SI zu spielen. Eine NC mit PLC und zusätzlich ein linux embbeded für das drum rum.
Ich glaube nicht, dass solche eierlegende Wollmilchsäue notwendig sind und von den Entwicklern und Anwendern beherschbar sind.

Meine These ist eigentlich ganz einfach:
NC soll fahren, das kann die am besten.
PlC soll steuern, dafür ist die geschaffen 
und PC oder wie das sonst genannt wird für Visualisierung und Daten oder der gleichen verwendet.



bike


----------



## trinitaucher (10 Januar 2010)

bike schrieb:


> Ich glaube nicht, dass solche eierlegende Wollmilchsäue notwendig sind und von den Entwicklern und Anwendern beherschbar sind.


Ich habe sehr früh die Beckhoff-Steuerungen kennen gelernt und davor nur wenig Kontakt mit den Systemen von Siemens (und Phoenix und Scheider) gehabt.
Die PC-basierten Systeme, im Falle von Beckhoff, sind ja kein Hexenwerk. Wer nur die PLC braucht, der nutzt auch nur die. Das Handling hinsichtlich Programmierung und Konfiguration ist nicht anders oder aufwendiger, als die Systeme anderer Hersteller.

Nur dass im Hintergrund halt eine extrem Leistungsfähige CPU werkelt, der man bei Bedarf noch zig Zusatzaufgaben erledigen kann. Das alles unter der bekannten Windows-Umgebung.
Da ist es halt sehr einfach, für die SPS noch schnell mal einen Webserver einzurichten oder ne Datenarchivierung oder Rezepturverwaltung als .csv-Datei für Excel zu erstellen.
... und das sind alles Dinge, die der PC mit dem Betriebssystem kostenlos mitbringt ... kein Hexenwerk.

... wenn ich heute nochmal Siemens programmieren müsste, würde ich sehr viel an Funktionalität und Komfort vermiseen, glaube ich.



bike schrieb:


> Meine These ist eigentlich ganz einfach:
> NC soll fahren, das kann die am besten.
> PlC soll steuern, dafür ist die geschaffen
> und PC oder wie das sonst genannt wird für Visualisierung und Daten oder der gleichen verwendet.


Deine scheint mir die typische Sicht der "klassischen" SPS-Programmierer zu sein.

Und hinsichtlich "einfacher zu handhaben":
In deinem Falle hast du es meist mit mindestens 2 Systemen zu tun. Wenn PLC und NC auf einem PC-System koexistieren und der Anwender im Programmieralltag kaum noch eine Trennung feststellt (so wie bei der BEckhoff NC), wieso soll das komplizierter sein?
... ich nenne das Fortschritt. :TOOL:


----------



## rostiger Nagel (10 Januar 2010)

moin taucher,



trinitaucher schrieb:


> ... wenn ich heute nochmal Siemens programmieren müsste, würde ich sehr viel an Funktionalität und Komfort vermiseen, glaube ich.


 
ganz so ist es ja nicht mehr, Siemens treibt ja das PC geschäft voran.
Schon klar das Sie noch nicht da sind wo Beckhoff schon ist, aber
SPS und HMI laufen schon rund bei denen. 

Wenn der Beckhoff eine eigene vernünftige HMI-Software anbieten würde
wäre ich schon längst auf Beckhoff umgestiegen.
Ich habe die erfahrung gemacht das die HMI mehr Arbeit macht wie das
reine SPS-Programmieren, da brauche ich dann schon ein gutes Werkzeug.


----------



## Larry Laffer (10 Januar 2010)

OK ... gebe ich jetzt auch mal meinen Senf dazu ...

Die von Siemens zur Zeit verfolgte Strategie (wenn es denn eine gibt) ist mir auch nicht eingängig ... das wird dann aber die Zukunft zeigen.

Was die Steuerungen selbst angeht :
In meiner Steuerungswelt gibt es (mittlerweile) grundsätzlich den PC - diesen allerdings hauptsächlich zur Visualisierung mir diversen Abaraten von Daten-Erfassung und -Archivierung. 
Ich könnte mir aber nur sehr schwer vorstellen, beides in einem System zu integrieren (aus unterschiedlichen Gründen). Sicher ist ein Allrounder hier und da praktisch - aber immer auch praktikabel ?
Die Grundaufgaben des PC's (in meiner Welt) haben mit denen der SPS erstmal nicht so viel zu tun.
Selbstverständlich habe ich aber auch relativ intelligente Bestandteile in der SPS (in SCL realisiert), die ein PC sicher noch etwas schneller ausführen könnte.
Aber ... performante unterschiedliche Tasks können sich auch schon mal gegenseitig behindern - ist immer eine Frage, wie es gemacht ist.
Eine Positionier-Aufgabe wird ja auch ganz selbstverständlich an einen Servo-Regler übergeben - und zwar nicht, weil es die SPS nicht genauso gut könnte, sondern damit sie unabhängig voneinander arbeiten können.

Obwohl ich ein großer Freund von "maximaler Integration" bin ziehe ich hier gerne die Grenze ...

Gruß
LL


----------



## trinitaucher (10 Januar 2010)

Larry Laffer schrieb:


> Die Grundaufgaben des PC's (in meiner Welt) haben mit denen der SPS erstmal nicht so viel zu tun.
> ...
> Aber ... performante unterschiedliche Tasks können sich auch schon mal gegenseitig behindern - ist immer eine Frage, wie es gemacht ist.


Dabei haben PC und SPS sehr viel miteinander zu tun. Bis auf das Betriebsystem und spezifische Ausprägungen der Hardware ist erstmal kein Unterschied vorhanden. Beide haben CPU und Arbeitsspeicher, sowie heutzutage auch einen Nicht-Arbeitspeicher (mir fällt kein bessere Wort ein). Feldbusanbindung (oder generell Kommunikation zu anderen Systemen) ist bei beiden mit Zusatzhardware möglich. Beim PC nur mit tiefer standardisierter Hardware (PCI-Karten).
Nimmt man eine Beckhoff CX-CPU, dann ist der einzige Unterschied zwischen SPS und PC das Betriebsystem. 

Die "Grundaufgaben" sind für mich doch eher historisch entstanden, da die Rechentechnik sich zunächst in zwei Richtungen (IT und Steuerung) auseinander bewegt hat.
Aber nun kommt beides durch Software wieder zusammen. Den Trend sehe ich klar in Richtung "mehr Applikation", also mehr Anwendungen in der Maschine gehen.
Da ist doch der ständige Kommunikationsaufwand zwischen PC und SPS eher lästig.




Larry Laffer schrieb:


> Eine Positionier-Aufgabe wird ja auch ganz selbstverständlich an einen Servo-Regler übergeben - und zwar nicht, weil es die SPS nicht genauso gut könnte, sondern damit sie unabhängig voneinander arbeiten können.


Ich sehe den Bedarf nach Unabhängigkeit der Systeme im Maschinenbau (wo ich arbeite) eher schwinden. Für sicherheitsrelevante Anwendungen mag das zutreffen, ansonsten kann die SPS (bzw. integrierte SPS/NC auf dem PC) eine Positionierung genauso gut.
Den Achsregler sehe ich nur noch als Endstufe.

Was macht der PC in der klassischen Steueurngstechnik?
- Visualisieren
- Datenbanken
- Auswertungen mit Spezialsoftware

Was macht die SPS / NC?
- I/Os schalten
- Achsen Positionieren

Ich verstehe nicht so recht, wieso man immer gedanklich noch zwischen IT- und Steuerungswelt unterscheiden will. (mag an meiner im Vergleich zu anderen Usern hier noch geringen Berufserfahrung liegen)

Wenn der PC beide o.g. Anwendungsgebiete beherrscht, und dabei sogar noch besser ins System integriert als der Stand-Alone-PC und mit höherer Performance als die SPS....wieso noch trennen?

TwinCAT 3 mit der Integration von C/C++ usw geht doch genau in diese Richtung. (darum geht es ja eigentlich in diesem Thread) 

Wenn man sich bei Siemens mit deren Lösung, wie "bike" sie beschrieben hat,nnen Ast abbricht, dann ist es ja kein Wunder, dass PC-basierte Systeme wenig akzeptiert sind.

... Ach Leute... wir schweifen schon wieder ab...


----------



## Blockmove (10 Januar 2010)

Ob Hard- oder Soft-SPS ist nicht mal das grundlegende Problem.
Es liegt meines Erachtens an der Hard- und Software bei den PCs. Unsere ältesten Anlagen mit S5 sind von ca. 1985. Wartung und Instandhaltung sind immer noch möglich. Die meisten Ersatzteile sind noch erhältlich.
Die PC-Software musste aber schon x-mal geändert werden.
Betriebssystem: DOS -> Win 3.11 -> Win XP.
Serielle Treiber: Meilhaus -> Standard-Com -> Windows-Comport.
Datenhaltung: DBase -> Access.

Solange man den Source-Code hat und entsprechende Entwickler ist das ja auch meist kein riesen Problem, aber wenn nicht :-(
Aber dazu gibt es genügend Threads hier im Forum.

Gruß
Dieter


----------



## bike (10 Januar 2010)

trinitaucher schrieb:


> :
> In deinem Falle hast du es meist mit mindestens 2 Systemen zu tun. Wenn PLC und NC auf einem PC-System koexistieren und der Anwender im Programmieralltag kaum noch eine Trennung feststellt (so wie bei der BEckhoff NC), wieso soll das komplizierter sein?
> ... ich nenne das Fortschritt. :TOOL:


Dann hast du vermutlich nicht die Erfahrung eines PLC Programmieres.
Also eine PLC starte ich meist nur wenn die Spannung wiederkommt, also in vielen Betrieben nur keinmal, da 24/7 gearbeitet wird.
Wer mir erzählt eine SoftPLC kann das auch, dem glaube ich nicht.
Denn ich arbeite neben den Teilen von Siemens(Hard- und SoftPLC) mit denen von Beckhoff und IBH und auch noch anderen.
Keines dieser kann angeschalten bleiben  und  kein Herrsteller hat es mir garantiert, dass die 24/7 Betrieb können und ggF bei einem Problem die Kosten, die beim Kunden entstehen, übernommen werden.

Also die Definition, dass zwischen PC und PLC kaum ein UNterschied ist der ist wohl nur soweit richtig, dass beide Spannung und Strom zum Betrieb brauchen, sonst sind daziwschen Welten.


Um auf den Ausgangspunkt zu kommen:
Nach meiner Meinung und Erfahrung ist es gut, dass es zwei Welten gibt und beide haben ihre Berechtigung, aber bitte nicht alles in einen Topf geben und umrühren und diesen Brei als tolle Errungenschaft zu bezeichnen.


bike

P.S: ich würde mich auch ab und an über Funktionen freune, die ein PC direkt bietet. Doch wichtiger ist ein störungsfreier Betrieb.


----------



## bike (10 Januar 2010)

trinitaucher schrieb:


> Ich verstehe nicht so recht, wieso man immer gedanklich noch zwischen IT- und Steuerungswelt unterscheiden will. (mag an meiner im Vergleich zu anderen Usern hier noch geringen Berufserfahrung liegen)


Ganz einfach ist der Grund: Wenn in der IT was daneben läuft, dann ist eben etwas schief gelaufen in der Stuerwelt ist oft ein sichtbarer meist beträchtlicher  materieller Schaden, oft leider auch Personenschaden.
Daher besteht dieser Unterschied und der wird denke ich auch bleiben.

Wie fehlerhaft Compiler sind zeigt sich heute an den Bankkarten, da bin ich froh eine PLC zuhaben die solche Probleme nicht(mehr) kennt.

Ich entwickle leider inzwischen auch mehr mit C, Delphi und JAVA als PLC.


bike


----------



## trinitaucher (10 Januar 2010)

bike schrieb:


> Also die Definition, dass zwischen PC und PLC kaum ein UNterschied ist der ist wohl nur soweit richtig, dass beide Spannung und Strom zum Betrieb brauchen, sonst sind daziwschen Welten.


Wenn man den PC immer noch als Billighardware im ATX-Normgehäuse ansiehrt.
Das was einen "PC" zu mehr macht als eine PLC sind das Betriebsystem, die obligatorischen Ein-/Ausgabegeräte (Maus/Tastatur+Monitor, die er als "personal Computer" benötigt) und evt. der höhere Grad an Standardisierung.
Wenn man die Standardisierung außer acht lässt und Maus/Tastatur und Monitor in der SPS durch I/Os und Bildschirm substituiert, ist der einzige nennenswerte Unterschied nur das Betriebssystem, was (heutzutage) als umfassend standardisiertes Software-Interface dient.


bike schrieb:


> Also eine PLC starte ich meist nur wenn die Spannung wiederkommt, also in vielen Betrieben nur keinmal, da 24/7 gearbeitet wird.
> Wer mir erzählt eine SoftPLC kann das auch, dem glaube ich nicht.
> Denn ich arbeite neben den Teilen von Siemens(Hard- und SoftPLC) mit denen von Beckhoff und IBH und auch noch anderen.
> *Keines dieser kann angeschalten bleiben*  und  kein Herrsteller hat es mir garantiert, dass die 24/7 Betrieb können und ggF bei einem Problem die Kosten, die beim Kunden entstehen, übernommen werden.


Wie kommst du zu dieser Einschätzung?
Wer sagt dir denn, dass du einen (Industrie)PC zwingend ausschalten musst?

Welcher SPS-Hersteller übernimmt den bitteschön die Ausfallkosten, wenn eine derer CPUs nen Problem hat?


----------



## bike (10 Januar 2010)

trinitaucher schrieb:


> Wie kommst du zu dieser Einschätzung?
> Wer sagt dir denn, dass du einen (Industrie)PC zwingend ausschalten musst?



Ich.
Ich habe solchen Mist am Bein und deine Einschätzung, dass PC das selbe kann und die selbe Zuverlässigkeit hat wie eine PLC stimmt einfach nicht.

Profis sind immer besser als Allrounder.

Ich weiss inzwischen warum Fanuc die meisten NC Steuerungen verkauft.
Deren System ist alt, gut, doch es läuft stabil und zuverlässig.
Eine 16M ist mir 100 mal lieber im Gesicht als eine 180 im Hintern.

Willkommen in der real world 

Nimm eine Beckhoffsteuerung und geh einmal damit zu Kunden im Automotiv Bereich. Ein Besuch in Guyancourt wird dir vielleicht die Augen öffnen, aber nicht nur dort. 
Visionen sind immer gut, doch diese müssen auch den Besuch in Realität vertragen.

Hochsprachen sind nicht dafür gebaut Anlagen zu steuern.


bike

P.S: wenn wir das Geld hätten, das wir wegen solchen Experimeten den Kunden nachwerfen müssen, müssten nicht Leute bei uns entlassen werden.


----------



## trinitaucher (10 Januar 2010)

bike schrieb:


> trinitaucher schrieb:
> 
> 
> > bike schrieb:
> ...


Nenn doch mal nen konkretes Beispiel. Auch für die These, eine PC-Steuerung könne keinen 24/7-Betrieb.
"Ich" ist irgendwie kein überzeugendes Argument.

Und dass PC-basierte Systeme nur aufgrund von Ausfallwahrscheinlichkeiten nicht im Automotiv-Bereich eingesetzt werden, halte ich für ein Gerücht. Schließlich bietet Siemens mittlerweile auch PC-basierte Lösungen an.

Möglicherweise haben die PC-basierten Systeme noch ein Nieschendasein und sind von den klassichen SPSlern wenig akzeptiert, aber ich bin fest davon überzeugt, dass sich am Markt in den nächsten Jahren noch viel tun wird.

OK, meinetwegen könne wir diese Diskussion auch sein lassen. Du hast deine Meinung. Ich hab meine.



bike schrieb:


> Visionen sind immer gut, doch diese müssen auch den Besuch in Realität vertragen


Ohne Visionen hätten wir heute nicht einmal nen PC, geschweige denn elektrische Energie


----------



## bike (10 Januar 2010)

trinitaucher schrieb:


> Nenn doch mal nen konkretes Beispiel. Auch für die These, eine PC-Steuerung könne keinen 24/7-Betrieb.
> "Ich" ist irgendwie kein überzeugendes Argument.



Für mich schon, da wir mit unseren PC Systemen das Geld nur hinterherwerfen, da solche Systeme einfach nicht funktionieren.
Es gibt KEINEN PC der ein Jahr durchläuft, ohne irgendwelche Probleme.
Selbst unsere Server die bestimmt vom feinsten sind haben ab und an eine Streicheleinhiet und einen Reboot nötig. Das sind aber Kisten die so teuer sind, dass damit sich der Preis bei Anlagen verdoppeln würde



trinitaucher schrieb:


> Und dass PC-basierte Systeme nur aufgrund von Ausfallwahrscheinlichkeiten nicht im Automotiv-Bereich eingesetzt werden, halte ich für ein Gerücht. Schließlich bietet Siemens mittlerweile auch PC-basierte Lösungen an.



die im Automotiv und Aerospace nicht eingesetzt werden, da die Kunden diese nicht wollen.





trinitaucher schrieb:


> OK, meinetwegen könne wir diese Diskussion auch sein lassen. Du hast deine Meinung. Ich hab meine.
> 
> 
> Ohne Visionen hätten wir heute nicht einmal nen PC, geschweige denn elektrische Energie



Stimmt es ist keine Diskussion sondern ein Monolog von zweien.
Mach doch das System so publik, dass wir es bei den grossen Kunden einsetzen dürfen, der Nobelpreis ist dir sicher!


bike


----------



## Question_mark (10 Januar 2010)

*Damit das hier kein M*

Hallo,



			
				trinitaucher schrieb:
			
		

> Wenn man die Standardisierung außer acht lässt und Maus/Tastatur und Monitor in der SPS durch I/Os und Bildschirm substituiert, ist der einzige nennenswerte Unterschied nur das Betriebssystem,



Diesen Vergleich finde ich wirklich an den Haaren herbeigezogen. Insofern findet das nicht ganz meine Zustimmung.

Der Abstand der Leistungsfähigkeit zwischen PLC und PC hat im Laufe der Jahrzehnte sicherlich abgenommen. Viele Funktionen, die früher nur mit einem PC möglich waren, kann man heute auch mit einer PLC erledigen. Aber, und da muss ich dem User Bike recht geben, Steuerungsaufgaben gehören nicht auf den PC. Und eine Visu gehört nicht in die PLC, vielleicht treffen sich ja mal im Laufe der nächsten Jahre diese beiden Ebenen auf einem gemeinsamen Level, aber zur Zeit sind wir davon noch weit entfernt. 



			
				bike schrieb:
			
		

> sondern ein Monolog von zweien.



Sogar das stimmt. Ich hätte das hier zuerst als Dialog zwischen trinitaucher und bike gewertet.

Aber, hier handelt es sich tatsächlich um einen Monolog, da keine spielexternen Figuren (also weitere Forumsteilnehmer) ausdrücklich angesprochen werden. Verdammt, ist die deutsche Sprache manchmal schwer ...

Gruß

Question_mark

PS : Ich programmiere 50/50, also 50% in Hochsprachen auf dem PC und 50% in PLC ..


----------



## rostiger Nagel (11 Januar 2010)

Beim dem ganzen Gerede PC oder PLC würde mich mal intressieren, warum
ihr eure HMI den PC (bzw. Windows) anvertraut aber das SPS Programm
nicht. Es ist ja schön zu wissen das SPS Programm läuft unter allen
bedingungen weiter, aber ich kann die Anlage nicht mehr bedienen weil die
HMI anscheinend unter Windows ausgefallen ist. Für mich ist, das ein
wiederspruch in sich.

Dazu das eine SPS absolut fehlerfrei ist und unverwüstlich, kann ich doch
nur den Kopf schütteln. Wie oft haben wir es hier im Forum, das eine
SPS offensichtlich defekt ist oder ein Betriebssystem Update braucht.
Mann lese mal folgende punkte von letzten Firmware Update der 319 PN/DP
(der FAQ ist vom 22.12.2009)



> Wird ein OB35 mit kleinen Weckintervallen von bis zu 5ms programmiert, dann geht die CPU, beim Überladen von Bausteinen nicht mehr sporadisch mit OB-Anforderungsfehler in STOP.
> 
> Die nacheinander erfolgende Zuweisung von 3 oder mehr aufeinander folgenden Bits (z.B. 0.0, 0.1, 0.2, ...) erfolgt nun stets korrekt.
> 
> ...


 
und das ist nur ein Auszug, soviel zu den absoluten perfekten Systemen
die überhaubt keine fehler kennen.
(wer möchte kann ja mal den rest lesen http://support.automation.siemens.c...tandard&viewreg=WW&objid=10805045&treeLang=de)

Bei den anderen CPU's sieht es nicht anders aus. Für mich ist es immer
erschreckend wenn ich in den FAQ's lese, das auf einmal funktionen in
Ordnung gebracht wurden, die ich seit jahren einsetze.

Dann die Systemverfügbarkeit von PC's oder der schnelle Wandel, für mich war mal
vor jahren die S5-95U eine schicke steuerung, dann ist dafür die 314IFM gekommen
und auch die wurde wieder abgelöst von der 314C.
Jetzt vesuch doch einmal das EPROM von der S5 in einer 300er zu stecken,
geht nicht. Wenn du die IFM durch eine C erzetzen must geht das auch
nicht einfach mit Speicherkarte ziehen und stecken, weil da die Karten
auch wieder unterschiedlich sind. Da musst du als Programmierer auch wieder dran.

Ich glaube auch nicht das die PC-Hardware so viel schlechter ist wie die 
PLC Hardware, der PC wird auch 24/7 laufen, wenn es ein Industrie PC ist.


----------



## Larry Laffer (11 Januar 2010)

Hallo ihr ...

Zu dem Thema noch etwas von mir ...

Man sollte hier die Begrifflichkeiten SPS und PC nicht so eng sehen. Eine SPS ist ja in jedem Fall auch etwas wie ein PC - nur halt ein etwas anderes Betriebssystem, dass eine andere Ziel-Ausrichtung erfordert.

Ich sehe die Dinge so, wie sie in der Programmierung auch stattfinden. Es gibt nicht den einen Superbaustein, in dem alles programmiert ist (obwohl man das im Prinziop auch hinkriegen würde), sondern Einzel-Aufgaben werden an Einzel-Funktionen oder -Prozeduren vergeben, welchen dann nur noch das Resultat zurückliefern. Verallgemeinernd ist diese Übergabe eine Schnittstelle - wie zwischen HW-Komponenten.
Wie schon erwähnt : so sehe ich die Welt - Punkt !

Ob ich z.B. einen Servo-Regler oder was auch immer einem Unter-Task übergeben würde (ich habe schon geschrieben, dass ich keinen Zweifel daran habe,dass das geht) ? - Nein - mein Prinzip.

Genauso sehe ich das(wie schon geschrieben mit der Visu). Das erfordert auch nur eine Art Schnittstelle (und die ist nicht mal besonders groß) zwischen vollkommen unterschiedlichen Programm-Teilen - warum sollen die, wenn sie doch so unterschiedlich sind, nicht auch auf seperaten Rechnern laufen ? Etwas Anderes wären seperate Tasks ja schließlich auch nicht ...

Wie war das mit F-Programmen ? Sind das zwei Tasks in einem Prozessor oder 2 Prozessoren (und Begleit-HW), die miteinander "sprechen" ?

Aber ich denke, hier kann und darf jeder seine Meinung haben, so lange er die meinung des Anderen gelten läßt ... Die Zukunft wird uns zeigen, wie es wirklich wird ...

Gruß
LL


----------



## rostiger Nagel (11 Januar 2010)

Larry Laffer schrieb:


> Wie war das mit F-Programmen ? Sind das zwei Tasks in einem Prozessor oder 2 Prozessoren (und Begleit-HW), die miteinander "sprechen" ?


 
F-Programme bei Siemens, laufen im OB35 (zwar auch ein eigener Task)
aber damit kennen wir uns ja aus. Mittlerweile läuft das F-Programm auch
auf dem PC, das ist dann kein besonderer mit extra Prozessor.


----------



## Larry Laffer (11 Januar 2010)

Ach ja ... noch etwas ...

Ich habe überhaupt keinen Zweifel daran, dass man mit einem Hochsprachen-Programm eine Anlage oder Maschine steuern und betreiben kann. In (sinnvollen) Teilen mache ich das ja schlußendlich auch. Es ist hier nur halt die Frage (und so etwas hat Zotos am Anfang des Thread m.E. ja auch schon erwähnt) was man wie am Besten und am Sinnvollsten macht ...


----------



## SPSDAU (11 Januar 2010)

bike schrieb:


> die im Automotiv und Aerospace nicht eingesetzt werden, da die Kunden diese nicht wollen.
> bike



Guten Morgen,

ich habe ja nichts gegen unterschiedliche Philosophien und kann diese auch akzeptieren, nur sollte man nicht mit falschen Behauptungen argumentieren. 

Ich kenne ca. 1 Dutzend große Automobilwerke von Innen und wenn man da rufen würde "SOFT-SPS raus" könnte keiner mehr produzieren und dies an relavanten Stellen. Auch im Bereich Flugtechnik kann ich Dir garantieren das es dort inzwischen reichlich SOFT-SPS in den Werken gibt.

Ich kann das von Helmut_von_der_Reparatur gesagte aus der Praxis nur Unterstützen, wenn man eine solche Trennlinie PLC PC beibehalten will dann müsste man die Maschine und die Linie auch so aufbauen. Dies findet in der Praxis aber kaum noch statt, denn die Visu ist eben  funktionsrelevant und es gibt heute auch genügend Linien die ohne ein MES System überhaupt nicht mehr laufen.

Gruß!

SPSDAU


----------



## SPSDAU (11 Januar 2010)

Larry Laffer schrieb:


> Hallo ihr ...
> 
> Ob ich z.B. einen Servo-Regler oder was auch immer einem Unter-Task übergeben würde (ich habe schon geschrieben, dass ich keinen Zweifel daran habe,dass das geht) ? - Nein - mein Prinzip.
> ...
> Genauso sehe ich das(wie schon geschrieben mit der Visu). Das erfordert auch nur eine Art Schnittstelle (und die ist nicht mal besonders groß) zwischen vollkommen unterschiedlichen Programm-Teilen - warum sollen die, wenn sie doch so unterschiedlich sind, nicht auch auf seperaten Rechnern laufen ? Etwas Anderes wären seperate Tasks ja schließlich auch nicht ...



Hi,

worin besteht denn der von Dir beschriebene Unterschied in den Anwendungen aus Sicht des Prozessors ? Ich könnte mir glatt vorstellen das dem das völlig egal ist ?

Was hier völlig fehlt sind die entscheidenden Argumentente pro Integration in 1 System:

1. Kosten (ich beneide jeden der in einer Branche arbeitet wo dies kein Thema ist)
2. Nutzung von 1 System mit Durchgriff auf alle Komponenten für den Programmierer. Ich habe z.B. keine Lust mir die X.-Servoachse freiwillig anzutun wenn ich dies auch in der NC machen kann. Bei vielen größeren Maschinenbauern gibt es auch heute noch getrennte Spezialisten für SPS und Antriebstechnik.
3. Die Integration von immer mehr Funktionen/Erfassungen u.s.w. in eine SOFT-SPS, da kann keine Hard SPS mithalten.


----------



## MasterOhh (11 Januar 2010)

Die Diskusion Hard vs Soft SPS finde ich sehr interessant, ist aber leider nicht so recht das Thema dieses Threads. Vieleicht könntet ihr das Streitgespräch in einem neuen Topic weiterführen, ich würds auf jedenfall weiter lesen!


----------



## pvbrowser (11 Januar 2010)

Wenn die Chinesen schlau sind,

stecken die ein Atom- oder Arm-Motherboard aus einem Netbook in ein SPS Gehäuse und spendieren dem Ganzen noch eine I/O Karte mit galvanischer Trennung. Darauf könnten Sie Linux laufen lassen und das Ganze mit C++ programmieren.

Ist das denn so abwegig ?


----------

