Programmierung auf dem PC

pvbrowser

Level-1
Beiträge
470
Reaktionspunkte
44
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...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
 
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
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. :ROFLMAO:

Liebe Grüße,
Sebastian
 
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Kundenwunsch sollte in dieser Unterhaltung nicht berücksichtigt werden.

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

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.
 
Zuletzt bearbeitet:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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. :(

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

OK. Programmierung als reiner Selbstzweck. Ich habe verstanden. :ROFLMAO:

Viele Grüße

Gerhard Bäurle
 
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.


OK. Programmierung als reiner Selbstzweck. Ich habe verstanden. :ROFLMAO:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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!!!!!
 
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 ... :p

... und jetzt gibs mir ... ;)


Gruß Axel
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ... :p

... und jetzt gibs mir ... ;)


Gruß Axel


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?
...
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.
...
...
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.
...
...
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]
 
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.
 
Zurück
Oben