Movisuite Fernzugriff

AutismPrime95

Level-2
Beiträge
58
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo alle miteinander,

momentan bearbeite ich mein erstes Projekt mit der Movisuite und würde gerne wissen wie es möglich ist mit Fernzugriff den Status jeden einzelnen Umrichters(in der Movisuite) aufrufen zu können. Vorallem ist es mir wichtig den Fehlerspeicher auslesen zu können.

Hat jemand damit schon Erfahrungen gemacht und kann mir vielleicht weiterhelfen?
 
Hallo @AutismPrime95,

Hängen die einzelnen Umrichter an einer SEW MoviPLC, so kann das Routing und Engineering komplett über diese Steuerung erfolgen.
Dem Engineeringport kann eine beliebige IP/SN vergeben werden, womit eine Integration in das gewünschte Netzwerk möglich ist.

Handelt es sich um Einzelgeräte, so kann über die Feldbusschnittstelle (z.B. Profinet oder Ethercat) ein Zugriff erfolgen.
Falls du im Detail fragen zu dem Thema hast, gerne bei uns telefonisch melden:

+49 7251 75 1780

Gruß SEW Service
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin AutismPrime95,

ich was hast Du für ein Fernwartungszugang? Welche Geräte kannst Du erreichen?

Bei uns ist das Problem, dass wir keinen Fernwartungszugang in das Profinet, sondern in das übergeordnete Anlagennetz haben. Damit erreichen wir die angeschlossenen Steuerungen, aber erstmal nicht die Umrichter.
Dafür muss man vom überlagerten „Fernwartungsnetz“ in das Profinet routen.
Allerdings akzeptiert nicht jeder Kunde aus SecurityGründen das Durchrouten in das Profinet.

Zuletzt haben wir (wir nutzen eine S7-1515…) das Routing über das IP-Forwarding von einer Schnittstelle der CPU zur anderen realisiert. Ist aber auch nicht soooo easy. Der Umrichter braucht die CPU-IP als Routeradresse, in der CPU muss das IP-Forwarding aktiviert sein. Jetzt muss noch auf Deinem Rechner für die Rechnerschnittstelle eine Route hinzugefügt werden bzw. es muss im VPN-Server des Kunden eine Route hinzugefügt werden (akzeptiert nicht jeder Kunde)…

Man sollte meinen, dass der Zugriff auf die Umrichter heutzutage quasi „state of the art“ ist. In der Praxis aber nicht immer (schon gar nicht immer gleich) umsetzbar.

VG

MFreiberger
 
Ich habe einen Fernwartungszugang auf die Master CPU in der Anlage und auf alle anderen Profinet-Teilnehmer, Anlagenrechner etc.

Mit dem Kunden ist alles abgeklärt und wir haben eben nur Zugriff auf unsere Anlage. Diese hat ihren eigenen IP-Bereich und nur da kommen wir drauf. Auch die SEW Motoren sind in diesem Bereich.

Was ich eben nicht verstehe, ich bin mit der SPS verbunden und kann trotzdem nicht mit der Movisuite auf die Motoren zugreifen.

Edit: Es gibt keine SEW MoviPLC, nur Einzelgeräte im Profinet.
 
Ich habe einen Fernwartungszugang auf die Master CPU in der Anlage und auf alle anderen Profinet-Teilnehmer, Anlagenrechner etc.
Ist denn die Master CPU auch ein Profinet-Teilnehmer (und wenn ja, warum) oder habt ihr einfach Industrial Ethernet und Profinet gemischt im Netzwerk?
Kannst Du mal Screenshots von der Topologie und der Netzansicht zeigen? Wenn Teilnehmer nicht in der Topologie auftauchen, wäre es interessant, wenn man hier ggf. den Schaltplan oder was Handschriftliches hätte.

Mit dem Kunden ist alles abgeklärt und wir haben eben nur Zugriff auf unsere Anlage. Diese hat ihren eigenen IP-Bereich und nur da kommen wir drauf. Auch die SEW Motoren sind in diesem Bereich.
Der Anlagenrechner ist ein Teil Eures Netzwerkes? Ansonsten keine weiteren Teilnehmer?

