(Industrie) PC statt SPS
-
Hallo.
Gibt es für einen Pc eine Digitale I/O-Karte, die mit den gängigen SPS-Pegeln arbeitet?
Ich möchte in eine Anlage statt einer SPS einen PC einbauen.
-
Die dinger gibts doch wie sand am meer...
http://www.gbm.de/MWE-Systeme/Digital-IO-Karten.htm
Und bist wirklich sicher ein normaler PC ein guter ersatz für ne SPS ist?
Wenn dann würd ich nen industrie PC nehmen und da liefern die hersteller (siemens & co.) meist auch den ganzen rest (I/O karten, CAN,I2C,..ect. ports,...) gleich mit den man braucht.
-
Es gibt auch SPS als PCI-Steckkarten
Ich weiß ja nicht was für eine Anwendung du hast, aber ein normaler PC ist vielleicht wirklich nicht sooo eine gute Idee. Erst recht nicht mit Windows drauf
-
Sollte so ne Art Versuchsprojekt sein. Mir geht es hauptsächlich darum, das ganze mit C++ zu implementieren.
Was kostet so ein std Industrie PC?
-
hi,
für einen vernünftigen IPC kann man schon mal 2500 Euros auf die Theke legen.
-
C++ ist aber auch ne ganz schlechte Idee... Für solche Sachen verwendet man einfache und maschinennahe Programmiersprachen.
-
a) geht sowas mit C++ und
b) sogar unter Windows 98Dummerweise gibt es zu wenig Leute, die sowas wirklich ordentlich umsetzen, deswegen ziehen sich die Maschinenbauer wieder auf Maschinensteuerungen zurück und stecken zehnmal soviel Zeit in komplexere Anwendungen hinein, weil die Dinger z.T. schon Probleme mit einer 32-bit-Division haben. Dafür kann's dann jeder Mechatroniker (glaubt man jedenfalls...).
Natürlich gibt es ein Problem mit der IPC-Programmierung. Für ein ordentliches System braucht es zusätzlich Visualisierungstools - die gesamte Library, die dafür erstellt werden muss ist Non-Standard und macht abhängig vom Programmierer. Eine komplette Neuentwicklung ist ausserdem extrem teuer.
Ferner gibt es das Problem des Nachkaufes. Wie lange hält sich so ein IPC- oder Kartenhersteller überhaupt? Das sind alles Minuspunkte für den IPC.
Deswegen habe ich momentan auch nichts mehr zu tun! Da hilft Qualifikation und eine ready-to-go Librarysammlung überhaupt nichts.
Ferner ist es mittlerweile so, dass nur noch Leute gebraucht werden, die Elektroplanung und Programmierung zusammen erledigen. Ein reiner Programmierer, der kein Kabel legen darf, hat da endgültig gelitten.
-
Hahahaha, Win98???????????????????? und c++ ??? Ich lach mich schlappp... Sicher nicht ! Sowas würde kein Profi machen. Zumindest nicht bei "richtigen" Maschinen die ein paar Milliönchen kosten.
Halt dich zurück!
-dEUs
-
Ing schrieb:
Hahahaha, Win98???????????????????? und c++ ??? Ich lach mich schlappp... Sicher nicht ! Sowas würde kein Profi machen. Zumindest nicht bei "richtigen" Maschinen die ein paar Milliönchen kosten....
Er hat ja auch nicht behauptet, dass das ein Profi machen würde, sondern lediglich, dass es funktionieren würde...
Also Win98 würd ich dafür auch nicht einsetzen... dann kannste auch gleich nen standard PC einsetzen
Besser wäre da schon ein stabiles Echtzeitsystem.Aber warum sollte man denn kein C++ anwenden
, so viel einfacher ist C nun auch wieder nicht, erst recht nicht, wenn das ein komplexes System werden soll.
-
-
Bitsy schrieb:
Dummerweise gibt es zu wenig Leute, die sowas wirklich ordentlich umsetzen, deswegen ziehen sich die Maschinenbauer wieder auf Maschinensteuerungen zurück und stecken zehnmal soviel Zeit in komplexere Anwendungen hinein, weil die Dinger z.T. schon Probleme mit einer 32-bit-Division haben. Dafür kann's dann jeder Mechatroniker (glaubt man jedenfalls...).
Ja und genau deswegen, will ich mit C++ arbeiten. Mit diesen SPS Sprachen kann und will ich mich nicht anfreunden.
-
Klar kann man sich schöneres vorstellen als diese SPS Sprachen. Aber vergesst doch einfach mal die ach so tolle objektorientierte Welt. Das ist viel zu viel overhead für ne Steuerungsaufgabe. c reicht völlig und ist besser dafür. komplexer ist nicht immer besser.
-
Ing schrieb:
Aber vergesst doch einfach mal die ach so tolle objektorientierte Welt. Das ist viel zu viel overhead für ne Steuerungsaufgabe. c reicht völlig und ist besser dafür.
Du solltest keine Programmier-Konzepte mit einer Programmiersprache vergleichen. Das passt irgend wie nicht.
Man kann mit C++ genauso gut Prozedual programmieren und mit C genauso gut Objekt Orientiert. Sogar Funktional, Aspekt Orientiert und wer weiss was alles.
-
Hallo
sowas habe ich vor einigen Jahrten mal gemacht
Steckkarte PC + mit eigenem Betriebssystem (von Phoenix)
Sauschnell billig sicher (wie eine SPS)MfG
Klaus
-
edit:
@kingruedi:
Don't feed the trolls. Hab auch alles wieder wegeditiert.
-
kingruedi schrieb:
Man kann mit C++ genauso gut Prozedual programmieren und mit C genauso gut Objekt Orientiert. Sogar Funktional, Aspekt Orientiert und wer weiss was alles.
Es macht aber keinen Sinn C++ zum prozeduralen Programmieren zu verwenden. Dann kann ich gleich c benutzen und habe schlankere und schnellere Programme.
-
Bitsy schrieb:
edit:
@kingruedi:
Don't feed the trolls. Hab auch alles wieder wegeditiert. Keine Ahnung, was Du damit sagen willst
Du vielleicht Ing?
-
Ing schrieb:
Hahahaha, Win98???????????????????? und c++ ??? Ich lach mich schlappp... Sicher nicht ! Sowas würde kein Profi machen. Zumindest nicht bei "richtigen" Maschinen die ein paar Milliönchen kosten.
Von wegen.
Findet man unheimlich oft, gerade auch bei Maschinen, die ein paar Milliönchen kosten. Ok, 98 wäre mir auch unheimlich... aber mit NT oder w2k und einer Erweiterung wie Kithara dazu sehe ich auch kein grundlegendes Problem.
Hat sicherlich auch bestechende Vorteile, was z.B. Tools für Fernwartung betrifft oder Vernetzung, und und und. Oder eine Vielzahl an ActiveXen für Visualisierungen, etc.
Daß die Industrie das auch nicht gerade als Seltenheit abtut sieht man an der Existenz von OPC - und den zugehörigen Treibern für sämtliche SPSen und Hardwareanschaltungen.
C++ ist auch oft eine gute Wahl, da gerade Maschinensteuerungen eine gewisse "Generizität" aufweisen, d.h. eine sehr schöne Abstraktion nach Klassen erlauben, wodurch sich Ableitungsbäume für verschiedene Maschinenmodule sehr schön modellieren und implementieren lassen. Für alle Sachen, die mit Zeittakten >100ms arbeiten, kein grundsätzliches Problem.
Schnellere Dinge benötigen dann andere Betriebssysteme, aber bevor ich dann zu einem Echtzeit-OS greife nehme ich lieber eine SoftSPS (mein Favorit: TwinCat SoftPLC von der Fa. Beckhoff) und binde die Anschaltungen via Profibus an den PC an, um alle schnellen Signale (bis runter 50µs) damit zu erledigen. TwinCat hat eine sehr schöne Oberfläche, unterstützt die Anbindung an Quellcodeverwaltungen, und hat einen Online-Debugger. Ebenso unterstützt es eine OPC-Schnittstelle und COM für den Datenaustausch.
-
Klar gibt es Windows-Basierte Lösungen, hätte er von WinNT oder 2000 gesprochen, hätte ich auch nichts gesagt, aber W98 halte ich für unwahrscheinlich.
-
C++ ist auch oft eine gute Wahl, da gerade Maschinensteuerungen eine gewisse "Generizität" aufweisen, d.h. eine sehr schöne Abstraktion nach Klassen erlauben, wodurch sich Ableitungsbäume für verschiedene Maschinenmodule sehr schön modellieren und implementieren lassen. Für alle Sachen, die mit Zeittakten >100ms arbeiten, kein grundsätzliches Problem.
Genau deswegen ging's. Und ja - es existiert bereits in 4 grossen Maschinen.
In der Ältesten (die 2000 sogar noch einen Innovationspreis damit gewonnen hat), laufen die gleichen Libraries sogar noch unter DOS. In allen wird Allegro als Graphikoberfläche und Keyboardtreiber verwendet - und es bringt programmierbare Timerinterrupts mit!
Es ist weder Echtzeit, noch Multithreading notwendig gewesen. In der Zeit, in der Festplattenzugriffe laufen, macht die Maschine nichts Gefährliches, und sonst hat das OS nichts zu tun. Also - keine Gefahr!
Mit einem 200 MHz-P2 sind 200 Zyklen pro Sekunde möglich - auch nur, weil Analogkanäle gepollt werden müssen und dort ein Wait von 1 ms nötig ist. Die Programme sind recht rechenintensiv. S5-95U für spezielle Geschichten ist auch nebenbei (in den älteren Maschinen) drin, wird auch angesteuert, als Slave.
Dort habe ich ein fertiges Modul, was in einem einfachen Protokoll DB und DW angibt und dann einen Wert liest/schreibt - mehr braucht's nicht, damit ist alles möglich.
Die neuen Programme würden sogar auch noch unter DOS laufen - wenn - ja, wenn nicht eine neue Prozessorkarte einen Onboard-Grafikchip mitgebracht hätte, der VESA nicht vollständig unterstützt und wir plötzlich dumm geschaut hätten. Die alte Karte wird nicht mehr hergestellt, bumms, aus. Aber da hat die Plattformunabhängigkeit meiner Software (und eben von Allegro) den Umstieg auf W98 in Nullkommanix ermöglicht. Lediglich die COM-Schnittstellen mussten neu programmiert werden, fertig.
Allegro kommt mit DirectX hervorragend zurecht, und ich musste (bis auf die COMs) kein Wort WinAPI oder DirectX verwenden. Mit Win2000 hätte ich da erheblich mehr Probleme gehabt, ob XP (was die Hardware ja abschneidet) überhaupt gegangen wäre - keine Ahnung. Ist auch wurscht - es läuft ja! 24/7!
Möglicherweise stimmt steuerungstechnisch im Jahre 2003 die Geschichte mit dem Baum und Autofahren, aber man sieht - ungewöhnliche Lösungen haben ungewöhnliche Vorgeschichten. Und diese ist bereits 1990 gestartet worden - und ich habe mich in keine Sackgasse reingeschafft, aus der ich nicht mehr rausgekommen wäre. Die letzte der Maschinen wurde im letzten Jahr fertiggestellt - Probleme haben die Hydrauliker, aber nicht ich...
Sollte noch ein Auftrag kommen (der verschoben wurde), werden wir Linux einsetzen - und ich werde auch nur die COM-Geschichte austauschen müssen.Ein Wort noch, weshalb C++:
Es wurde seinerzeit in C begonnen, aber ich hatte die Zeit, es langsam nach C++ rüberzubringen und im Laufe der Jahre immer mehr zu modularisieren.
D.h.: die main loop fährt natürlich nach SPS-Prinzip, lesen, verarbeiten, schreiben. Vorher gibt es eine Initialisierungsphase, in der Skripte gelesen werden, in denen Objekte beschrieben werden, die dann gespawnt werden und sich selbst in Verarbeitungslisten eintragen. Alles ist hierarchisch in einem Baum geordnet, sodass letztlich nur der Verarbeitungsaufruf eines 'mastermodule's notwendig ist. Der Rest schnackelt von selbst. Alle Module haben einen gewissen Satz an Statuszuständen und können Schrittketten in sich tragen, rufen dann wieder untergeordnete Module auf, die letztlich wieder einfache, allgemein formulierbare Module sind, wie abstrakte Zylinder mit zwei 'Enden' ein/zwei Schaltausgängen. Abgeleitete Versionen kümmern sich um Details (ob es also ein Schaltausgang ist, oder zwei, ob die Sensorik aus Zeitgliedern, oder einfachen Näherungsschaltern, oder Mischformen davon sind. Der Typ wird im Skript festgestellt - so kann auch mal ein Schalter ausfallen, der zwischenzeitlich durch ein Zeitglied ersetzt wird.
Jedes Modul besitzt wiederum eine innere Mechanik, die ich jetzt nicht im Detail beschreiben werde. Damit ist es möglich, die Maschine in Automatik laufen zu lassen, und an einem anderen Ende Wartungsarbeiten durchzuführen, bei denen ein Zylinder manuell hin und her gefahren wird. Ferner existiert für jedes Modul ein sogenanntes 'Mock-Objekt' - ist das Teil nicht vorhanden, ersetzt die Simulation ein Normalverhalten. Ferner sind z.B. Zylinder-Module in ein grundlegendes Stör/Not-Aus-System eingebunden, was auch in einer Leerapplikation stets vorhanden ist.
Die Visualisierung hat auch ein paar schöne Features.
Nicht nur die geskripteten Module sind über Namen (im Internetnamensstil, also hauptmodul.untermodul.detail) ansprechbar, sondern alle Variablen sind keine typischen C++-Variablen mehr, sondern werden ebenfalls im Skript erzeugt. Typ, Limits, sowie plug-ins von pre/postfunktionen (bei Werteänderung) sind möglich.
Und so sind sie deshalb auch in der Visualisierung ansprechbar.
Für die Visualisierung werden Visualizer bereitgestellt, die ebenfalls per Skript an die Variablen der Module angebunden werden. Ob dies LED, oder Balken, oder einfache Zahlen sind, ob sie editierbar oder read/only sind, entscheidet alles das Skript - somit kann der Endkunde jederzeit Extraseiten einbinden, in denen er spezielle Dinge gleichzeitig unter die Lupe nimmt.
Wenn ich nun noch die Schrittkettengeschichten in einer einfachen SPS-ähnlichen Sprache auslagere und einen schönen Editor zu Verfügung stelle, hat der Kunde sogar noch die Möglichkeit Programmänderungen selbst vorzunehmen und eigene Module zu entwerfen...
Merke: ich brauche steuerungstechnisch gar keine Ahnung zu haben - reicht, wenn ich weiß, worum es geht, und dem Kunden Tools zur Verfügung stelle.
Und manche alte Eiche fährt schon seit 20 Jahren unfallfrei Auto.