,.,.,.,.,.,.
Druckbare Version
,.,.,.,.,.,.
Was ist ein "Bildgebender Sensor"? Wenns eine Videokamera mit entsprechender Auflösung ist brauchst Du ein sehr schnelles Bussystem und / oder eine passende Komprimierung.
Ein elektronischer Sensor als solches ist erstmal ein Baustein, oder ein Platine die einen physikalischen oder chemischen Wert in ein elektrisches Signal wandelt.
Heuzutage gibt es Sensoren für sehr viele Größen. Von der Temperatur über Gewichte bis hin zu PH Sensoren.
Allerdings gibt der Sensor selber oft nur eine Spannung, einen A/D Wandlerwert, oder eine Frequenz aus.
Um die gemessenen Werte auch tatsächlich in einer Steuerung nutzen zu können, brauchst Du eine Adaption.
Du möchtest also den Profibus verwenden.
Dazu muss zwischen den Sensor und dem Bussystem einen Protokoll Stack, sowie die Anbindung an die physikalische Verbindung reingebaut bzw. programmiert werden.
Physikalisch wird hierbei für Kupferadern das Protokoll EIA-485 verwendet.
Ich kenn das Bussystem jetzt nicht so gut. Vermutlich wirst Du den Sensor, einen Microcontroller und einen Bustreiber für jeden Sensortyp brauchen.
Soweit ich in Wikipedia gelesen hab ist die maximale Datenrate auf Kupfer 12MBit. Wie groß dann die Reichweite wird, ist wieder ne andere Frage.
Eventuell bekommst Du auch fertige Sensoren mit integriertem Schnittstellenwandler für den Profibus.
Einen optischn Sensor hab ich z.B. hier: http://www.automation.siemens.com/mc...tc=wwiia303560 gefunden.
Eine tatsächlich gleichzeitige Auswertung der 3 Sensorsignale ist mit ziemlicher Sicherheit nicht möglich. Wohl aber innerhalb eines zeitlichen Rahmens.
Du hast Laufzeiten auf dem Bus, es kann ja immer nur ein Signal darüber geschickt werden. Zudem braucht auch der Steuerrechner Zeit um auf die empfangenen Telegramme reagieren zu können. Wenn's tatsächlich absolut gleichzeitig passieren muß, bleibt dir nur der Weg über diskrete oder programmierbare Logik ( einzelne Chips oder FPGA ). Und alle Sensoren müssen direkt an die Logik angebunden sein.
Du schreibst alles sehr vage. Da kann man entweder mit einer mehrseitigen Vorlesung oder eben fast gar nicht antworten.
Versuch die Aufgabe in mehrere einzelne Teilaufgaben zu zerlegen.
Welcher Steuerrechner?
Welches Bussystem - Betriebsparameter - Topologie?
Passende Sensoren - Fertig oder Eigenentwicklungen?
Ausgehend vom Sensor mit dem meisten Datenaufkommen, über den Bus, der diese Daten ja übertragen muß, zum Steuerrechner, der die Daten auswerten und auch wieder Reaktionen auslösen muß ( Rechenleistung ? ).
So solltest Du auf eine Lösung kommen.
Das ist im Prinzip in jedem PC bereits realisiert:Zitat:
An diese sollen dann beispielsweise ein bildgebender Sensor, ein Temperatursensor und ein taktiler Sensor angeschlossen werden. Die Daten von den drei Sensoren sollen dann gleichzeitig ausgeweret werden. Ist das technisch realisierbar?
Bildgebend: Webcam
Temperatur: intern vorhanden um die Chips zu schützen
Taktil: Tastatur, Maus
Das mit der Gleichzeitigkeit ist natürlich relativ, ein Computer macht alles schön nacheinander, dafür so schnell, dass man meint es wäre gleichzeitig. Wenn man hohe Anforderungen an Echtzeit hat, wird man eher keinen PC verwenden.
Das dürfte wohl prinzipiell mit jedem Bussystem so sein. Man wird aber nur in Ausnahmefällen Sensoren finden, die man direkt an den Bus anschließen kann. Primär haben die meisten Sensoren ein analoges Ausgangssignal, das eher vom Sensortyp als vom Hersteller abhängt. Das Signal muss dann aufbereitet (z.B. verstärkt), digitalisiert und über eine Schnittstelle an den Bus angeschlossen werden. Der Profibus stammt wohl aus der Prozessautomatisierung, da sollte solche Hardware verfügbar sein.Zitat:
... wollte ich den PROFIBUS verwenden. Weil dieser laut Literatur Sensoren unterschiedlicher Hersteller miteinander verbinden kann.
Verrätst Du uns bitte noch, was Du studiert hast, damit wir Dein Vorwissen besser einschätzen können (es langweilt mich, jemanden in 5 Sätzen etwas zu erklären, was er schon weiss).
,.,.,.,..,.,.,
1234567890
Tut mir leid, ich bin da eher der Praktiker.
Das mit der Adaption der Sensoren auf ein Bussystem hast Du richtig erkannt.
Einen Treiber für jeden einzelnen Sensor brauchst Du eigentlich nicht.
So wie ich das sehe ist der Sensor mit dem höchsten Datenaufkommen die CCD Kamera.
Es wäre also zu überlegen, ob man diese nicht auf ein Bussystem legt, sondern direkt mit dem Bildverarbeitungsrechner verbindet.
Das bedeutet aber, das dein Steuerrechner nicht allzu weit von den Kameras entfernt sein sollte oder man ein Medium verwendet, das die benötigte Reichweite und Datendurchsatz bringt.
Da Du in deinem System auch sehr aufwendige Routinen wie z.B. eine Bildverarbeitung einfügen musst, brauchst Du einen potenten Rechner.
Also PC oder Linux Maschine. Ne SPS wird das wohl nicht mehr schaffen.
Für den Rest der Sensoren und Aktoren sollte dann dein Bussystem ( Profibus ) schnell genug sein.
Um Kosten zu sparen könnte man auch mehrere Sensoren an einen Schnittstellenumsetzer vorsehen.
Warum muß jeder Schalter einen eigenen Umsetzer kriegen ? Man könnte ja Module mit z.B. 8 Eingängen vorsehen, an die man dann eben bis zu 8 Schalter anschließen kann, wenns räumlich passt.
Einen Treiber in seiner eigentlichen Funktion wirst Du wohl für die Kamera - Ich würde 2 davon verwenden um auch eine Tiefeninformation zu kriegen - und das Profibus PC Interface brauchen.
Für das Profibus Protokoll selbst wirst Du schon eher eine Protokoll Suite brauchen.
So wie ich das sehe ist der Profibus ein adressiertes Sytem mit Source und Destination Adressen. Zusätzlich gibt es da einen Function Code, der wohl den Inhalt der Nachricht definiert.
Du benötigst also eine Tabelle in der drinsteht Source Adresse X Datentyp Y bringt 3 Datenbytes mit "dieser" Bedeutung und Einheit. Das würde ich dann als Protokoll Suite bezeichnen.
Das Zusammen mit den Daten aus Deiner Kamera wird verarbeitet. Das Ergebnis wird dann in Steuerbefehle für deine Aktoren umgerechnet und wieder auf das Bussystem gelegt.
Als Sicherungsmassnahmen kannst Du Quittungskreisläufe einbauen.
Auch ein unabhängiger "Watchdog" Rechner, der zusätzlich am Bussystem hängt und den Datenaustausch überwacht wäre eine Option.
Guck Dir in diesem Zusammenhang auch mal das OSI Schichtenmodell an.
Sehr viele der neueren Bussysteme orientieren sich daran.
Alle verwendeten! Schichten müssen entweder als Hardware oder in Software realisiert sein.
Den aufwendigsten Teil dieser Aufgabe sehe ich bei der Bildanalyse. Du musst ja die einzelnen Objekte Greifer, Ware, Paletten, Hindernisse erkennen und dann mit deinen Aktoren entsprechend reagieren.
Da es aber mal vorerst nur ein Baukasten ist wird das wohl nicht dein Problem sein.
,.,.,..,.,.,.,.