Was ich eben nicht verstehe, ich bin mit der SPS verbunden und kann trotzdem nicht mit der Movisuite auf die Motoren zugreifen.
<Klugschiß> Mal abgesehen davon, dass mit der Movisuite nicht auf die Motoren, sondern auf die Umrichtertechnik zugegriffen wird: </Klugschiß>
Kannst Du die Umrichter anpingen?

Edit: Es gibt keine SEW MoviPLC, nur Einzelgeräte im Profinet.
Danke für die Info. Profinet und Serviceschnittstelle sind (zumindest war das bei der MoviAxis so) aber zwei verschiedene Paar Schuhe...
Wie sieht das bei der MoviC aus? Gibt es noch die separate ServiceSchnittstelle?

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube mein Chef haut mir auf die Finger wenn ich diese hier öffentlich mache. Im Prinzip gehen wir von der CPU (die auch ein Profinet-Teilnehmer ist) auf mehrere Switches und dann zu den anderen Teilnehmern, Interfacemodule, Umrichter usw. Hier handelt es sich um eine CPU 1516F-3.

Ja Profinet und Industrial Ethernet sollten gemischt sein, da ja der Anlagenrechner Teil unseres Netzwerkes ist.

Der Klugschiß ist gar nicht so verkehrt, natürlich geht es um die Umrichter :D
Ich kann die Geräte anpingen, aber nur wenn ich mich explizit mit ihrer IP verbinde, ansonsten können sie auch angesprochen werden, allerdings mit Paket-Verlusten.

MoviC habe ich ehrlich gesagt gar nicht verwendet, die Umrichter wurden in Gänze mit der MoviSuite eingerichtet.
Meines Wissens nach, besitzen die Umrichter nur die Profinet Schnittstelle. Service Schnittstelle habe ich keine entdeckt.
Bei den Motoren handelt es sich um die Reihe Movimot advanced mit integriertem Umrichter am Motor selbst.

Ich denke dafür benötige ich auch einen bestimmten Port um auf diese zugreifen zu können. Mit dem 102 Simatic Port kann ich mich mit dem TIA Online verbinden, also gehe ich davon aus das hierfür ein anderer verwendet werden muss um mich in der MoviSuite Online zu schalten.
 
Hallo @AutismPrime95,

Wenn dein Engineering Rechner mit installierter Movisuite im Profinet-Netzwerk steckt, dann kann Movisuite die einzelnen SEW Teilnehmer finden.
Idealerweise der lokalen Netzwerkschnittstelle eine freie IP im Adressbereich des Profinet-Netzwerkes vergeben.
Movisuite verwendet die Netzwerports 300-310. Diese sollten in deiner/den Firewalls freigeschaltet sein.

Zusatzinformation zum Thema IP Forwarding bei Siemens Steuerungen:

Falls der Rechner über die Siemens Steuerung auf das Profinetnetzwerk zugreift und die Steuerung somit in zwei verschiedenen Netzwerken platziert ist, wäre eventuell IP-Forwarding eine Möglichkeit.
Die Funktion IP-Forwarding aktiviert/deaktiviert man in TIA-Portal V16.
Wenn IP-Forwarding aktiviert ist, dann leitet die S7-1500 CPU empfangene, nicht an die CPU adressierte IP-Pakete an lokal angeschlossene IP-Subnetze weiter, bzw. an einen konfigurierten Router.
Das folgende Bild zeigt, wie ein PC mit MOVISUITE auf Daten eines MOVIDRIVE-C Technology zugreift.
Der PC und der Antriebsumrichter MOVIDRIVE-C befinden sich in unterschiedlichen IP-Subnetzen.
Die IP-Subnetze sind an die beiden Schnittstellen X1 und X2 der CPU angeschlossen.

1667380777812.png


