Hallo miteinander, bevor ich hier lange tippe vorab kurz gefragt, ob es hier Kundige mit Profinet gibt. Ich habe da ein paar Detailschwierigkeiten - mit Sicherheit nichts wildes - aber hier gibt's niemanden, der sich damit auskennt. Danke und Grüße M.S.
Hallo Martin, falsche Forum, bei http://www.sps-forum.de/ bist du gut aufgehoben. Ich kenne mich ein Wenig aus, fragt einfach, vielleicht kann ich helfen.
Anwender oder Entwickler? Schwierigkeiten beim theoretischen Verständnis? Man kann dir nicht sagen ob du Hilfe erwarten kannst wenn du nicht mal im Ansatz das Problem beschreibst.
:
Bearbeitet durch User
Dennis S. schrieb: > Anwender oder Entwickler? Schwierigkeiten beim theoretischen > Verständnis? Alles zusammen. > Man kann dir nicht sagen ob du Hilfe erwarten kannst wenn du nicht mal > im Ansatz das Problem beschreibst. Der Aufbau ist folgender: Ein total beschissener Univeral Robots Roboter (Gott ich sag euch, wenn Ihr das irgendwie vermeiden könnt wenn so eine Anschaffung bei euch ins Haus steht: Nehmt was gescheides!) der bisher nur MODBUS TCP konnte. Architektur ist: Server steuert über Modbus den UR-Roboter sowie zwei weitere Prüfstände, die alle zusammenhängen. Jetzt kam am Roboter ein Zukaufteil dazu (Greifer) der nur IO-Link kann. Der Vertreter sagte IO-Link wäre kein Problem, weil der UR Roboter mit der Firmwareupdate dann auch Profinet unterstützt. Also einen IO-Link-Master<>Profinet Adapter dazugekauft, und jetzt festellen müssen, dass er UR, der sich damit rühmt, eine SPS zu haben, nur ein Profinet Client ist und keine Masterfunktionalität hat. Steht nur leider nirgendwo beschrieben weil selbst nach einem Monat im Manual vom UR-Roboter kein Sterbenswörtchen von Profinet erwähnt wird. Support gibt es keinen in Deutschland, das läuft nur über die Vertriebspartner und jetzt - tada - die haben keinen blassen Schimmer, freuen sich aber natürlich darüber, dass sie jetzt erfahren, dass der UR auch Profinet kann... Der Roboter soll direkt den Greifer steuern können, weil er ja selbst die Hoheit über seine eigene Hardware haben soll. Aber damit er das kann, muss ich jetzt irgendwie den Profinet Slave auf den IO-Link Greifer bekommen. Scheinbar hilft mir der IO-Link-Master nicht in dem Maße, wie ich mir das erhofft habe. Und da suche ich jetzt nach Ideen, Anregungen oder Aufklärung. Gibt es keine Slave<->Slave Kommunikation bei Profinet? Oder anders gefragt: Gibt es keine Profinet-Master, die man nur ins Netz hängen kann, damit halt irgendein Master da ist? Ich kann doch nicht irgendeine SPS verbauen?!
Hm... Ok als ich damit gearbeitet hatte (schon etwas her), hatte ich nur Luxus! Probleme waren alles anders als deine. Martin S. schrieb: > dass er UR, der sich damit rühmt, eine SPS zu haben, > nur ein Profinet Client ist und keine Masterfunktionalität hat. Bist du hier 100% sicher? wenn ja, dann geht meine Meinung nach nicht, der Robi braucht eine Masterfunktion damit er mit seine "externe" Peripherie klar kommt. Was ist mit dem einge E/As? von Robi? eine Lösung wäre die E/As von Greifer direkt an der Kontroller von Robi anklemmen, wenn keine freie E/A mehr gibt dann MUSS 100% E/A Karten von Herteller von Robi geben. Martin S. schrieb: > Server steuert über Modbus den UR-Roboter sowie zwei > weitere Prüfstände, die alle zusammenhängen. Server? hast du kein SPS? andere Lösung wäre, die E/As von Greifer in SPS bzw. Server bearbeiten (also IO Link an SPS/Server) dann an Robi weiter sagen was er machen soll.
:
Bearbeitet durch User
Martin e. C. schrieb: > Hm... > Ok als ich damit gearbeitet hatte (schon etwas her), hatte ich nur > Luxus! Probleme waren alles anders als deine. > > Martin S. schrieb: >> dass er UR, der sich damit rühmt, eine SPS zu haben, >> nur ein Profinet Client ist und keine Masterfunktionalität hat. > > Bist du hier 100% sicher? wenn ja, dann geht meine Meinung nach nicht, > der Robi braucht eine Masterfunktion damit er mit seine "externe" > Peripherie klar kommt. Ja, wundert mich auch. Da steht allerdings im entsprechenden Menü "Profinet Device". Da bleibt er hängen, weil er keine kommunikation zum Master aufbauen kann :-/ > Was ist mit dem einge E/As? von Robi? eine Lösung wäre die E/As von > Greifer direkt an der Kontroller von Robi anklemmen, wenn keine freie > E/A mehr gibt dann MUSS 100% E/A Karten von Herteller von Robi geben. Dann hätten wir keinen IO-Link Greifer nehmen dürfen. Allerdings ist er mit E/A-Gesteuert auch ziemlich "dumm", da die ganze Repzeptverwaltung dann fehlt. Und eine UR-kompatible Version vom Greifer, die dann ein Plugin für die Oberfläche des Roboters hat, kommt erst jetzt irgendwann raus. > Martin S. schrieb: >> Server steuert über Modbus den UR-Roboter sowie zwei >> weitere Prüfstände, die alle zusammenhängen. > > Server? hast du kein SPS? Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu machen. Wir haben keine zeitkritischen Abläufe, der Server gibt über Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der allerdings in der Steuerung des Roboters hinterlegt ist. Normalerweise sind diese UR ja auch als stand-alone Geräte konzipiert. Dass dann aber elementare Steuerfunktionen fehlen hätte ich nicht erwartet... wobei ich von dem Teil inzwischen gar nichts mehr erwarte. Hätten wir doch nur Kuka oder ABB oder Mitsubishi oder .... genommen. Da kostet das Teil zwar in der Anschaffung das Doppelte, dafür habe ich ein technisches High-end Gerät mit Toleranzen um den Faktor 10 besser und wirklich extrem guten Support, der auch bei der Projektierung hilft. So versuchen wir jetzt alles von der Pike auf selbst uns beizubringen. Worin das endet, sieht man ja jetzt... > andere Lösung wäre, die E/As von Greifer in > SPS bzw. Server bearbeiten (also IO Link an SPS/Server) dann an Robi > weiter sagen was er machen soll. So haben wir es jetzt mit dem alten Greifer. Aber das ist extrem umständlich, weil man fragmentierten Code bekommt. Daher wollte ich ja auch den Greifer am Roboter haben.
Es ist in der Industrie üblich, das Roboter sich extern als Device darstellt. Dieses kann dann von einer übergeordneten Steuerung angesprochen werden und so quasi mehrere Roboter von einer Steuerung koordiniert werden. Vermutlich unterstützt das Ding deswegen nur Device. Die Roboter haben dann meistens ein internes Bus-System um Ihre eigenen Peripherien zu steuern. Das kann z.b. auch ein Profinet System sein, bei dir ist es wohl Modbus. Wenn ich das richtig verstehe gehört der Greifer ja zum Roboter selbst, ist dann Topologisch eigentlich eher am Internen Bus des Roboters anzusiedeln. Bekommst Du überhaupt die Steuerbefehle für den Greifer über das Device Interface des Roboters nach draußen? Möglicherweise wäre es sinnvoller gewesen einen Modbus auf IO-Link Adapter zu nehmen, weis aber nicht ob es sowas gibt. Was Du machen könntest wäre eine billige Profinet Steuerung zu kaufen, mit dieser den Roboter und den Profinet-IO-Link Adapter anzusprechen und dann die Steuerung die Daten von dem Roboter auf den Adapter spiegeln zu lassen. Dafür reicht vermutlich jede Siemens Steuerung aus. An Deiner Stelle hätte ich eine Siemens CPU mit Rückwandbus genommen (Die kann Profinet Master) und and den Rückwandbus ein IOLink Master Modul gesteckt. https://mall.industry.siemens.com/mall/de/WW/Catalog/Product/6ES7510-1DJ01-0AB0 https://mall.industry.siemens.com/mall/de/WW/Catalog/Product/6ES7137-6BD00-0BA0 (Ich arbeite übrigens nicht bei Siemens, mache aber den ganzen Tag Profinet)
Hallo Andreas, vielen Dank für Deinen Rat. Problem ist, dass diese Modbus<->IO-Link Geschichten wohl nicht das Gelbe vom Ei sein sollen. Man macht schlussendlich einen riesen Spagat. Das nächste Projekt wird eine SPS bekommen - so schlau ist man offensichtlich schon und auch dieses wird umgestellt werden. Man will jetzt halt erstmal produzieren können, sonst liegt der Aufbau noch länger brach. Doch wie heißt es so schön: Nichts hält länger als ein Provisorium. Aber um das nochmal zu verdeutlichen, wie das normalerweise abläuft: - Zwei Profinet-Devices dürfen nur über einen Switch miteinander verbunden werden, es sei denn, sie haben einen integrierten Switch. - Im Profinet braucht es immer einen Master/Server - Die Parametrisierung von Profinet-Devices läuft immer über einen Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte + Supervisor-Software?) - Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt (vorher haben sie ja auch noch gar keine IP, oder?) - Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal nichts von denen. Der Server muss also die Topologie kennen, oder? - Die Datenübertragung zwischen Devices wird über den Server/Master abgearbeitet, oder? Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen? Quasi eine Master+Supervisor-Software?
Martin S. schrieb: > - Die Parametrisierung von Profinet-Devices läuft immer über einen > Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte > + Supervisor-Software?) Kommt etwas drauf an, was du mit Parametrierung meinst. Die Taufe (Zuweisung des Profinet-Stationsnamens) und die Auswahl der Prozessdatenmodule erfolgt im Regelfall über die Projektierungsumgebung deiner Steuerung (Step7/TIA bei Siemens, Twincat bei Beckhoff, etc.). Je nach Gerät kann die Steuerung während Betriebs dann aber natürlich noch Geräteparamter ändern (über die Busverbindung). > - Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt > (vorher haben sie ja auch noch gar keine IP, oder?) Profinet-Geräten wird keine IP zugewiesen, nur ein Stationsname. Die IP bekommen die Geräte dann während des Profinet-Startups von Master zugewiesen. > - Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal > nichts von denen. Der Server muss also die Topologie kennen, oder? Ne, Topologie muss nicht bekannt sein. Der Bus kann gescannt werden, um die Geräte zu finden. > - Die Datenübertragung zwischen Devices wird über den Server/Master > abgearbeitet, oder? Was du mit (direkter) Datenübertragung zwischen Devices/Slaves meinst wird in der Feldbustechnik im allgemeinen Querverkehr genannt. Wie das bei PN aber genau aussieht weiß ich momentan nicht. > Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen? > Quasi eine Master+Supervisor-Software? Ja, es Profinet-Master auch in Software von diversen Herstellern.
:
Bearbeitet durch User
Zu den Begrifflichkeiten: Profinet ist keine Master/Slave-, sondern ein Producer-Consumer-System : Beim Hochlauf übermittelt der IO-Controller den Devices die Konfiguration die vorher im Engineering-Tool festgelegt wurde. Dazu gehört zum Beispiel der Stationsaufbau (bei modularen Devices) sowie die SendCycle. Nach dem ApplicationReady von seiten des Devices arbeitet das System autark. Es gibt kein Token oder Polling oder Request/Response-Verfahren währed des Prozessdatenaustauschs. Ein Datenquerverkehr zwischen den Devices ist möglich wird aber nicht immer unterstützt. Stichwort zum Suchen ist MCR. Der Supervisor hat im Wesentlichen die gleichen Funktionen wie ein Controller. Einige wenige Unterschiede gibt es beim gleichzeitigen Zugriff auf ein Device. IO-Devices haben durchaus eine IP-Adresse und bekommen diese häufig (aber nicht ausschließlich) vom Controller beim Startup zugewiesen. Auch dies ist im Engineering-Tool einstellbar. Der NameOfStation dient der Adressauflösung und unter anderem der Nachbarschaftserkennung via LLDP. Da ich Robotik gelesen habe: eine alternative Startup-Form ist Fast-Startup bei der nach AIDA-Empfehlung nach 500ms ein Ausgang gesetzt werden können soll. Gruß Dennis
Martin S. schrieb: > Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar > nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu > machen. > Wir haben keine zeitkritischen Abläufe, der Server gibt über > Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der > allerdings in der Steuerung des Roboters hinterleg Ich hatte bis jetzt in diese konstellation nie gehabt/gehört, natürlich ist alles möglich, besonders an der Uni's wird ähnliches gemacht und getestet ob es sinn macht ist wieder anders. So eine "eventuelle" günstiger Lösung kommt am Ede viel teuer, da bei Erweiterungen nicht flexibel ist. Vielleichts kommst du jetzt auf ein SPS nicht herum, wäre eventuell günstiger als ers alles mögliche zu probieren. In diesem Fall muss man sicher sein dass dein Robi oder die Profinet Karte von Robi sowie die IO Link Greifer von SPS problemlos angesprochen werden können (liegen die GSD Dateien vor?), dann nimmst du beide Teilnehmer in SPS und schiebst du die Daten zwischen Robi und Greifer hin und her. Dominik S. schrieb: > Ne, Topologie muss nicht bekannt sein. Der Bus kann gescannt werden, um > die Geräte zu finden. Bei paar Teilnehmer nicht, bei mehrere macht natürlich sinn da die Telegramme sauber zu jeder Teilnehmer kommen, bei Zeit kritische Anwendungen sowie so.
:
Bearbeitet durch User
Martin e. C. schrieb: > Bei paar Teilnehmer nicht, bei mehrere macht natürlich sinn da die > Telegramme sauber zu jeder Teilnehmer kommen, bei Zeit kritische > Anwendungen sowie so. Falls es um PROFINET geht ist das so nicht richtig.. die Sende- und Empfangszeiten werden werden im ConnectFrame vom Controller an die Devices gegeben. Erst bei IRT (also RTC-Class 3) ist die Topologie wirklich wichtig. Aber das ist für den TO ja sowieso nicht relevant. Gruß Dennis
Martin e. C. schrieb: > Martin S. schrieb: >> Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar >> nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu >> machen. >> Wir haben keine zeitkritischen Abläufe, der Server gibt über >> Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der >> allerdings in der Steuerung des Roboters hinterleg > > Ich hatte bis jetzt in diese konstellation nie gehabt/gehört, natürlich > ist alles möglich, besonders an der Uni's wird ähnliches gemacht und > getestet ob es sinn macht ist wieder anders. Wie macht man das dann typischerweise? Das Problem ist hier schlichtweg, dass man für den UR keine Leute bekommt. Also müssen wir alles selbst machen und uns fehlen auch jegliche Erfahrungswerte. Wie wird es denn sonst gemacht? > So eine "eventuelle" > günstiger Lösung kommt am Ede viel teuer, da bei Erweiterungen nicht > flexibel ist. Wer hätte das gedacht? Also ich hab sowas "nie prophezeit"... Ich treffe halt die Entscheidungen nicht, sonst wäre es ganz anders gelaufen. > Vielleichts kommst du jetzt auf ein SPS nicht herum, wäre eventuell > günstiger als ers alles mögliche zu probieren. > In diesem Fall muss man sicher sein dass dein Robi oder die Profinet > Karte von Robi sowie die IO Link Greifer von SPS problemlos angesprochen > werden können (liegen die GSD Dateien vor?), dann nimmst du beide > Teilnehmer in SPS und schiebst du die Daten zwischen Robi und Greifer > hin und her. Genau das war der Plan - nur ohne SPS. Leider scheiterte er. Ich muss nochmal Rückfrage mit Zimmer halten, die wollten einen reinen UR-Greifer auf den Markt bringen. Vllt. hat sich da ja mittlerweile was getan.
Martin S. schrieb: > Wie macht man das dann typischerweise? Das Problem ist hier schlichtweg, > dass man für den UR keine Leute bekommt. Also müssen wir alles selbst > machen und uns fehlen auch jegliche Erfahrungswerte. > > Wie wird es denn sonst gemacht? Ich hatte nur mit Automobil Industrie zu tun gehabt und obwohl auch viel viel geforscht wird, ist Typischerweise fast jede konstellation so: Ein SPS (Master) und jeder menge Teilnehmer (Slaven), entspricht Stationen, Roboter usw. Ein Roboter ist Slave von SPS aber Master von seine Teilnehmer wie z.B. Greifer, Zangen, Kappenfräser, etc. Sehr selten aber möglich waren Greifer (E/A Module) Slaves von SPS. Das alles Unabhängig von Bussystem. Die "übliche" Robotern und SPS'en können Profibus und Profinet.
Hallo Martin, war leider etwas abwesend. Zusammenfassend zu deinen Fragen, es gab ja schon eine ganze Menge richtig Antworten Martin S. schrieb: > Aber um das nochmal zu verdeutlichen, wie das normalerweise abläuft: > > - Zwei Profinet-Devices dürfen nur über einen Switch miteinander > verbunden werden, es sei denn, sie haben einen integrierten Switch. Genau, ein Hub ist in einem Profinet Netzwerk nicht zulässig. (Die Geräte erkennen das und verweigern den Datenaustausch). Die allermeisten Profinetgeräte haben jedoch einen Integrierten Switch mit mindestens zwei Ports. > - Im Profinet braucht es immer einen Master/Server Genau. Nur ein Master (Im Profinet Sprachgebrauch Controller - Master /Slave wollte man tatsächlich wegen der Nähe der Begriffe zu Sklaverei nicht verwenden) kann aktiv eine Verbindung zu einem Slave (Bei Profinet "Device") aufbauen. Dieser Controller überträgt beim Verbindungsaufbau sämtliche Parameter in das Gerät. (Bei jedem Hochlauf erneut) > - Die Parametrisierung von Profinet-Devices läuft immer über einen > Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte > + Supervisor-Software?) Nein. Die Parameter die ein Gerät benötigt werden im Controller gespeichert. Diese werden dann beim Hochlauf vom Controller in das Device übertragen. Das einzige was man machen muss ist die sogenannte Gerätetaufe. D.h. die Bus Addresse des Profinet-Gerätes wird im Gerät permanent gespeichert ( so das bei Strom aus/an die addresse erhalten bleibt). Taufe deswegen, weil bei Profinet die Addresse des Geräts der Stationsname ist. Dafür bietet dann meist jeder Controllerhersteller ein eigenes kleines Tool an, man kann mit jedem solchen Tool jedes Profinet Device taufen, da das Protokoll standardisiert ist. Achtung: Neben dem Stationsnamen haben Profinet Geräte auch noch eine IP Addresse. Diese wird normalerweise jedoch vom Profinet Controller beim Hochlauf mit eingestellt. Das was Du mit Supervisor meinst, heist bei Profinet "Engineering Software". Mit dieser nimmt man einmalig sein System in Betrieb, programmiert meist die PLC/Controller. Danach benötigt man diese nicht mehr, höchstens um mal Fehlerdiagnose zu machen. z.B. Step 7/TIA Portal, 3S Codesys (wobei das auch selbst eine PLC sein kann), PC Worx. (Supervisor gibt es bei Profinet übrigens auch, das ist ein Controller mit speziellen Rechten) > - Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt > (vorher haben sie ja auch noch gar keine IP, oder?) Im Prinzip ja. Der Hochlauf ist in mehrer Phasen aufgeteilt: - Zuweisung IP Addresse - Abgleich Soll/Ist Konfiguration, d.h. der Controller sendet was er im Device erwartet, und das Device vergleicht dass mit seiner Ist-Konfiguration und meldet eventuell Unterschiede - Der Controller überträgt alle Parameter an das Device (z.B. ADC Wertebereiche, Kurzschlussbegrenzungswerte....) - Das Device wendet die Parameter an und Signalisiert "application ready" - Danach beginnt dann der Prozessdatenaustausch > - Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal > nichts von denen. Der Server muss also die Topologie kennen, oder? Nein, der Controller muss nur die Namen der Geräte kennen. Wo die Geräte physikalisch verbunden sind ist erst mal egal, dae in ganz normales ethernet netzwerk aufgebaut wird. Man kann problemlos PCs mit anschließen oder sogar PC Netzwerkverkehr durch die Geräte hindurch transportieren. (Wenn man synchrones Profinet machen will gibt es da allerdings ein paar Einschränkungen) > - Die Datenübertragung zwischen Devices wird über den Server/Master > abgearbeitet, oder? Beim Profinet sendet jeder Teilnehmer aktiv seine Daten zum Empfänger. Welche Daten zu senden sind und wohin diese zu senden sind wird vom Controller beim Hochlauf in das Device parametriert. Der Empfänger der Daten hat typischerweise ein Timeout mit dem er den Sender überwacht. Prinzipiell gibt es auch möglich Daten zwischen zwei Devices auszutauschen, jedoch können das nur wenige Devices. Aber selbst bei diesem Szenario benötigt man einen Controller, dieser muss nämlich beiden Devices sagen das sie miteinander sprechen sollen. > Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen? > Quasi eine Master+Supervisor-Software? Prinzipiell kann man einen Profinet Controller auch in Software auf einem PC laufen lassen, da es eben ganz normales Ethernet ist. Allerdings muss man sich hier Gedanken über Echtzeit machen, damit der PC die Telegramme schnell genug generiert. (Kleinster Profinet Sendtakt ist 4 ms, den kann man nochmals untersetzen, das können aber nicht alle Devices; Der Windows-Scheduler hat ein Takt von 10ms, ist also eigentlich schon zu langsam) Was es noch gibt sind z.B. PC-Einsteckkarten, die als Master fungieren können. Diese sind aber meist teurer als eine Kleinsteuerung.
Vielen Dank an Dich und an den Rest für die teils sehr umfangreichen Antworten. Ich fasse zusammen: 1) Wenn Menschen Entscheidungen über Dinge treffen, von denen sie keine Ahnung haben, kommt nur Schrott dabei heraus. 2) Wenn man so ein Projekt lostritt, dann richtig, oder gar nicht. Halbheiten bringen nur Ärger. 3) Damit das IO-Link-Device überhaupt laufen kann brauche ich jetzt noch einen Profinet-Master in Form einer SPS. Ohne SPS, ohne Profinet. 4) Für so ein Projekt keine SPS eingesetzt zu haben, war eine katastrophale Fehlentscheidung (wie ich finde). Na dann weiß ich jetzt mal, woran ich bin und muss mir jetzt eine Lösungsstrategie entwickeln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.