# Programmierung auf dem PC



## pvbrowser (4 März 2007)

Wie seht Ihr das ?

Wenn man einen PC für Steuerungs/Regelungs-Aufgaben einsetzt,
sollte man dann mit SPS-ähnlicher Programmierung heran gehen oder
sollte man in Hochsprachen programmieren, die auf dem PC zu hause sind.

Wenn ja, welche ?
- C/C++
- VB
...

Scriptsprachen oder compilierte Sprachen ? 

Wir machen das in C/C++
- Serverseitige Programmierung
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classes.html
- Programmierung des HMI
http://pvbrowser.de/pvbrowser/sf/manual/html/modules.html


----------



## zotos (4 März 2007)

Die Frage ist meiner Meinung nach sehr schwammig.

Also wenn es um die Programmierung von Echtzeitsystemen mit Physikalisch Ein- und Ausgängen (wenn auch über ein Feldbussystem) denke ich das kein Weg an SPS bzw. in dem Fall an einer Soft-SPS vorbei führt.

Ich kenne zwar aus der Praxis auch andere Systeme wie z.B. C Programme die aus MS-DOS laufen oder bei Multitasking OS9. Aber diese Systeme sind historisch gewachsen und lassen sich nur sehr schwer debuggen.

...Jetzt wo ich Deine Frage noch mal lese kann ich da irgendetwas nicht richtig gelesen haben. VB ist IMHO nicht für Steuerungen und Regelungen zu gebrauchen. Als HMI ist VB wirklich brauchbar aber doch nicht zu Steuerung.


----------



## pvbrowser (4 März 2007)

zotos schrieb:


> ...Jetzt wo ich Deine Frage noch mal lese kann ich da irgendetwas nicht richtig gelesen haben. VB ist IMHO nicht für Steuerungen und Regelungen zu gebrauchen. Als HMI ist VB wirklich brauchbar aber doch nicht zu Steuerung.



Wir nehmen C/C++

Hier ist z.B. ein Regler:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlController.html

Aber auch für Steuerung nehmen wir ANSI-C


----------



## seeba (4 März 2007)

pvbrowser schrieb:


> Wir nehmen C/C++
> 
> Hier ist z.B. ein Regler:
> http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlController.html
> ...


Hallo Rainer,
wenn's um Systeme oder Maschinen geht, die man in Serie fertigt oder in einer Art Modulsystem, kann man sicherlich was eigenes unter RTLinux oder so entwickeln, aber für Sondermaschinen sollte man dann doch lieber zu einer SPS oder einer Soft SPS greifen.

Ich wollte mich schon länger mit RTLinux und EtherCAT beschäftigen, aber ich bin vollbeschäftigter Schüler. 

Liebe Grüße,
Sebastian


----------



## pvbrowser (5 März 2007)

Hallo Sebastian,

wenn es um PC's in der Automation geht, sollte man vielleicht zwischen normalen PC's und embedded Systemen (ohne Festplatte) unterscheiden.

Normale PC's sollten wohl nur ab Level 2 in der Automation eingesetzt werden.

Im Level 1, da wo Alles unbeaufsichtigt laufen muss, sind embedded Systeme aber inzwischen vielleicht eine Alternative (wenn auch kein Ersatz) für SPS Systeme.

Bei solchen embedded Systemen könnte man ja nun eine Programmiersprache, wie ANSI-C einsetzen. Mit einer entsprechenden Bibliothek, könnte ich mir durchaus vorstellen, dass das eine Alternative zur SPS Programmierung ist.

Wie ist die allgemeine Meinung dazu ?


----------



## zotos (5 März 2007)

Wir setzen (nicht ausschließlich) auch bei Vollautomaten PC gestütze Systeme (auch mit Festplatte und Monitor) ein.

Das ist doch keine Frage der Hardware sonderen vom Software Konzept.
Also ich denke das eine SPS die durch einen PC ersetzt wird immer noch eine SPS (SoftSPS) sein sollte. Die SPS Programmierung ist ja nur ein Tool um eine Aufgabe zu lösen.

Dazu ist es schwer mit C/C++ ein Debugging an einer laufenden Maschine zu bewerkstelligen.

Also ich denke eine Maschine direkt in C/C++ zu programmieren ist ein Rückschritt.


----------



## kiestumpe (5 März 2007)

Hallo,

ich denk die Frage kann nicht allgemeingültig beantwortet werden.

