appsofting
Level-1
- Beiträge
- 38
- Reaktionspunkte
- 7
-> Hier kostenlos registrieren
Ich frage mich nur, wie es in Zukunft aussehen wird. Wir müssen vorbereitet sein 
Step 7 Mehrere PLCs in einem Netzwerk. Netzwerk überlastet?
- Ersteller halloween20
- Erstellt am
-> Hier kostenlos registrieren
OP
halloween20
Level-2
- Beiträge
- 20
- Reaktionspunkte
- 0
huihuihui...
hab da wohl ein interessantes thema angestoßen
Der Punkt ist. Wir (die programmierer der Anlagen) wissen nur, dass wir für alle fünf PLCs + deren PN Teilnehmer zum einen die IP "x" und den Gerätenamen "y"vergeben müssen.
Jede unserer Anlangen hat wenigstens einen, zwei Anlagen wegen der Verteilung der PN Teilnehmer, sogar zwei ProfiNet switche der Firma Phoenix Conntact.
Das Firmennetz ist dann in dem, im Schaltschrank befindlichen, Switch mit angeschlossen.
Das dieses "alles in einem" Netz vorgehen nicht generel doof ist, ist auch uns klar. Zum einen sitzen unseren Kunden überall in Deutschland oder gar im Ausland. Da will man nicht, kann es auch gar nicht, immer hin fahren/reisen wenn mal ein problem auftritt. Fernwartung ist da deutlich Zeiteffektiver, auch für unsere Kunden.
Das aktuelle Problem ist aber, sehr wahrscheinlich, auf diesen umstand zurückzuführen. Nun stehen wir und unser Kunde hier und suchen einen Fehler der die gesamte Produktionshalle still legt. Alle unsere Anlagen laufen "für sich" ohne Probleme. Diese kommen erst durch das anbinden ans Firmennetz. Der Kunde sagt nun "solange alle unsere Anlagen aus sind, besteht kein Problem" bei den restlichen Anlagen.
Ich habe aber erstmal ein paar ansatzpunkte die wir nachgehen können.
Jeder zeigt mit dem Finger auf einen anderen :sm23:
hab da wohl ein interessantes thema angestoßen
Der Punkt ist. Wir (die programmierer der Anlagen) wissen nur, dass wir für alle fünf PLCs + deren PN Teilnehmer zum einen die IP "x" und den Gerätenamen "y"vergeben müssen.
Jede unserer Anlangen hat wenigstens einen, zwei Anlagen wegen der Verteilung der PN Teilnehmer, sogar zwei ProfiNet switche der Firma Phoenix Conntact.
Das Firmennetz ist dann in dem, im Schaltschrank befindlichen, Switch mit angeschlossen.
Das dieses "alles in einem" Netz vorgehen nicht generel doof ist, ist auch uns klar. Zum einen sitzen unseren Kunden überall in Deutschland oder gar im Ausland. Da will man nicht, kann es auch gar nicht, immer hin fahren/reisen wenn mal ein problem auftritt. Fernwartung ist da deutlich Zeiteffektiver, auch für unsere Kunden.
Das aktuelle Problem ist aber, sehr wahrscheinlich, auf diesen umstand zurückzuführen. Nun stehen wir und unser Kunde hier und suchen einen Fehler der die gesamte Produktionshalle still legt. Alle unsere Anlagen laufen "für sich" ohne Probleme. Diese kommen erst durch das anbinden ans Firmennetz. Der Kunde sagt nun "solange alle unsere Anlagen aus sind, besteht kein Problem" bei den restlichen Anlagen.
Ich habe aber erstmal ein paar ansatzpunkte die wir nachgehen können.
Jeder zeigt mit dem Finger auf einen anderen :sm23:
-> Hier kostenlos registrieren
Es bleiben auch andere Anlagen stehen als eure?
Vielleicht solltet ihr den IT Netzaufbau beim Kunden einmal anfragen, wenn sie wirklich "ein Netz" bzw 1 VLAN haben wo alles drin hängt, könntet ihr einstreuen ob die VLAN getrennt werden können, damit wird schon einmal viel Beeinflussung untereinander ausgeschlossen.
Da auch Sachen wir Brodcast und andere Funktionen eigentlich nur im Lokalen VLAN weitergereicht werden. Und Geräte ohne entsprechendes Gateway nicht in ein anderes Subnet kommunizieren können.
Wenn ihr die Option habt zum testen die zweite Schnittstelle auf der Steuerung für den Uplink zu nutzen, könntet ihr das auch einmal versuchen, man hat dann zwar keinen direkten Zugriff mehr auf Komponenten im PDN aber so wäre bis auf die CPU alles abgekapselt zum Firmennetz.
- Beiträge
- 9.191
- Reaktionspunkte
- 2.950
Was ist denn ein PDN?
Cassandra
Level-2
- Beiträge
- 645
- Reaktionspunkte
- 537
Indu-Sol
Level-2
- Beiträge
- 70
- Reaktionspunkte
- 28
-> Hier kostenlos registrieren
Hallo Zusammen,
Ich stimme eurer Diskussion völlig zu, dass der Weg noch weit ist, viele Diskussionen und Abstimmungen erfordert und man erst das Know-how dafür aufbauen muss.
Ich musste in meinem Arbeitsleben schon mehreren technologischen Wandeln folgen, ob ich es nun wollte oder nicht, und solch einen Wandel erleben wir gerade wieder in den Netzwerken.
Warum meint ihr, machen wir uns Gedanken über TSN? Weil wir perspektivisch offene, konvergente Netzwerke mit PN und vielen weiteren Anwendungen erwarten!
Warum stellen unsere Indu-Sol Produkte, sowie eine ganze Reihe von Feldgeräten, ihre Daten zunehmend auch im OPC-Format zur Verfügung? Weil wir auf Dauer nicht mehr alle Daten über das Prozessabbild der SPS rangieren können, oder aufwändig Gateways zwischen den Netzen installieren und programmieren wollen!
Der Druck „von oben“ in Bezug auf den freien Zugriff auf Daten bei uns „unten“ in den OT-Netzwerken wird steigen.
Mauern wir uns weiter ein und blocken einfach nur mit Argumenten wie, Echtzeitprobleme, Securityprobleme, dann disqualifizieren wir uns als Gesprächspartner und werden über kurz oder lang nicht mehr ernst genommen.
Qualifizieren wir uns aber, wägen in Diskussionen mit der IT fair das Pro und Contra ab, zeigen Wege durch unsere Netzwerke auf bzw. lehnen sie gut argumentiert ab und scheuen uns nicht vor Neuem, dann bleiben wir im Spiel.
MfG
René Heidl
ich hoffe Sie sehen mir meine leichte Provokation „ewig Gestrige“ nach :wink:
Ich stimme eurer Diskussion völlig zu, dass der Weg noch weit ist, viele Diskussionen und Abstimmungen erfordert und man erst das Know-how dafür aufbauen muss.
Ich musste in meinem Arbeitsleben schon mehreren technologischen Wandeln folgen, ob ich es nun wollte oder nicht, und solch einen Wandel erleben wir gerade wieder in den Netzwerken.
Warum meint ihr, machen wir uns Gedanken über TSN? Weil wir perspektivisch offene, konvergente Netzwerke mit PN und vielen weiteren Anwendungen erwarten!
Warum stellen unsere Indu-Sol Produkte, sowie eine ganze Reihe von Feldgeräten, ihre Daten zunehmend auch im OPC-Format zur Verfügung? Weil wir auf Dauer nicht mehr alle Daten über das Prozessabbild der SPS rangieren können, oder aufwändig Gateways zwischen den Netzen installieren und programmieren wollen!
Der Druck „von oben“ in Bezug auf den freien Zugriff auf Daten bei uns „unten“ in den OT-Netzwerken wird steigen.
Mauern wir uns weiter ein und blocken einfach nur mit Argumenten wie, Echtzeitprobleme, Securityprobleme, dann disqualifizieren wir uns als Gesprächspartner und werden über kurz oder lang nicht mehr ernst genommen.
Qualifizieren wir uns aber, wägen in Diskussionen mit der IT fair das Pro und Contra ab, zeigen Wege durch unsere Netzwerke auf bzw. lehnen sie gut argumentiert ab und scheuen uns nicht vor Neuem, dann bleiben wir im Spiel.
MfG
René Heidl
- Beiträge
- 12.426
- Reaktionspunkte
- 4.607
Ich darf / muss mich seit einigen Jahren mit dem Thema I4.0 und IIoT beschäftigen.
Aus meiner Sicht ist das Pferd zu Tode geritten und es wird Zeit abzusteigen
Warum diese Meinung:
In vielen Bereichen hat man schlichtweg erkannt, dass Sensordaten alleine in irgendwelchen IT-System (ich vermeide mal den Begriff Cloud) alleine nichts bringen.
Um sinnvolle Ergebnisse zu bekommen, braucht man fast immer zusätzliche Daten aus der SPS. Die SPS "kennt" die Anlage.
Bei Big Data, KI und Analytics sind viele Werbeversprechen zerplatzt wie Luftblasen. Oft muss man nämlich um Auswertungen zu bekommen, Teile der Logik nachprogrammieren.
Nur ist diese Logik entweder in der SPS schon vorhanden, oder lässt sich dort einfacher und schneller implementieren.
SPS entwickelt sich zunehmend weiter. Die Produktzyklen werden deutlich kürzer - Segen und Fluch.
Bei aktuellen Steuerungen ist OPC UA Server eigentlich schon Standard. OPC UA Client wird immer mehr integriert.
Die Leistungsfähigkeit steigt. Es werden auch IIoT-Funktionen zunehmend integriert (Wago PFC200 2nd Generation mit Docker).
Auch wenn im Zuge von I4.0 (wieder mal) das Ende der klassischen SPS vorhergesagt wurde (PLC in der Cloud), so lebt sie weiter.
Ich denke TSN wird klar kommen, aber sicher nicht in dem prognostizierten Umfang.
Die angeprochenen Gateways werden sicher deutlich mehr und nicht weniger werden, da das Thema Security immer weiter ins Bewusstsein rückt.
Wir reden von Netzwerk-Segmentierung und Zonierung. Und dies spricht ganz klar gegen die Marketingversprechen "In 10 Minuten sind sind ihre Sensordaten in der Cloud".
Ansonsten hat man nämlich in 11 Minuten Wannacry im Netz
Fazit:
Es bleibt spannend und interessant
getOptimum
Level-1
- Beiträge
- 26
- Reaktionspunkte
- 1
Ich darf / muss mich seit einigen Jahren mit dem Thema I4.0 und IIoT beschäftigen.
Aus meiner Sicht ist das Pferd zu Tode geritten und es wird Zeit abzusteigen
Warum diese Meinung:
In vielen Bereichen hat man schlichtweg erkannt, dass Sensordaten alleine in irgendwelchen IT-System (ich vermeide mal den Begriff Cloud) alleine nichts bringen.
Um sinnvolle Ergebnisse zu bekommen, braucht man fast immer zusätzliche Daten aus der SPS. Die SPS "kennt" die Anlage.
Bei Big Data, KI und Analytics sind viele Werbeversprechen zerplatzt wie Luftblasen. Oft muss man nämlich um Auswertungen zu bekommen, Teile der Logik nachprogrammieren.
Nur ist diese Logik entweder in der SPS schon vorhanden, oder lässt sich dort einfacher und schneller implementieren.
SPS entwickelt sich zunehmend weiter. Die Produktzyklen werden deutlich kürzer - Segen und Fluch.
Bei aktuellen Steuerungen ist OPC UA Server eigentlich schon Standard. OPC UA Client wird immer mehr integriert.
Die Leistungsfähigkeit steigt. Es werden auch IIoT-Funktionen zunehmend integriert (Wago PFC200 2nd Generation mit Docker).
Auch wenn im Zuge von I4.0 (wieder mal) das Ende der klassischen SPS vorhergesagt wurde (PLC in der Cloud), so lebt sie weiter.
Ich denke TSN wird klar kommen, aber sicher nicht in dem prognostizierten Umfang.
Die angeprochenen Gateways werden sicher deutlich mehr und nicht weniger werden, da das Thema Security immer weiter ins Bewusstsein rückt.
Wir reden von Netzwerk-Segmentierung und Zonierung. Und dies spricht ganz klar gegen die Marketingversprechen "In 10 Minuten sind sind ihre Sensordaten in der Cloud".
Ansonsten hat man nämlich in 11 Minuten Wannacry im Netz
Fazit:
Es bleibt spannend und interessant
Dieser Einschätzung möchte ich mich zu 100% anschließen.
Wenn es mit VLAN-Tagging so einfach wäre die Sicherheit der Prozesse zu gewährleisten, gäbe es kein PROFISECURE, und nicht unzählige Arbeitskreise und Hersteller die mit Gateways für BigData beschäftigt sind.
Gesendet von iPhone mit Tapatalk
-> Hier kostenlos registrieren
Macht der Gewohnheit.
Produktions Daten Netzwerk.
Bei uns sind seit einer Weile die Netze Office und Maschinennah getrennt. Und wird intern mit PDN abgekürzt.
Ich verstehe die Diskussion nicht. Warum nicht die Netze in verschiedene Subnetze aufteilen und über Routing zusammenbringen, wo es erforderlich ist? Was soll daran nicht mehr zeitgemäß sein? Es besteht weder eine physikalische Trennung, noch sind Zugriffe von außerhalb unterbunden. Es ist nur aufgeräumter und kontrollierbar.
- Beiträge
- 12.426
- Reaktionspunkte
- 4.607
Wir hatten vor einiger Zeit in einem Standort ein Problem mit Wannacry.
Durch Segmentierung und Zonenkonzept konnte ein Überspringen in andere Netzwerksegmente rechtzeitig verhindert werden.
Als Folge dieses Vorfalls wird das Zonenkonzept weiter ausgebaut und zusätzliche Firewalls zwischen den Zonen installiert.
Natürlich wird dadurch Einiges für I4.0 erschwert, aber dafür auch ein gewisser unkontrollierbarer Wildwuchs eingedämmt.
-> Hier kostenlos registrieren
Also ist der einzige Vorteil des "zeitgemäßen" alles in ein Netz packen, dass die Komplexität und der Aufwand ein Netz und Geräte zu administrieren verringert wird. Sehe ich das richtig? I4.0, oder anders gesagt, dass jeder Sensor für sich seine Daten in irgendeine Cloud schmeißt und das niemand mehr anschaut, ist auch mit dem herkömmlichen und netzwerktechnisch korrekten Netzaufbau möglich. Dieses Argument mit dem unliebsamen Buzzword lasse ich nicht gelten.
In freier Wildbahn ist mir auch kaum eine Firma begegnet die solch einen Aufbau präferiert. Es wurde immer tunlichst genau darauf geachtet, dass ja alle gängigen Grundprinzipien der Trennung und des segmentierten Aufbaus eingehalten werden, inkl Firewalls, Routers usw. Daher wundert mich die Diskussion hier, da ich das so nicht kenne. Eher anders: Genau das wird bei namhaften Firmen mit allen Mitteln versucht zu vermeiden. Wer dort ein Netz so aufbaut wird standrechtlich erschossen. Einzig und allein da, wo kaum fähiges IT-Personal vorhanden war (ist aber generell so, meist gibt es nur sehr sehr wenige gute Leute pro Firma diesbezüglich) gab es solche Konstellationen. Mit den daraus resultierenden Problemen:
-Kampf um jede einzelne IP Adresse
-wenn man per Fernwartung im Netz war mal eben mehrere andere Anlagen bösartig "kompromittieren" konnte
-beim Parametrieren von PN-Geräten 1 Nummer in der Adresse zu weit, oder es gibt eine Verwechslung da es die gleiche HW ist, und schon schießt man ein Device einer anderen Anlage ab
-Rekonfiguration aller Netzwerkgeräte vor Ort, da die mitgeteilten Adressen schon belegt waren. Der Klassiker.
-andere Hersteller sich unwissend Adressen einfach genommen haben und daraus resultierende Doppelbelegungen im Netz
-lahmes Netz. Ja ich weiß, in der Theorie und durch die Verwaltung der Pakete durch die Switches sollte das nicht sein, aber in der Praxis schwirren dann eben doch gefühlt irgendwelche Broadcasts und UDP Pakete durchs Netz in alle Ecken was der Stabilität und Performance nicht gut tut. Gerade bei solch einem Netz musste ich mal sämtliche PN-Kommunikation in der Auslastung drastisch einschränken, bzw. fehlertoleranter machen, da es ständig zu ausfällen kam, was sonst bei gleichem Aufbau nie der Fall ist.
usw. Die Liste ist Endlos. Von der Sicherheitsproblematik wie sie Blockmove erwähnt hat mal ganz zu schweigen.
Das einzige was hier "zeitgemäß" ist, ist die verringerte Komplexität. Aber so kennt man das ja überall.
Einzig bei IPV6 könnte ich diesem Aufbau vielleicht etwas abgewinnen, aber das wird die nächsten 15 Jahre in diesem Segment nicht Einzug halten, bzw. selbst dann wird dieser Aufbau immer nicht so anwendbar sein, da noch genug IPV4 Systeme vorhanden sein werden. Und was das Thema VLANs angeht, muss ich aus Erfahrung sagen, dass dort mehr schief geht als funktioniert.
In freier Wildbahn ist mir auch kaum eine Firma begegnet die solch einen Aufbau präferiert. Es wurde immer tunlichst genau darauf geachtet, dass ja alle gängigen Grundprinzipien der Trennung und des segmentierten Aufbaus eingehalten werden, inkl Firewalls, Routers usw. Daher wundert mich die Diskussion hier, da ich das so nicht kenne. Eher anders: Genau das wird bei namhaften Firmen mit allen Mitteln versucht zu vermeiden. Wer dort ein Netz so aufbaut wird standrechtlich erschossen. Einzig und allein da, wo kaum fähiges IT-Personal vorhanden war (ist aber generell so, meist gibt es nur sehr sehr wenige gute Leute pro Firma diesbezüglich) gab es solche Konstellationen. Mit den daraus resultierenden Problemen:
-Kampf um jede einzelne IP Adresse
-wenn man per Fernwartung im Netz war mal eben mehrere andere Anlagen bösartig "kompromittieren" konnte
-beim Parametrieren von PN-Geräten 1 Nummer in der Adresse zu weit, oder es gibt eine Verwechslung da es die gleiche HW ist, und schon schießt man ein Device einer anderen Anlage ab
-Rekonfiguration aller Netzwerkgeräte vor Ort, da die mitgeteilten Adressen schon belegt waren. Der Klassiker.
-andere Hersteller sich unwissend Adressen einfach genommen haben und daraus resultierende Doppelbelegungen im Netz
-lahmes Netz. Ja ich weiß, in der Theorie und durch die Verwaltung der Pakete durch die Switches sollte das nicht sein, aber in der Praxis schwirren dann eben doch gefühlt irgendwelche Broadcasts und UDP Pakete durchs Netz in alle Ecken was der Stabilität und Performance nicht gut tut. Gerade bei solch einem Netz musste ich mal sämtliche PN-Kommunikation in der Auslastung drastisch einschränken, bzw. fehlertoleranter machen, da es ständig zu ausfällen kam, was sonst bei gleichem Aufbau nie der Fall ist.
usw. Die Liste ist Endlos. Von der Sicherheitsproblematik wie sie Blockmove erwähnt hat mal ganz zu schweigen.
Das einzige was hier "zeitgemäß" ist, ist die verringerte Komplexität. Aber so kennt man das ja überall.
Einzig bei IPV6 könnte ich diesem Aufbau vielleicht etwas abgewinnen, aber das wird die nächsten 15 Jahre in diesem Segment nicht Einzug halten, bzw. selbst dann wird dieser Aufbau immer nicht so anwendbar sein, da noch genug IPV4 Systeme vorhanden sein werden. Und was das Thema VLANs angeht, muss ich aus Erfahrung sagen, dass dort mehr schief geht als funktioniert.
Zuletzt bearbeitet:
- Beiträge
- 12.426
- Reaktionspunkte
- 4.607
Und selbst das ist nicht der Fall.
Intelligente Sensoren oder IO-Link-Master mit Cloudanschluss brauchen für die Konfiguration mit der Cloud entsprechende Zugangsdaten, Parameter, Zertifikate und sonstwas.
Für die Einbindung in die SPS brauchst du wieder andere Daten (Profinetnummer und -name).
Wer soll das alles Konfigurieren? Der SPSler, der Dataanalyst, der Netzwerker?
Bisher hast klar getrennte Hardware- und Software, die jeder aus seinem Gebiet beherrscht.
Nachher hast du zig Tools von zig Herstellern für zig Geräte.
Alleine schon das Verwalten der Firmware und der Zertifikate für Hunderte von schlauen Sensoren wird lustig.
Genau aus dem Grund verstehe ich diese IO-Link Cloud Geschichte nicht. Es macht (in 98% der Fälle) keinen Sinn und endet im FW-, Parameter-, Netzwerk-, Zertifikats-, Zugangsdaten-, Sicherheits-, Zuständigkeits- und Kostenfiasko.
Warum nicht die Daten effektiv direkt und variabel aus der Steuerung holen (hier vor allem mit für die Analyse absolut notwendigen Zusatzinformationen aus dem Programm, sonst sind sie nämlich nichts Wert) und dann lokal speichern, bzw. für die krassen Leute noch in die Cloud wuppen. Ist nicht IT4.0, sondern IT1.0 und gab es ohne Cloud schon vor 30 Jahren. Nein, es muss jeder kleinste Sensor sein eigenes Süppchen kochen und vor allem, das ist wohl der Grund für den Pseudo-Hype: am Ende einzeln für 3€/Monat bezahlt werden. Darum gehts. Das nennt man dann Digitalisierung, weil Datenakquisition auf dem technisch korrekten Weg ist ja analog und mit Dampfwalze betrieben...
Warum nicht die Daten effektiv direkt und variabel aus der Steuerung holen (hier vor allem mit für die Analyse absolut notwendigen Zusatzinformationen aus dem Programm, sonst sind sie nämlich nichts Wert) und dann lokal speichern, bzw. für die krassen Leute noch in die Cloud wuppen. Ist nicht IT4.0, sondern IT1.0 und gab es ohne Cloud schon vor 30 Jahren. Nein, es muss jeder kleinste Sensor sein eigenes Süppchen kochen und vor allem, das ist wohl der Grund für den Pseudo-Hype: am Ende einzeln für 3€/Monat bezahlt werden. Darum gehts. Das nennt man dann Digitalisierung, weil Datenakquisition auf dem technisch korrekten Weg ist ja analog und mit Dampfwalze betrieben...
Zuletzt bearbeitet:
Indu-Sol
Level-2
- Beiträge
- 70
- Reaktionspunkte
- 28
-> Hier kostenlos registrieren
Hallo Zusammen,
ich finde die Diskussion sehr anregend und verfolge diese auch weiter, nur allein das hilft halloween20 bei seinem Problem aktuell nicht weiter.
@halloween20: Gibt es schon neue Erkenntnisse? Die möglichen Ursachen sind vielfältig basierend auf Ihren Beschreibungen des Fehlers. Ich bräuchte Angaben zur Netzlast, zum Auftreten von Discards und Errors im Netzwerk und zum Broadcastaufkommen, um weiterhelfen zu können.
Auch ist eine VLAN-Trennung schneller empfohlen als praktisch umgesetzt.
Ein Phoenix-Switch wird für die Anbindung nach oben genutzt: Hoffentlich ist es kein reiner Access-Layer-Switch, denn für den Backbone und die Anbindungen nach „oben“ sollte man Distribution-Layer-Switche nutzen, um diese nicht zu überfordern. Ein überforderter Access-Layer-Switch discardet nämlich Telegramme. Hat Phoenix dann noch ein „shared memory“, dann kann es passieren, dass eben nicht am „uplink“ Telegramme verworfen werden, sondern an Ports, an denen eventuell der PROFINET-Verkehr drüber geht.
Aber das sind nur ein paar Möglichkeiten.
Vielleicht ist es für Sie, oder Ihren Endkunden denkbar und im Budget, in diesem Fall einmal auf externe Hilfe zurückzugreifen.
MfG
René Heidl
ich finde die Diskussion sehr anregend und verfolge diese auch weiter, nur allein das hilft halloween20 bei seinem Problem aktuell nicht weiter.
@halloween20: Gibt es schon neue Erkenntnisse? Die möglichen Ursachen sind vielfältig basierend auf Ihren Beschreibungen des Fehlers. Ich bräuchte Angaben zur Netzlast, zum Auftreten von Discards und Errors im Netzwerk und zum Broadcastaufkommen, um weiterhelfen zu können.
Auch ist eine VLAN-Trennung schneller empfohlen als praktisch umgesetzt.
Ein Phoenix-Switch wird für die Anbindung nach oben genutzt: Hoffentlich ist es kein reiner Access-Layer-Switch, denn für den Backbone und die Anbindungen nach „oben“ sollte man Distribution-Layer-Switche nutzen, um diese nicht zu überfordern. Ein überforderter Access-Layer-Switch discardet nämlich Telegramme. Hat Phoenix dann noch ein „shared memory“, dann kann es passieren, dass eben nicht am „uplink“ Telegramme verworfen werden, sondern an Ports, an denen eventuell der PROFINET-Verkehr drüber geht.
Aber das sind nur ein paar Möglichkeiten.
Vielleicht ist es für Sie, oder Ihren Endkunden denkbar und im Budget, in diesem Fall einmal auf externe Hilfe zurückzugreifen.
MfG
René Heidl
- Beiträge
- 11.207
- Reaktionspunkte
- 3.827
hmm, bin ich der einzige, bei dem an den Anlagen nichtmal die Topologie der PNIO-Teilnehmer stimmt? Weil an einem 8-port-Switch niemand die richtigen Kabel in die richtige Buchse bekommt??? Und selbst wenn das mal richtig gesteckt ist, spätestens nach 3 Jahren stimmt da nix mehr...
Also keine Ahnung, Netze gehören physikalisch getrennt... Und wer was anderes behauptet, der sollte mal ne Weile auf die Baustelle fahren...
Gruß.
Also keine Ahnung, Netze gehören physikalisch getrennt... Und wer was anderes behauptet, der sollte mal ne Weile auf die Baustelle fahren...
Gruß.
escride1
Level-3
- Beiträge
- 1.262
- Reaktionspunkte
- 327
Vielleicht nicht der einzige aber einer der wenigen, wir haben selbst im Schaltplan den genauen Port der Teilnehmer eingezeichnet.
Ich behaupte was anderes und bin ständig auf Baustellen.
appsofting
Level-1
- Beiträge
- 38
- Reaktionspunkte
- 7
-> Hier kostenlos registrieren
Bei einer großen Anzahl von Geräten kann die fehlende Netzwerksegmentierung bei einem Ausfall zu Problemen führen, z.B. Identifizierung des Moduls, Austausch, manuelle Zuordnung des Namens. Kleine Anlagen sind immer noch akzeptabel, aber größere, die ich vermeiden würde.
- Beiträge
- 12.426
- Reaktionspunkte
- 4.607
Vielleicht nicht der einzige aber einer der wenigen, wir haben selbst im Schaltplan den genauen Port der Teilnehmer eingezeichnet.
Ich behaupte was anderes und bin ständig auf Baustellen.
Ist bei mir genauso. Steckt was in einem Port was da nicht hingehört, dann gibt's Mecker.
Falsch gesteckte Netzwerkleitungen ärgern mich deutlich mehr bei der Inbetriebnahme als Fehler bei Sensoren.
Bei der Inbetriebnahme werden zuerst alle Stränge am Schaltschrank-Switch ausgesteckt, dann Hardware eingespielt und dann einer nach dem anderen eingesteckt. Wenn alles richtig verkabelt ist, dann ist das Thema Profinet-Adressierung schnell durch. Ich hab keinen Bock mit dem Blinktest irgendwelche Profinetteilnehmer zu suchen und zu adressieren.
- Beiträge
- 11.207
- Reaktionspunkte
- 3.827
hmm, also ists dann doch eher wie bei mir ☺ dass eher nix stimmt, und Du das richtig stecken musst ☺
Bei einer großen Halle, wo ALLES in einem Netz steckt, willst Du das prüfen?
Im letzten Jahr erlebt: Jemand hat bei nem TP1500 die IP für die 2. Schnittstelle nur am Panel geändert und dann ins Werksnetz damit und nix davon gesagt. Ich dann am Panel nen Bild geändert und neu geladen. Somit war die alte IP wieder drin und somit im Werksnetz...
Gruß.
