OS-Implementierungen von Feldbussen gibt es für Linux diverse. Das schnellste dürfte Ethercat sein. Es fehlt aber an offenen Implementieren von SPSen und man ist so gezwungen mit RT-Linux und C zu arbeiten, anstatt nach dem IEC-Standart.
Ach ja, die Siemens-Lösung ist ganz sicher nicht OS.
Es geht nicht um Feldbus aber um Realtime Ethernet. Soweit mir bekannt ist, muss auf den Linux Server ein Realtime Kernel vorhanden sein. Die Ansteuerungssoftware auf den Linux Rechner sowie den notwendige Treibern sind wohl OS.
Naja, prinzipiell ein RT-Ethernet basierter Feldbus... Ob da Feldbus wirklich der richtige Begriff ist, darüber lässt sich nun sicherlich bis zum Sankt-Nimmerleins-Tag diskutieren.
Genauso darüber, welches System nun das schnellste ist. EtherCat ? Profinet IRT ?
Aber darum ging es in dem Artikel ja garnicht.
Trotzdem: Profinet = Siemens... Daran wird sich so schnell (leider) nichts ändern... Von daher glaube ich kaum das das OS sein wird....
Das was Siemens macht ist, dass sie eine IO-Funktion zur Verfügung stellen und nichts weiter. Um die Zeiten muss man sich selbst kümmern. Ethercat belastet aber die CPU weniger und Antwortzeiten liegen im Microsekundenbereich.
Und ja, Profinet kann deshalb als Feltbus bezeichnet werden, weil er die klassischen Aufgaben analog zu Profibus oder Modbus tätigt.
Ich versteh grad die Antwort auf die Frage nicht... Ist Feldbus via WLAN möglich? - Nein, Felbus= I/O-Anbindung an SPS...
Thema des Artikels: SPS-unabhängiger Profinet-Controller, basierend auf Linux. Profinet ist Ethernet-basierend, also theoretisch wäre WLAN möglich. Ich seh eher das Problem der Geschwindigkeit. Profinet setzt ein 100MBit Ethernet vorraus, liese sich also evtl mit einem 300Mbit-WLAN realisieren... Ob das sinnvoll ist, ist eine ganz andere Frage...
Siemens setzt schon WLAN für Profinet ein, ist laut Siemens sogar möglich NOTAUS sicher zu realisieren. Aber für sinvoll halte ich das auch nicht unbedingt.
Ich finde dass es schon sinnvolle Verwendungen für "drahtlose Feldbusse" gibt. Hat man z.B. in der Verfahrenstechnik ein System, welches von einem Operateur überwacht werden muss, ist unter Umständen eine Fernbedienung recht praktisch. Ist diese nun sogar noch Drahtlos, ist der Operateur evtl. in der Lage an einem sichereren Ort zu stehen. Voraussetzung ist natürlich ein fehlerfreies Funktionieren der Fernbedienung (inkl. Not-Aus).
Unterbricht man die Verbindung zwischen "WLAN-NotAus" und AP/SPS, loest das den NotAus aus. Sicher ist das also wohl schon und auch zugelassen. Aber nach einem Fehler moechte ich in so einem System nicht suchen.
Ob die Informationen schnell genug ankommen ist bei Nicht-Sicherheitseinrichtungen wohl von der Anwendung abhaengig. Eine Verzoegerung um 500ms beim Oeffnen eines Ventils in einer Waschanlage wird wohl kaum Auswirkungen auf den Prozess haben...
Ach ja, die Siemens-Lösung ist ganz sicher nicht OS.
Genauso darüber, welches System nun das schnellste ist. EtherCat ? Profinet IRT ?
Aber darum ging es in dem Artikel ja garnicht.
Trotzdem: Profinet = Siemens... Daran wird sich so schnell (leider) nichts ändern... Von daher glaube ich kaum das das OS sein wird....
Und ja, Profinet kann deshalb als Feltbus bezeichnet werden, weil er die klassischen Aufgaben analog zu Profibus oder Modbus tätigt.
http://www.hbs.honeywell.de/downloads/ExcelWeb.pdf
(noch ein Meilenstein für Linux
Hm, ein Feldbus über WLAN ? Ist sowas im Hinblick auf die Zuverlässigkeit wirklich technisch möglich ?
Ich versteh grad die Antwort auf die Frage nicht... Ist Feldbus via WLAN möglich? - Nein, Felbus= I/O-Anbindung an SPS...
Thema des Artikels: SPS-unabhängiger Profinet-Controller, basierend auf Linux.
Profinet ist Ethernet-basierend, also theoretisch wäre WLAN möglich. Ich seh eher das Problem der Geschwindigkeit. Profinet setzt ein 100MBit Ethernet vorraus, liese sich also evtl mit einem 300Mbit-WLAN realisieren... Ob das sinnvoll ist, ist eine ganz andere Frage...
Und es läuft auch der Notaus darüber ......
Es wäre interessant zu wissen (mit Link), ob so eine Not-Aus Lösung wirklich zulässig ist...
Sicher ist das also wohl schon und auch zugelassen. Aber nach einem Fehler moechte ich in so einem System nicht suchen.
Ob die Informationen schnell genug ankommen ist bei Nicht-Sicherheitseinrichtungen wohl von der Anwendung abhaengig.
Eine Verzoegerung um 500ms beim Oeffnen eines Ventils in einer Waschanlage wird wohl kaum Auswirkungen auf den Prozess haben...
klar ist sowas moeglich, aber garantiert nicht sicher, und auch nicht ueber laengere zeitraeume zuverlaessig.
http://www.codemercs.com/IOWarriorD.html