Man muss sich doch eher folgende Fragen dazu stellen:

Was wird/wurde bisher eingesetzt?
Wie zuverlässig funktioniert das, gibt es bedarf dies zu ändern?
Wie schnell kann ich mit dem bisherigen System meine Aufgabe lösen und was bringt mir ein anderes System an Vorteilen?
Wenn ich Hochsprachen einsetze, sind alle Mitabrbeiter entsprechend geschult?
Reicht die zur Verfügung gestellte Zykluszeit des Systems für meine Anwendung?

Ich persönlich würde mit einer IDE für Windows keine Steuerungsaufgaben realisieren (MS C++, Borland Delphi etc). Das wäre mir zu unhandlich für das Problem. 

Eine alternative zu PLC-Systemen bilden m.W. noch die System von National Instruments. Die Karten sind schnell, können jedoch nur Konfiguriert werden. 

Schließlich kann man die uController auch noch direkt programmieren, und dann würde ich auch C++ zurückgreifen. Aber das lohnt nur bei hohen Stückzahlen, da man sich um die Schnittstellen zum Feld selber zusammenschustern muss. 

hth


----------



## HDD (5 März 2007)

Hier ist auch nicht zu vergessen dass der Endverbraucher noch ein Wörtchen mit reden kann.
Beispiel bis vor einiger Zeit hatte ein Maschinebauer der Anlagen für uns geliefert hat auch so ein Selbstgestricktes System  sogar die CPU war Eigenbau und alles in C Programmiert. Aber auf Druck der Verbraucher hin hat er nun umgestellt auf Standart Systeme S7 SCL. Wer lässt sich freiwillig eine System einbauen, dass die Instandhalter nur sehr schwer Überblicken, wenn überhaupt. Die Manager kennen nicht mal das Wort C++ aber Simatic kennt jeder.

HDD


----------



## zotos (5 März 2007)

HDD schrieb:


> Hier ist auch nicht zu vergessen dass der Endverbraucher noch ein Wörtchen mit reden kann.
> Beispiel bis vor einiger Zeit hatte ein Maschinebauer der Anlagen für uns geliefert hat auch so ein Selbstgestricktes System  sogar die CPU war Eigenbau und alles in C Programmiert. Aber auf Druck der Verbraucher hin hat er nun umgestellt auf Standart Systeme S7 SCL. Wer lässt sich freiwillig eine System einbauen, dass die Instandhalter nur sehr schwer Überblicken, wenn überhaupt. Die Manager kennen nicht mal das Wort C++ aber Simatic kennt jeder.
> 
> HDD



Kundenwunsch sollte in dieser Unterhaltung nicht berücksichtigt werden.

Sonst kann man hier ja nie über irgend etwas schreiben. Es geht hier um die Meinung von Programmieren und nicht um Kunden.

Und man sollte auch nicht dem irrglabuben verfallen das jeder Kunde S7 haben möchte.


----------



## Gerhard Bäurle (5 März 2007)

zotos schrieb:


> Kundenwunsch sollte in dieser Unterhaltung nicht berücksichtigt werden.



Ausgerechnet die, die das Ganze bezahlen müssen, sollen nicht berücksichtigt werden?  

Meine Meinung dazu:

An Software in fertigungs- oder prozesstechnischen Anlagen 
stellt man ganz andere Anforderungen als an Bürosoftware,
zum Beispiel
Verhalten nach Stromausfall
Echtzeitverhalten
Schnelle Störungsbeseitigung (wenige Instandhalter für viele 
Systeme)
Längere Lebenszyklen

Um das alles in einer PC-Hochsprache so zu lösen, wie in
STEP7, CoDeSys oder anderen Steuerungsystemen, muss
man doch riesigen Aufwand betreiben.

Wo das ganze läuft, PC oder embedded oder SPS ist ein
anderes Thema.

Viele Grüße

Gerhard Bäurle

PS: Es gibt durch aus Fälle, in denen namhafte Maschinenbauer 
die Rentenverträge von C-Entwicklern bei HMI- und Steuerungs-
aufgaben zugunsten von Standardsystemen aufgegekündigt haben.


----------



## zotos (5 März 2007)

Die Frage geht doch darum wie man einen PC-basierendes System zu Steuerung und Reglung von Prozessen programmiert.

Varianten 
a) mit einem SPS-System (z.B. CoDeSys mit RTE oder Step7 mit WinAC)
b) direkt in einer Hochspache (z.B. C/C++)

