Wir haben Profibus nicht verwendet, aber wir haben DeviceNET (ein weiteres CAN-basiertes Protokoll), Ethernet/IP y ControlNet die alle ähnliche Herausforderungen haben.
Wir machen das seit den späten 1990er Jahren und verlassen uns daher hauptsächlich auf unseren selbst erstellten Code unter Verwendung von Standard-Hardware. Die Unternehmen, die in diesem Zeitraum Langlebigkeit bewiesen haben, sind meiner Erinnerung nach: -
- AnyBus (HMS, www.anybus.com ) haben wir vor kurzem begonnen, ihre Gateway-Produkte zu verwenden, da wir Feldbusschnittstellen in der Nähe der Hardware platzieren und dann über normales Ethernet kommunizieren können (normalerweise über Ethernet/IP www.odva.org ). Dies hat den Vorteil, dass Hardware und PC nur durch ein Netzwerkkabel getrennt sind. Die Ethernet/IP .NET-Klassen wurden von uns selbst geschrieben, da zu dieser Zeit nicht viel auf dem Markt war. Ich bin sicher, dass eine schnelle Google-Suche geeignete Klassenbibliotheken finden würde
- SST ( www.mysst.com ) verfügen seit mehr als einem Jahrzehnt über Feldbusschnittstellen. Die letzte SST-Karte, die wir für DeviceNET verwendet haben, hatte nur noch VB6-Beispielcode. Eine gute Auswahl an Feldbusunterstützung und verschiedene Formfaktoren, z.B. PC104, PCI, PMCIA
- Beckhoff/Wago ( www.beckhoff.com , www.wago.com ) verwenden wir Beckhoff in der Regel eher für die E/A als für die Schnittstellenkarten, aber auch hier handelt es sich um ein Unternehmen, das schon seit langem existiert. Sie haben auch Produkte, die OPC unterstützen (eine weitere Möglichkeit, E/A-Informationen zu erhalten, ohne direkt mit der Hardware/den Gerätetreibern zu kommunizieren).
Ich schlage vor, keine OPC-Schnittstellen zur Hardware direkt zu verwenden (es ist OK für die Kommunikation über PC (.NET)->PLC->Profibus), da Sie sicherstellen müssen, dass das Steuersystem auf den Verlust der Kontrolle durch Ihre .NET-Anwendung reagiert. Ich gehe davon aus, dass Sie hier einen Profibus-Master (und keinen Slave) benötigen. Solange Ihr Steuersystem an sich ausfallsicher ist, sollte ein Kommunikationsverlust bedeuten, dass das Steuersystem in einen "Leerlauf"-Zustand übergeht und daher die meisten E/A in den ausfallsicheren Zustand zurückkehren.
Wir versuchen auch sicherzustellen, dass wir keinen sicherheitsrelevanten Code in .NET einfügen. Der größte Teil unseres .NET-Codes ist eine Benutzerschnittstelle von einer SPS, aber an einigen Stellen steuern wir den Feldbus direkt, stellen aber sicher, dass Hardware-Verriegelungen einen unsicheren Betrieb verhindern, entweder mit Sicherheitsschaltern/Relais oder einer kleinen SPS, die nur die Aufgabe der Verriegelung hat. Und vor allem: Machen Sie das System ausfallsicher! Wenn die Kommunikation mit dem .NET-Code ausfällt, sollte die Automatisierung in den ausfallsicheren Zustand versetzt werden.