Voraussetzungen für die Nutzung von IP-Forwarding sind:
  • S7-1500 CPU ab Firmware-Version V2.8
  • Anzahl Ethernet-Schnittstellen: Die CPU besitzt mindestens 2 Ethernet-Schnittstellen oder die CPU besitzt eine Ethernet-Schnittstelle und ein CP 1543-1 ab Firmware-Version V2.2 stellt die andere Ethernet-Schnittstelle zur Verfügung. In diesem Fall muss die Funktion "Zugriff auf PLC über Kommunikationsmodul" in der CPU für den CP aktiviert sein.
  • IP-Forwarding ist aktiviert.
  • In jedem beteiligten Gerät entlang des Hin- und Rückwegs der IP-Pakete sind passende Default-Gateways/Routen parametriert. Dies kann im Parameterbaum des jeweiligen Gerätes durchgeführt werden:
    1667381114018.png

Gruß SEW Service
 
Zuletzt bearbeitet:
Mit Engineering Rechner ist jetzt mein Rechner mit dem ich selbst arbeite oder mein Anlagenrechner im Profinet gemeint? Sorry ich habe bis jetzt diesen Begriff noch nie gehört.

Ich verbinde mich dann aber trotzdem mit meiner CPU über diese Ports oder muss ich dann die Adresse der Umrichter wählen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MoviC habe ich ehrlich gesagt gar nicht verwendet, die Umrichter wurden in Gänze mit der MoviSuite eingerichtet.
Also "MoviC" ist die Umrichtergeneration. "MoviSuite" ist das EngineeringTool.

Mit Engineering Rechner ist jetzt mein Rechner mit dem ich selbst arbeite oder mein Anlagenrechner im Profinet gemeint?
Der Engineering (Ingenieurwesen / Technik meint: das Programmieren/Projektieren der Technik) findet auf dem Rechner statt, auf dem die MoviSuite installiert ist und von dem aus die Umrichter projektiert und supportet werden.
Was ist der "Anlagenrechner"? Meinst Du eine Visualisierung für die Anlage? Der ist dann nicht gemeint.

Wenn dein Engineering Rechner mit installierter Movisuite im Profinet-Netzwerk steckt, [..]
So soll es ja anscheinend sein. Aber es konnte noch nicht verifiziert werden, ob es so ist bzw. ob der Umrichter (per Ping) erreichbar ist.
 
Zusatzinformation zum Thema IP Forwarding bei Siemens Steuerungen:

Falls der Rechner über die Siemens Steuerung auf das Profinetnetzwerk zugreift und die Steuerung somit in zwei verschiedenen Netzwerken platziert ist, wäre eventuell IP-Forwarding eine Möglichkeit.
Die Funktion IP-Forwarding aktiviert/deaktiviert man in TIA-Portal V16.
Wenn IP-Forwarding aktiviert ist, dann leitet die S7-1500 CPU empfangene, nicht an die CPU adressierte IP-Pakete an lokal angeschlossene IP-Subnetze weiter, bzw. an einen konfigurierten Router.
Das folgende Bild zeigt, wie ein PC mit MOVISUITE auf Daten eines MOVIDRIVE-C Technology zugreift.
Der PC und der Antriebsumrichter MOVIDRIVE-C befinden sich in unterschiedlichen IP-Subnetzen.
Die IP-Subnetze sind an die beiden Schnittstellen X1 und X2 der CPU angeschlossen.

Anhang anzeigen 64636


Voraussetzungen für die Nutzung von IP-Forwarding sind:
  • S7-1500 CPU ab Firmware-Version V2.8
  • Anzahl Ethernet-Schnittstellen: Die CPU besitzt mindestens 2 Ethernet-Schnittstellen oder die CPU besitzt eine Ethernet-Schnittstelle und ein CP 1543-1 ab Firmware-Version V2.2 stellt die andere Ethernet-Schnittstelle zur Verfügung. In diesem Fall muss die Funktion "Zugriff auf PLC über Kommunikationsmodul" in der CPU für den CP aktiviert sein.
  • IP-Forwarding ist aktiviert.
  • In jedem beteiligten Gerät entlang des Hin- und Rückwegs der IP-Pakete sind passende Default-Gateways/Routen parametriert. Dies kann im Parameterbaum des jeweiligen Gerätes durchgeführt werden:
    Anhang anzeigen 64637