Ich bevorzuge die SPS-Programmierung für das Steuern und Regeln von Prozessen im zusammenhang mit Maschinen und Anlagen.

Wer hier nun schreibt was ist aber wenn der Kunde unbedingt eine klassische SPS oder zwingend Step7 vorschreibt hat die Frage nicht verstanden.

@Gerhard Bäurle: Da es in diesem Beitrag keinen Kunden (es zahlt also auch keiner irgend etwas!) gibt kann dieser nicht berücksichtigt werden. Es sein den alle Kunden dieser Welt wären gleich was man bei der Argumentation von dem einen oder anderen hier manch mal vermuten könnte.


----------



## HDD (5 März 2007)

Hallo Fönig,
es war nicht meine Absicht deine (Betonung liegt auf DEINE) Diskussion hier zustören!
Ich wollte lediglich eine weitere Sichtweise dieses Themas darstellen. Und dass jeder nur Siemens will habe ich nie behauptet, deshalb auch das Wort Beispiel.  Jetzt nur zum Schluss dann halte ich mich hier raus, es ist aber doch Fakt das Siemens Marktführer ist auch wenn der Fönig diesen Namen nicht mag.

HDD


----------



## Gerhard Bäurle (5 März 2007)

HDD schrieb:


> Hallo Fönig,
> es war nicht meine Absicht deine (Betonung liegt auf DEINE) Diskussion hier zustören!
> Ich wollte lediglich eine weitere Sichtweise dieses Themas darstellen. Und dass jeder nur Siemens will habe ich nie behauptet, deshalb auch das Wort Beispiel.  Jetzt nur zum Schluss dann halte ich mich hier raus, es ist aber doch Fakt das Siemens Marktführer ist auch wenn der Fönig diesen Namen nicht mag.
> 
> HDD



Warum raushalten? Auch Fönige fönnen sich irren.  



zotos schrieb:


> Es geht hier um die Meinung von Programmieren und nicht um Kunden.



OK. Programmierung als reiner Selbstzweck. Ich habe verstanden. 

Viele Grüße

Gerhard Bäurle


----------



## zotos (5 März 2007)

HDD schrieb:


> Hallo Fönig,
> es war nicht meine Absicht deine (Betonung liegt auf DEINE) Diskussion hier zustören!
> Ich wollte lediglich eine weitere Sichtweise dieses Themas darstellen. Und dass jeder nur Siemens will habe ich nie behauptet, deshalb auch das Wort Beispiel. Jetzt nur zum Schluss dann halte ich mich hier raus, es ist aber doch Fakt das Siemens Marktführer ist auch wenn der Fönig diesen Namen nicht mag.
> 
> HDD


  Du hast das Thema nicht verstanden und bist jetzt beleidigt... das ist aber süß ;o) So kenne ich Dich gar nicht.
Ich weis wer Marktführer ist aber Du verwechselst das mit einem Monopol. Ich stehe dazu das ich Siemens für sehr altmodisch und völlig überteuert halte.




deltalogic schrieb:


> OK. Programmierung als reiner Selbstzweck. Ich habe verstanden.


 Programmierung ist kein selbst Zweck. Aber bei einer Diskussion die vielleicht nicht gerade in das Produktspektrum von Deltalogic passt auf einen Fiktiven Kunden zu pochen der auf SIMATIC besteht ist ziemlich doof.


----------



## HDD (5 März 2007)

Also ich denke schon das ich diese Thema verstanden habe. Nur passt dir halt meine Antwort nicht. Darum geht es doch und gerade weil wir uns kennen wollte ich mich hier raus halten um eine Vernünftige Diskussion hier dann doch noch entstehen zulassen. Nun geh ich in meinen Ecke und heul noch ein wenig. Oder wie wir gestern festgestellt haben gehe ich in den Keller und lach.

Mit Pfälzischem Nachbargrus 

HDD

PS. Warte wenn ich dich im Chat erwische. Ich liebe Siemens es gibt nichts Besseres auf der Welt was sage ich im Universum!!!!!


----------



## afk (5 März 2007)

zotos schrieb:


> Aber bei einer Diskussion die vielleicht nicht gerade in das Produktspektrum von Deltalogic passt auf einen Fiktiven Kunden zu pochen der auf SIMATIC besteht ist ziemlich doof.


Nu muß ich mich als oller PC-Programmierer doch auch noch einmischen:

Auf einen fiktiven Kunden hizuweisen, wäre bei der Diskussion zwar blöd, das hat (zumindest so wie ich das in diesem Thread lese) aber auch keiner gemacht, sondern es wurde auf die üblichen Kundengepflogenheiten hingewiesen. Und die große Masse der Auftraggeber im Automatisierungsbereich wollen einen PC nun mal ausschließlich zum Visualisieren und ggf. als Datensammler eingesetzt wissen, aber für Steuerungsaufgaben wird eben auf eine Hardware-SPS bestanden.

Und meine persönliche Meinung zu dem Thema: Das ist auch gut so !

Wenn Du schreibst, daß (fast) alle Anderen die Frage nicht verstanden hätten, doofe Argumente anführen würden und dann auch noch beleidigt seien, wenn sie das von Dir vorgehalten bekommen, dann macht das fast den Eindruck, als wärst Du selbst beleidigt, weil keiner Deiner Meinung ist ...  

... und jetzt gibs mir ...  


Gruß Axel


----------



## Gerhard Bäurle (5 März 2007)

zotos schrieb:


> Programmierung ist kein selbst Zweck. Aber bei einer Diskussion die vielleicht nicht gerade in das Produktspektrum von Deltalogic passt auf einen Fiktiven Kunden zu pochen der auf SIMATIC besteht ist ziemlich doof.



Lieber zotos,

vielleicht lesen Sie sich bei einem Fläschchen Feierabendbier den Thread in aller Ruhe nochmal durch.

Dann werden Sie erkennen (spätestens nach dem 2. Bier), dass ich "STEP7, CoDeSys oder anderen Steuerungsystemen" geschrieben habe. Völlig losgelöst vom Produktspektrum von Deltalogic, das übrigens mit *ACCONtrol* eine S7-Software-SPS mit und ohne Echtzeit enthält. 

In diesem Sinne - Prost Feierabend.

Gerhard Bäurle


----------



## zotos (5 März 2007)

afk schrieb:


> Nu muß ich mich als oller PC-Programmierer doch auch noch einmischen:
> 
> Auf einen fiktiven Kunden hizuweisen, wäre bei der Diskussion zwar blöd, das hat (zumindest so wie ich das in diesem Thread lese) aber auch keiner gemacht, sondern es wurde auf die üblichen Kundengepflogenheiten hingewiesen. Und die große Masse der Auftraggeber im Automatisierungsbereich wollen einen PC nun mal ausschließlich zum Visualisieren und ggf. als Datensammler eingesetzt wissen, aber für Steuerungsaufgaben wird eben auf eine Hardware-SPS bestanden.
> 
> ...




Also ich habe werder vor es Dir noch HDD oder Herrn Bäurle "zu geben".

1. Es geht hier nicht um PC-basierend vs. klassische-SPS.

2. Es geht hier nicht um den Bekanntheitsgrad von SIMATIC oder C++ was HDD da geschrieben hat das kein Manager C++ kennt und jeder SIMATIC diese Behauptung ist wohl eher ein Witz (Google SIMATIC -> [SIZE=-1]1.240.000[/SIZE]  Treffer [SIZE=-1]vs. Google C++ -> 91.100.000 Treffer)

3. W[/SIZE]eil keiner Deiner Meinung ist?


zotos schrieb:


> ...
> Also wenn es um die Programmierung von Echtzeitsystemen mit Physikalisch Ein- und Ausgängen (wenn auch über ein Feldbussystem) denke ich das kein Weg an SPS bzw. in dem Fall an einer Soft-SPS vorbei führt.
> ...





zotos schrieb:


> ...
> Dazu ist es schwer mit C/C++ ein Debugging an einer laufenden Maschine zu bewerkstelligen.
> 
> Also ich denke eine Maschine direkt in C/C++ zu programmieren ist ein Rückschritt.
> ...





zotos schrieb:


> ...
> Ich bevorzuge die SPS-Programmierung für das Steuern und Regeln von Prozessen im zusammenhang mit Maschinen und Anlagen.
> ...



Kann es sein das leute Die mir vorwerfen diesen Beitrag nicht richtig gelesen zu haben, selbst mal etwas genauer lesen sollten?

So jetzt sind wir leider total OT. 

[ironie]
DANKE!
[/ironie]


----------



## Zottel (6 März 2007)

zotos schrieb:


> Dazu ist es schwer mit C/C++ ein Debugging an einer laufenden Maschine zu bewerkstelligen.


Das ist an sich kein Problem von C++:
Beim Debugging einer S7 (für mich nicht das Maß aller Dinge, aber ein Beispiel, das alle kennen) kannst du die Registerinhalte nach jedem Schritt (Verknüpfung, Rechnung) ansehen. Das Programm läuft mit unverminderter Geschwindigkeit und du kriegst nicht jeden Zyklus mit. Mit einem Debugger arbeitest du gewöhnlich mit Einzelschritten oder Breakpoints. Das ist so, weil es bei "normalen" PC-Programmen nichts ausmacht, wenn die Ausführung beliebig verlangsamt wird. Aber natürlich ließe sich ein Laufzeitsystem konstruieren, daß genau dasselbe tut wie eine SPS: Einen vom Benutzer hochgeladenen (kompilierten) Block (quasi den OB1) zyklisch abarbeiten, im dem gerade beobachteten Abschnitt die Registerinhalte sammeln und diese an einen angepaßten Debugger ausgeben.
Auch die Änderbarkeit von Code zur Laufzeit ohne Programmunterbrechung läßt sich machen: Genauso wie in einer S7 muß der Aufruf von Code-Blöcken über eine Liste von Adressen (Funktionszeiger in C/C++) erfolgen. Nachdem der neue Block im freien Speicher abgelegt wurde, ohne den alten zu überschreiben wird vor Beginn des nächsten Zyklus die Adresse des alten Blocks durch die vom neuen ersetzt. 
Nun zur Programmierung eines PC als Soft-SPS: C++ scheint mir nicht die richtige Sprache. Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen. Damit ist die Speicherverwaltung und der Konstruktor/Destruktor-Mechanismus überflüssig. Mehrfachvererbung verwendet kaum ein C++-Programmierer. Vererbung an sich läßt sich auch in C, ohne ++, mit Structs und Funktionszeigern realisieren. C (auch ohne ++) macht auf mich immer einen leicht kryptischen Eindruck, da man mit kurzen Folgen von Sonderzeichen allerlei nette Effekte bewirken kann.
Ich halte Pascal für leichter lesbar (wichtig, da Steuerungen eigentlich immer von anderen Personen als dem Programmierer gewartet werden müssen) und so finde ich es folgerichtig, daß SCL ziemlich "Pascal-artig" ist.

Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet. 

Meine Vorstellung wäre, Compiler zur Verfügung zu stellen für:
KOP, FUP -> AWL
AWL->Maschinencode
SCL->Maschinencode
SCL-> AWL
Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt: 
AVA->Maschinencode
AVA-> AWL
Der Sinn, den über den Zwischenschritt AWL gehen zu können oder nicht, liegt darin, daß mit AWL-Zwischenschritt der Code auch für nicht Hochsprachenkundige (notfalls) nachvollziehbar bleibt, während ohne AWL-Zwischenschritt optimaler (schneller, kurzer) Maschinencode erzeugt wird.


----------



## Markus (6 März 2007)

nicht direkt das thema aber vielleicht könnte das die von zottel angestossene sache weiterführen:

http://www.sps-forum.de/forumdisplay.php?f=27


----------



## zotos (6 März 2007)

Zottel schrieb:


> ...
> Mit einem Debugger arbeitest du gewöhnlich mit Einzelschritten oder Breakpoints.
> ...



So kenne ich das von CoDeSys. Ich benutze Breakpoints und Einzelschitte jedoch nur in der Simulation. Mit laufender Maschine würde das sicher mit einem schaden enden.



Zottel schrieb:


> ...
> Nun zur Programmierung eines PC als Soft-SPS: C++ scheint mir nicht die richtige Sprache. Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen. Damit ist die Speicherverwaltung und der Konstruktor/Destruktor-Mechanismus überflüssig. Mehrfachvererbung verwendet kaum ein C++-Programmierer. Vererbung an sich läßt sich auch in C, ohne ++, mit Structs und Funktionszeigern realisieren.
> ...



Ich selbst bin in C++ eine Niete und kann da auch nicht wirklich was zu sagen. In C beherrsche ich einige Schweinereien die den Code schlanker aber nicht gerade verständlicher machen.



Zottel schrieb:


> ...
> C (auch ohne ++) macht auf mich immer einen leicht kryptischen Eindruck, da man mit kurzen Folgen von Sonderzeichen allerlei nette Effekte bewirken kann.
> Ich halte Pascal für leichter lesbar (wichtig, da Steuerungen eigentlich immer von anderen Personen als dem Programmierer gewartet werden müssen) und so finde ich es folgerichtig, daß SCL ziemlich "Pascal-artig" ist.
> ...



100% ACK



Zottel schrieb:


> ...
> Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.
> ...



Auch hier 100% ACK.
Ich persönlich halte FUP bei Bitverknüpfungen für unschlagbar.
Immer die richtige (passende) Sprache (Tool) für die Aufgabe zu wählen ist schon mal die halbe Miete.



Zottel schrieb:


> ...
> Meine Vorstellung wäre, Compiler zur Verfügung zu stellen für:
> KOP, FUP -> AWL
> AWL->Maschinencode
> ...



Ich kenne das ja nur vom hören sagen hier aus dem Forum. Bin mir also bei folgenden Aussagen nicht sicher:

Step7 macht aus SCL erstmal AWL und das würde dann übel und schwer zu lesen sein.

Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.

_____

Ich kenne das auch von µC wenn man sich da einen Code der in C verfasst wurde in ASM anschaut ist das nicht wirklich lesbar.

Einen Compiler zu bauen ist sehr schwer und super viel Arbeit.

Ich denke das sich ST/SCL für die entsprechenden Aufgaben etablieren wird.

Als die SPSen auf den Markt kamen hat auch kein Instanthalter gewust was das ist und was da auf sie zu kommt. Das war zwar weit vor meiner Zeit aber heute ist eine SPS absolut Standart und so wird es mit den "neuen" Sprachen auch sein.

Die Anforderungen steigen und wenn wir da mit halten wollen dürfen wir nicht als Bermse wirken.


----------



## Werner29 (6 März 2007)

Hallo Zottel,

ich denke wie du, dass die Sprache keine Rolle spielt. Das Problem sind die Programmierumgebungen. Und die sind bei C/C++ eben nicht dafür gemacht,
sich an einen laufenden Prozess anzudocken, ohne Anhalten des Prozesses
Werte anzusehen. Mal eben schnell den Code ändern. (Du hast in deinem Beispiel vergessen, dass man auch Daten ändern will, dann wird die Sache meist komplizierter).



Zottel schrieb:


> Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt:
> AVA->Maschinencode
> AVA-> AWL



Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings. 
Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.

Bernhard


----------



## Gerhard Bäurle (6 März 2007)

Zottel schrieb:


> ...
> KOP, FUP -> AWL
> ...
> SCL-> AWL
> ...



Der AWL Code ist lesbar, aber nachvollziehbar? ... das ist dann ein 
riesiger Aufwand. 



zotos schrieb:


> Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.



Ja, das auf CoDeSys basierende ProSys hat STEP5-AWL 
und STEP7-AWL erzeugt, das AWL war auch lesbar. 

Aber wie jeder automatisch generierte Code war dieser 
AWL-Code nicht wartbar. Wurde von manchmal eher als
Kopierschutz betrachtet.  

Keine Kommentare, der Compiler macht manches um-
ständlicher als ein Programmierer - oder so effizient, 
dass es auch wieder schwer zu verstehen ist.

Das die Zukunft dem Pascal-ähnlichen ST/SCL gehört,
kann ich mir auch vorstellen.

Viele Grüße

Gerhard Bäurle


----------



## harrylask (6 März 2007)

Auch wenns eher an der Anfangsfrage vorbeigeht:

Ich bin nun seit 15 Jahren in der Steuerungstechnik tätig und programmiere nun seit gut 5 Jahren unsere SPSn ausschliesslich in C. Anfänglichs skeptisch weil ich dabei doch einiges mehr an Tipparbeit leisten muss (zumindestens meine IDE behandelt C eher stiefmütterleich). Ich habe in dieser Zeit die Sprache C lieben gelernt und möchte es nicht mehr missen. Richtig strukturiert erübrigen sich fast jeder zusätzlicher Kommentar.



> Beim Debugging einer S7 (für mich nicht das Maß aller Dinge, aber ein Beispiel, das alle kennen) kannst du die Registerinhalte nach jedem Schritt (Verknüpfung, Rechnung) ansehen.



Das sollte eigentlich jeder Debugger ein Hochsprache auch können. Kommt eigentlich nur darauf an wie man programmiert. Der klassische Debugger einer Hochsprache bleibt ja bei einer Programmzeile stehen und je länger diese ist desto umständlicher das debuggen.



> Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.



Was man nicht kennt erschliesst sich nicht jedem sofort, soll heissen, je öfter du damit konfrontiert wirst desto weniger Probleme hast du damit. Ein Programmierer sollte aber mit logischen Ausdrücken wie


```
A = ((B && C) || D) && E;
```

eigentlich keine Probleme haben (das sind mE absolute Basics).



> Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen.



Viele dieser Objekte werden eh nur einmal beim Start generiert und bleiben dann bis zum Schluss am Leben. Wichtig ist doch das man sich um die Speicherverwaltung nicht mehr selbst kümmern muss. Dass man dazu nicht unbedingt eine Hochsprache verwenden muss (Instanz DBs, lokaler Speicherbereich) ist klar, nur bei den meisten Anlagen mit Siemens SPSn seh ich noch fast immer den klassischen Stil mit absoluten Adressen.



> Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
> Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings.
> Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.



Vererbung, überladene Methoden, Namespaces ... klingt interessant!

Grüsse, Harrylask


----------



## pvbrowser (6 März 2007)

Wenn man Hochsprachen in der Programmierung von Automationen einsetzen will,
muss man auf folgendes achten:

- Das Wartungspersonal muss sich in der Hochsprache auskennen
- Man braucht eine Bibliothek für die gängigen Funktionen,
  die einfach zu nutzen ist.
- Das Grundgerüst des Programms sollte vorgegeben sein.
- Das Lesen und Schreiben der Prozessvariablen,
  sollte durch einfache Parametrierung in einer INI-Datei gemacht werden.

Dann könnten die Aktionen die in das Grundgerüst eingesetzt werden wie folgt aussehen:

//---------------------------------------------------------
#include "spslib.h"     // hier sind die Klassen und Funktionen der SPS-Bibliothek definiert
#include "spsdefines.h" // hier wird z.B. DRUCK, DRUCK_LIMIT definiert
extern SPSEingaenge eingaenge;
extern SPSAusgaenge ausgaenge;
extern SPSMeldungen meldungen;

void SPSZyklus() // nur hier drin muss der Anwendungsprogrammierer programmieren
                 // das Hauptprogramm ist fertig vorgegeben
{
  eingaenge.lesen();

  // Hier kommen die Aktionen
  // zum Beispiel
  if(eingaenge.variable(DRUCK) > DRUCK_LIMIT)
  {
    meldungen.printf("DRUCK zu hoch %d Bar",eingaenge.variable(DRUCK)); // zeigt Meldung in HMI an
  }

  ausgaenge.schreiben();
}
//---------------------------------------------------------

Das kann meines Erachtens einfacher lesbar sein,
als ein konventionelles SPS Programm.

Bei der Programmierung von Level 2 und 3 einer Automation,
wird sowieso eine Hochsprache eingesetzt.
Wenn man auch in Level 1 der Automation,
die gleiche Hochsprache einsetzen würde,
braucht das Wartungspersonal nur in einer Sprache zu denken.
Das wäre meines Erachtens ein Vorteil.


----------



## Gerhard Bäurle (6 März 2007)

pvbrowser schrieb:


> Bei der Programmierung von Level 2 und 3 einer Automation,
> wird sowieso eine Hochsprache eingesetzt.
> Wenn man auch in Level 1 der Automation,
> die gleiche Hochsprache einsetzen würde,
> ...



Hallo,

in der Literatur gibt es ja verschiedene Automatisierungs-
pyramiden mit drei, vier, fünf oder gar noch mehr 
Ebenen – je nach Hersteller oder Hochschullehrer .

Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
verstehen – damit wir eine einheitliche Basis haben.

Dummerweise ist in Wikipedia bei SCADA zwar von davon die
Rede, dass Automationen verschiedene Schichten
haben, bei den Automationen selbst steht aber nichts 
Genaueres dazu.

Viele Grüße

Gerhard Bäurle


----------



## pvbrowser (6 März 2007)

> Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
> verstehen – damit wir eine einheitliche Basis haben.

- Level 1
Feldebene, physikalische IO's, geschlossene Regelkreise, Echtzeit ...

- Level 2
Modellrechnungen, Optimierung, Sollwerte für Level 1 bereitstellen,
Data Logging, HMI ...

- Level 3
Produktionsplanung, Qualitätssicherung ...


----------



## zotos (7 März 2007)