Gruß SEW Service
Zum IP-Forwarding (was eigentlich nur ein recht simples Routing ist), muss noch gesagt werden, dass auf dem Router, der in das Anlagennetz hineinroutet, auch die Route parametriert werden muss. Zudem muss bei den Geräten die IP-Adresse der CPU (Schnittstelle, an der das Gerät "hängt") als Router eingetragen werden. @SEWSERVICE : Das steht bei Dir zwar auch schon implizit im Text, aber ich wollte noch einmal explizit darauf hinweisen, da ich da auch drüber gestolpert bin.




Nach den bisherigen Angaben des Themenstarters ist dies nicht die bestehende Konfiguration:
Ich habe einen Fernwartungszugang auf die Master CPU in der Anlage und auf alle anderen Profinet-Teilnehmer, Anlagenrechner etc.
Mit dem Kunden ist alles abgeklärt und wir haben eben nur Zugriff auf unsere Anlage. Diese hat ihren eigenen IP-Bereich und nur da kommen wir drauf. Auch die SEW Motoren sind in diesem Bereich.
 
Mit dem Kunden ist alles abgeklärt und wir haben eben nur Zugriff auf unsere Anlage. Diese hat ihren eigenen IP-Bereich und nur da kommen wir drauf. Auch die SEW Motoren sind in diesem Bereich.
Ich denke dafür benötige ich auch einen bestimmten Port um auf diese zugreifen zu können. Mit dem 102 Simatic Port kann ich mich mit dem TIA Online verbinden, also gehe ich davon aus das hierfür ein anderer verwendet werden muss um mich in der MoviSuite Online zu schalten.
Ich denke auch, daß die Kunde-IT da benötigte Ports nicht durchroutet, Ihr also nicht kompletten Zugriff auf Euer Netz habt. Möglicherweise ist diese Portliste für die Kunde-IT hilfreich:
https://download.sew-eurodrive.com/..._MOVISUITE_V2.22.0_Installationsanleitung.pdf
siehe Seite 9, Kapitel 6 Firewall-Regeln

Ich kann die Geräte anpingen, aber nur wenn ich mich explizit mit ihrer IP verbinde, ansonsten können sie auch angesprochen werden, allerdings mit Paket-Verlusten.
??? :unsure:


PS:
Movisuite verwendet die Netzwerports 300-310. Diese sollten in deiner/den Firewalls freigeschaltet sein.

Zusatzinformation zum Thema IP Forwarding bei Siemens Steuerungen:
IP-Forwarding durch eine Siemens SPS nützt aber nur was, wenn man mit einem Protokoll bis zu der SPS kommt. Wird das Protokoll schon vorher geblockt/nicht durchgeleitet, dann nutzt das IP Forwarding auch nichts.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich habe es geschafft mich mit einzelnen Umrichtern zu verbinden. Das IP-Forwarding habe ich nicht benötigt.

Mir fehlte lediglich der richtige Port um mich richtig zu verbinden. Der 310er Port schien es wohl gewesen zu sein. Vielen Dank an die Runde für die Hilfe!
 
Für die Generation B gabs da eine elegante Lösung namens "MOVITOOLS® via Ethernet". Dabei läuft auf der S7-Steuerung ein Kommunikations-Proxy, der Anfragen von Movitools oder später MotionStudio am TCP-Port 300 entgegen nimmt und dann mittels DPV1-Dienste an unterlagerte Profibus-Umrichter weitergibt. Abgesehen davon, dass die käuflicher Version pro CPU zu lizenzieren war, fehlerhaft war und SEW sich nie die Mühe gemacht hat, das ganze so zu portieren, dass die PN-Schnittstelle einer CPU als Zugangspunkt genutzt werden konnte, war das eine feine Lösung.

Ich habe den Mechanismus dann mal wasserdicht nachgebaut, so dass man CP- oder PN-Schnittstellen verwenden konnte und auch Profinet-Geräte unterstützt wurden und man trotzdem die DPV1-Dienste auch aus dem Anwenderprogramm benutzen konnte. Der Aufwand war überschaubar und wir haben das in faktisch jeder Anlage drinnen gehabt. Die Portierung auf S7-1500 und das Umsetzen des Discovers-Protokolls ist dann irgendwann stecken geblieben, weil ich die Firma gewechselt habe.

Jetzt wäre es naheliegend, Proxy-Bausteine zu bauen, welche entsprechende Port-Weiterleitungen über das S7-Programm realisieren. Also die Ports 300++ ins Profinet an den entsprechenden Geräte weiterzuleiten.

Noch simpler dürfte es allerdings ein, einen VPN-Router einzubauen, mit dessen Hilfe man direkt Teilnehmer im Profinet wird. abgesehen von fertigen Lösungen wäre da z.B. ein IOT2050 mit openWRT ein einfacher Ansatz. Damit sind auch die Discovery-Mechanismen nutzbar und mehrere MoviC-Controller können problemlos angesprochen werden.

Vom IP-Routing über die CPU halte ich nichts.
 
Moin maxder2te,

das hört sich interessant an.
Unsere Kunden lassen idR nur einen VPN-Router zu. Wir haben mehrere Steuerungen bei Kunden verbaut, die über ein Netz (nicht das Profinet) miteinander verbunden sind. Da hilft es uns nicht, wenn wir mit einem VPN-Router Teilnehmer eines Profinets sind.

Da Du Dich ja auszukennen scheinst: Was spricht aus Deiner Sicht gegen das IP-Routing über die CPU. Dies ist IMHO unsere einzige Möglichkeit auf die Profinet-Teilnehmer zuzugreifen.

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin maxder2te,

das hört sich interessant an.
Unsere Kunden lassen idR nur einen VPN-Router zu. Wir haben mehrere Steuerungen bei Kunden verbaut, die über ein Netz (nicht das Profinet) miteinander verbunden sind. Da hilft es uns nicht, wenn wir mit einem VPN-Router Teilnehmer eines Profinets sind.

Da Du Dich ja auszukennen scheinst: Was spricht aus Deiner Sicht gegen das IP-Routing über die CPU. Dies ist IMHO unsere einzige Möglichkeit auf die Profinet-Teilnehmer zuzugreifen.

VG

MFreiberger
Ich denke hier an Tunnel-in-Tunnel.

Das bedeutet, dass ich mittels VPN-Zugang (EWon oder Kundensystem) ins Kundennetzwerk rein gehe und dort Zugriff auf das übergeordnete Anlagennetz bekomme - x IP-Adressen pro Anlage. Am Übergang vom Anlagennetz zum Profinet hängt eine Firewall mit OpenVPN-Server, welche über 1 IP-Adresse (UDP Port 1194) erreichbar ist. Zu dieser Firewall baue ich nun einen Layer 2 Tunnel (TAP) auf und bekomme an einem Virtual Interface eine IP-Adresse aus dem Profinet zugewiesen. Ich kann nun alle Layer 2 und 3 Dienste nutzen, also auch DCP und diverse Discovery-Geschichten.

IP-Routing ist schon ok. Aber die meisten Vernetzungskonzepte bei Betreibern sehen eine explizite Trennung von Feldnetz und Anlagennetz vor, und das entweder über Firewalls oder über CPUs mit 2 Ethernet-Schnittstellen. Durch das IP-Routing wird dieses Konzept, das als Security-Konzept weit verbreitet ist, plötzlich ausgehebelt. Außerdem zwingt uns das Aktivieren des IP-Routings dazu, dass IP-Adressen im Feldnetz plötzlich eindeutig sein müssen - das bedeutet die IP-Adressvergabe muss werksweit oder konzernweit bis zum letzten Feldteilnehmer eindeutig sein. Mit IPv6 kein Problem, mit IPv4 sehr spannend.