Ich habe mir überlegt das man eine pro contra Liste zum diesem Thema anfangen sollte.

Also PC-basierende Automatisierung:
IEC 61131-3  vs. Hochsprachen

Aber das ist viel zu allgemein gefasst.

Also nimmt man eine Hochsprache wie C/C++ mit der kann man ja nun wirklich fast alles machen. Nur man muss eben auch alles selbst machen. Man benötigt um damit arbeiten zu können so was wie ein (auf neudeutsch) Framework. Das Beispiel von pvbrowser ist wohl so ein Grundgerüst das die Anbindung an die Hardware (IOs, etc.), Timer und sonstige Bausteine zu verfügung stellt. Allso alles aufgaben die, die SoftSPSen in Verbindung mit den Entwicklungsumgebungen von Haus aus mit sich bringen.

Solche Grundgerüste für C sind wohl in großer Zahl im Einsatz. Ich selbst habe eine Zeitlang mit einem solchen System gearbeitet. Nun findet man in einem solchen System oft nur schwer den durchblick da die gegebenen Funktionen die man benötigt nicht genormt sind. 

Die Programmiersysteme die sich an die IEC 61131-3 anlehnen (also mit zwei zugekniffenen Augen auch Step7) bieten also eine reihe an genormten Funktionen die meist auch gut dokumentiert sind und die "großen" darunter sind auch noch weit verbreited. Dazu kommt das man mit diesen Systemen eben nicht nur eine PC-basierende Steuerung sondern eben auch die klassischen SPSen programmieren kann.

Das Argument das man wenn man auf allen Ebenen der Automatisierung nur eine Sprache benutzen könnte:



pvbrowser schrieb:


> ...
> Bei der Programmierung von Level 2 und 3 einer Automation,
> wird sowieso eine Hochsprache eingesetzt.
> Wenn man auch in Level 1 der Automation,
> ...



...kann ich zwar nachvollziehen. Ich denke aber man bei einer SPS immer das passende Tool (Programmiersprache) verwenden sollte. 

z.B.:
Bitverknüpfungen (FUP/KOP)
Komplexe Sachen (ST/SCL)
Schrittketten (AS/GRAPH7)
Schnelle trickreiche Sachen (AWL)

Kann man so machen muss man aber nicht.

Das Kredo alles was in der Sprache XYZ geht auch in dieser zu machen halte ich für unpraktisch. Wird aber oft verlangt ;o(


Gibt es eigentlich ein offenes C/C++ "Framework" für die Automatisierung das von verschiedenen Firmen angewand wird?


----------



## Werner29 (7 März 2007)

Hallo,

wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
Da gibt es x Karten für y Feldbusse.
Dann erwartet man von einer SPS ein gesichertes Anlaufverhalten, remanente Daten, Programmänderung ohne den Prozess anzuhalten, Variablen beobachten ohne den Prozess anzuhalten...
Wenn man das alles gelöst hat, dann kann man mit der Applikation anfangen.
Oder man nimmt eben gleich ein Standardtool.

Bernhard


----------



## zotos (7 März 2007)

Werner29 schrieb:


> Hallo,
> 
> wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
> Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
> ...



Das Echtzeitproblem ist ja nicht Hardware bedingt. Man muss ja nicht zu einem OS greifen das keine Echtzeit unterstützt ;o) Aber wenn man z.B. zu RTLinux greift muss man das ja auch erstmal im Griff haben.

Ich denke auch das der Griff zu einem Standart Tool zur Programmierung wie CoDeSys (mit der CoDeSys-RTE) oder Step7 (mit WinAC/ACCONtrol) oder TwinCAT oder eines der anderen zahlreichen Systeme.

Die von Bernhard Angesprochenen Aufgaben die solche Systeme schon gelöst haben sind nicht gerade trivial.

In der heutigen Zeit wird oft bei der Entscheidung "make or buy" zu kaufen tendiert und in diesen Systemen stecken ja Mannjahre an Entwicklung und man muss diese Dinge oft erstmal auf eigene Kosten entwickeln bevor man damit Geld verdienen kann. 

Der Bereich der Automatisierung ist sehr groß es gibt sicher die eine oder andere Anwendung wo es sich lohnt C/C++ anstelle eines SPS-Systems zu nehmen.

Meiner Meinung nach sind die vorhandenen SPS-Systeme so ausgelegt das sie die meisten Anwendungen abdecken können.


----------