In unseren Applikationen, wo wir zwischen 3 und 200 identische Geräte in einer Anlage haben, wobei jedes Gerät ein inneres Profinet mit 3-20 Teilnehmern hat, ist das schon ein Thema, da ich dann z.B. 200 Hardware-Konfigurationen pflegen müsste. Daher ist die Hardwarekonfiguration und die Software bei allen Geräten identisch, nach außen hin gibts halt eine Firewall, welche die VPN-Funktionalität bereitstellt und nach außen hin mit einer eindeutigen IP-Adresse arbeitet.
Umgekehrt kann man sich natürlich niemals gleichzeitig auf meherere Geräte drauf hängen.

Ich hab sowas auch schon mit 3 verschachtelten Tunneln gemacht.

Wichtig:
Das Ganze muss natürlich entsprechend über Zugangsregeln usw. abgesichert sein. Die Layer 2 Zugangs-Geschichte öffnet natürlich Tür und Tor und man kann dann auch so Dinge machen mit Safety-Programm laden und Profisafe-Adressen zuweisen usw.
 
Das hört sich interessant an. Leider bin ich da nicht so bewandert.
Das bedeutet, dass ich mittels VPN-Zugang (EWon oder Kundensystem) ins Kundennetzwerk rein gehe und dort Zugriff auf das übergeordnete Anlagennetz bekomme - x IP-Adressen pro Anlage. Am Übergang vom Anlagennetz zum Profinet hängt eine Firewall mit OpenVPN-Server, welche über 1 IP-Adresse (UDP Port 1194) erreichbar ist. Zu dieser Firewall baue ich nun einen Layer 2 Tunnel (TAP) auf und bekomme an einem Virtual Interface eine IP-Adresse aus dem Profinet zugewiesen. Ich kann nun alle Layer 2 und 3 Dienste nutzen, also auch DCP und diverse Discovery-Geschichten.
Könntest Du mir das noch einmal näher erläutern?
Genauer nachgefragt: die "eine Firewall" ist noch ein weiteres Stück Hardware? Wenn ja, was setzt ihr da ein?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
20221107_131229.jpg
Ich hab das mal auf mein Whiteboard gemalt mit typischem Firmennetz

Durchgezogene Linien rechts:
schwarz: Firmennetzwerk, IP-Bereich x.x.x.x, z.B. 10.1.x.x, IP-Adressen konzernweit eindeutig
blau: Anlagennetzwerk (Shopfloor, Netzwerk, ...), IP-Adressen konzernweit eindeutig. Minimal 1 IP-Adresse pro Anlage. IP-Adressen sind per Router-Eintrag erreichbar und per Firewall vom Office-Netz getrennt.
rot: Feldnetz (Profinet), IP-Bereich 192.168.x.0, IP-Adressen innerhalb Feldnetz eindeutig

Das Feldnetz ist vom restlichen Netzwerk völlig weggekapselt. Die IP-Adressen am Feldnetz sind nicht werksweit eindeutig.

Mit meinem PC verbinde ich mich per VPN-Tunnel mit dem Kundennetzwerk, per IP-Routing komme ich bis ins Anlagennetzwerk und kann im gezeigten Beispiel in der linken Anlage die SPS, den PC und die Firewall erreichen. In der rechten Anlage kann ich nun die Firewall erreichen.

Im Feldnetz ist bei allen Geräten, welche nicht zusätzlich im Anlagennetz hängen, die Firewall als Gateway eingetragen. Auf der Firewall läuft ein OpenVPN-Server, welcher am Anlagennetzwerk seinen Serverport öffnet.
Ich verbinde mich nun von meinem Laptop per openVPN mit der Anlagen-Firewall. Mein Laptop erhält an der virtuellen Netzwerkkarte eine IP-Adresse aus dem Feldnetz und ist mittels TAP-Protokoll (Layer 2 tauglich) mit dem Feldnetz verbunden.

Für stationäre Aufbauten wird i.d.R. die linke Variante verwendet, für mobile Anwendungen die rechte. Die Anbindung ans Anlagennetz erfolgt bei mobilen Anwendungen halt per WLAN. Sind bei stationären Anwedungen im Feldnnetz keine Teilnehmer, die eine Ferndiagnose oder Parametrierung unterstützen (nur EAs), wird die Firewall weg gelassen.
 
Zurück
Oben