TIA Profibus Netzerweiterung um neuen Master in Bestandsanlage

CR/LF

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich stehe vor folgendem Problem:

Ich habe eine Bestandsanlage mit einer VIPA 315SB (wird als S7-318-2 projektiert). Programm ist unter STEP7 geschrieben. HMI ist noch ein altes MP270B mit Protool projektiert.

Als Software stand mir nur eine nicht aktuelle zur Verfügung. HWConfig und Software sind nicht identisch. Deswegen habe ich einen Programmabzug gemacht und die aktuellen Bausteine in das alte Projekt geschoben. Weiter dann noch die Symbolik händisch aktualisiert, damit wenigstens das Programm mal soweit passt.

Weiter habe ich probiert, die HWConfig in ein Projekt zu laden. Habe aber gemerkt, dass wenn ich die VIPA als leere Station ins PG lade, die Verbindung zum Panel MP270B nicht mit geladen wird.
Das MP270B kann ich nicht als Station laden. Fehlermeldung „Teilnehmer nicht erreichbar“. Weiter wird die Software des Panels auch nicht übertragen. Die ist im alten Projekt immerhin noch drin – ob die aktuell ist, weiß man aber auch nicht.
Da ich also kein Backup der HWConfig habe, möchte ich um eine Änderung dieser in der VIPA auf jeden Fall herum kommen. (Außer jemand hat einen Tipp, wie ich das schaffe, die Projekte konsistent zu bekommen). Es hängen noch mehrere Umrichter im Profibusnetz, die VIPA ist hier nicht alleine.



Daher bin ich aktuell an dem Punkt, dass ich die HWconfig der VIPA nicht anfassen will und kann



Nun soll die Anlage teilmodernisiert werden und ein vorhandener IPC477D soll als zweite HMI für die Neuerungen dienen. IPC enthält eine WinCC Runtime und eine Software SPS.

Habe in TIA ein Projekt mit dem IPC erstellt und die VIPA als Geräteproxy eingelesen. Ich hole aktuell Daten von der VIPA zum IPC über Profibus und GET. Das funktioniert soweit auch, wenn auch ein direkter Variablenzugriff toll wäre (HMI RT hat keinen direkten Zugriff auf den Profibusport, sondern nur Zugriff auf die Software SPS per Softbus. Der Profibusport ist für die Software SPS reserviert. Daher werden die Daten in die SPS geladen und von dort aus weiter ans HMI RT)
1640889953803.png

Nun soll noch ein Profibuskoppler integriert werden (Beckhoff BK3100 mit Analogeingängen und ein paar EAs). Dieser soll eine Heizungssteuerung (aktuell Insellösung) ersetzen. Steuerung soll über die Software SPS gehen mit Zugriff des Bedieners über den IPC.

Da ich die HWConfig der VIPA nicht ändern kann/will, muss nun der IPC der Master für den Koppler sein, aber gleichzeitig im Profibusnetz der VIPA hängen. Wenn ich diesen nun so konfiguriere, dann geht die Software SPS des IPC in STOP. Fehlerbeschreibung habe ich aktuell leider nicht mehr parat, es handelte sich aber um einen generellen Konfigurationsfehler, weswegen die SPS nicht in RUN kam. Eine genaue Beschreibung gab es im Diagnosepuffer nicht, sonst hätte ich spezifischer suchen können.
1640889996676.png

Als ich die Zuordnung des BK3100 zur Software SPS als Master aufgehoben hatte, ging die CPU nicht mehr in STOP. Ohne Masterzuordnung kann das Prozessabbild des BK3100 aber auch nicht erreicht werden.

Sorry für den langen Text, wollte es aber möglichst treffend beschreiben.

Runtergebrochen und zusammengefasst:
Habe einen IPC über Profibus als stillen Teilnehmer an einer VIPA 314 hängen, um Daten für die Visualisierung bereitzustellen ohne dass die VIPA das weiß bzw projektiert ist.
Daten werden untereinander zwischen IPC und VIPA über PUT/GET übertragen und nun soll noch ein BK3100 im gleichen Profibusnetz integriert werden, welcher das Prozessabbild dem IPC bereitstellen soll.
Alles ohne etwas an der HWConfig der VIPA 314 zu ändern.
Gibt es da einen Weg?

Den genauen Log des Diagnosepuffers kann ich erst nächste Woche zur Verfügung stellen. Vielleicht kann jemand auch ohne diesen helfen?


Vielen Dank!
 
Ohne es mir im Detail überlegt zu haben.

Werf die Vipa und das MP raus, und lass alles über den IPC laufen. das erspart Dir ne Menge ärger, gerade was zukünftige Änderungen angeht.

Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde über die VIPA über das TCP-IP der CPU anbinden an die Runtime VISU.
Da musst du auch nix in der Hardware ändern.
Für den vergleich der Hardware untereinander. Kannst du den AG Abzug und orginal als CFG im Hardwaremanger exportieren und dann mit deiner Hardware vergleichen. Ist aufwendig und auch nicht ganz einfach. Wenn Beide Hardware keine unterschied beim vergleichen Anzeigen sind sie auch gleich.
Für die Visu gibt's keine Chance zum vergleichen. Außer optisch Bilder vergleichen und hoffen das es der gleiche Stand ist.
Also VIPA über TCP IP Anbinden und den koppler über profibus.
 
Werf die Vipa und das MP raus, und lass alles über den IPC laufen. das erspart Dir ne Menge ärger, gerade was zukünftige Änderungen angeht.
Wäre natürlich der saubere Weg, aber das ist in Anbetracht der Stillstandszeit der Anlage nicht zu bewerkstelligen.
HMI ist auch noch mit Protool geschrieben.


Für den vergleich der Hardware untereinander. Kannst du den AG Abzug und orginal als CFG im Hardwaremanger exportieren und dann mit deiner Hardware vergleichen. Ist aufwendig und auch nicht ganz einfach. Wenn Beide Hardware keine unterschied beim vergleichen Anzeigen sind sie auch gleich.
Für die Visu gibt's keine Chance zum vergleichen. Außer optisch Bilder vergleichen und hoffen das es der gleiche Stand ist.
Ich lass das lieber, da ich kein Backup habe.
Die Zeit für den Umbau ist begrenzt und das System muss nächste Woche wieder laufen (Produktionsanlage)
Also VIPA über TCP IP Anbinden und den koppler über profibus.
Die Idee hatte ich beim Verfassen des Beitrags auch.
So wie ich das aber in der aktuellen HWConfig der VIPA sehe, wurde in dem PN-Kommunikationsmodul die Option SEND/RECEIVE nicht aktiviert. Was heißt, ich müsste hierbei auch eine neue HWConfig reinschießen, was ich vermeiden will.
Werde ich nächste Woche auf jeden Fall mal probieren.


Zu meiner eigentlichen Frage:
Kann das Profibusnetz generell so aufgebaut werden? Ihr habt mir im Grunde zwei Alternativen zum aktuellen Konzept genannt^^

Grüße
 
Die Idee hatte ich beim Verfassen des Beitrags auch.
So wie ich das aber in der aktuellen HWConfig der VIPA sehe, wurde in dem PN-Kommunikationsmodul die Option SEND/RECEIVE nicht aktiviert. Was heißt, ich müsste hierbei auch eine neue HWConfig reinschießen, was ich vermeiden will.
Werde ich nächste Woche auf jeden Fall mal probieren.
Brauchst du die Daten vom profibus koppler auf der vipa ?
Wie Schnell muss die Aktualisierungszeit zur VIPA sein.
Denke so im 100ms bis 1 sek Bereich.
Ich gehe aus das du auf der VIPA in der VISU daten lesen und schreiben willst. VIPA ändert sich nicht.
Ich Würde die Anbindung der VIPA über TCPIP RFC 1006 die muss nicht projektiert sein etc. Die geht immer muss nur richtig eingestellt werden in der VISU. Du kannst mal danach suchen und wirst etliche Beträge finden wie das geht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein, ich brauche die Daten des Kopplers auf dem IPC und der Software SPS.
Die VIPA hat damit nichts zu tun.
Bin grad mal dabei, das aufzubauen, dann kann ich auch den Fehlerlog posten bzgl Profibuserweiterung
 
Wäre natürlich der saubere Weg, aber das ist in Anbetracht der Stillstandszeit der Anlage nicht zu bewerkstelligen.
HMI ist auch noch mit Protool geschrieben.
Vielleicht ist aber die 'einfachere' Weg ?
Das ganze ist ein Drechshaufen - Sorry muss es sagen.
Alte software, VIPA mit TIA als Proxy, Daten wir mittels PUT/GET geschaufelt, noch was .. ?
Es soll möglich sein die MP270B HMI von Protool nach WinCC Flexible zu migrieren und weiter nach TIA WinCC RT.
Dasselbe mit das VIPA/318-2PN/DP Prgramm, migrieren nach WinAC.
Es muss möglich sein dies in ein Tag zu erledigen inklusiv ein Test das es funktioniert.

Dann hast du ein einfachen Projekt ohne besonderheiten und es ist viel einfacher zu warten. Ich wurde zuerst die Erweiterung mit die BK3100 machen nach diese Migrierung.

Nur, für ein WinAC wurde ich lieber auf STEP7 Klassik bleiben, nicht TIA.

edit: Profibus ist auch viel einfacher wenn man bei 1 Master bleibt.
 
Nein, ich brauche die Daten des Kopplers auf dem IPC und der Software SPS.
Die VIPA hat damit nichts zu tun.
also auf einem Profibusstrang sollen sich 2 Profibusmaster (Vipa+Soft-SPS) befinden und diverse Slaves die dem einen (Vipa+Umrichter) bzw. anderen (Soft-SPS+DPDP-Koppler) Master zugeordnet sind? Das wird so nicht gehn. Irgendwie ist das ganze so verworren, dass ich jetzt schon nicht durchblicke.

Wie groß ist denn die HW-Konfig der Vipa? Wenn Du da ne Zeit zum spielen hast, dann rekonstruiere die doch einfachmal...

Ich würde die Vipa als SPS belassen und die HW-Konfig geradeziehen. Die Soft-SPS würd ich garnicht verwenden. Der IPC wird die neue und alleinige Visu über Ethernet an die Vipa gekoppelt. Der DPDP-Koppler wird der Vipa per Profibus angebunden...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
also auf einem Profibusstrang sollen sich 2 Profibusmaster (Vipa+Soft-SPS) befinden und diverse Slaves die dem einen (Vipa+Umrichter) bzw. anderen (Soft-SPS+DPDP-Koppler) Master zugeordnet sind? Das wird so nicht gehn.
Doch, es nennt sich multi-master Betrieb.
Es verringert aber die Performance, um ein Faktor 5x-10x (!), und ist dann viel umständlicher zu handhaben.
Auch auf diesen Grund wurde ich den ganze System vereinfachen wenn möglich.

Irgendwie ist das ganze so verworren, dass ich jetzt schon nicht durchblicke.
+1
 
Doch, es nennt sich multi-master Betrieb.
Also ich hab solch ein Profibus-Multimaster-System in der Realität noch nirgends gesehn... Jetzt geh ich mal davon aus, dass Generationen von Automatisierern jetzt nicht zu doof dazu warn, sondern aus gutem Grund sowas nicht benutzt haben. Ich vermute aber eh, dass dazu auch HW-Konfig-Änderungen in der Vipa notwendig wären....

PS: ich würd dann auf jeden Fall ne 2. Profibus-Karte in den IPC einbauen. Dann bleiben die 2 Profibusse schön getrennt:rolleyes:
 
Das ganze ist ein Drechshaufen - Sorry muss es sagen.
;)
ich wollts nicht so drastisch formulieren😂
Ein ordentliches Konzept sich vor dem Stillstand zu überlegen, wär nicht schlecht gewesen....
Online/Offline-Vergleich vorher wär nicht schlecht gewesen....
HW-Konfig-Rekonstruktion vorher wär nicht schlecht gewesen....
Software-Rekonstruktion vorher wär nicht schlecht gewesen...
Wenn man erst am Stillstandstag damit anfängt, werdens lange Nächte :)
 
Sodele, melde mich wieder zurück

Warum es nicht funktionierte: Schlampigkeitsfehler, hatte einen BK3100 projektiert, aber einen BK3010 im Einsatz.. Habe den dann gegen einen BK3100 getauscht und die CPU ging in RUN..

Hatte auch das PB-Multimastersystem ohne Probleme zum laufen bekommen, hat soweit auch gut funktioniert.


Aufgrund möglicher Probeme bei der IBN (Busfehler, Anlagenstillstand) und dem Performanceverlust, habe ich das Netz aber dahingehend geändert wie SPS-Bitschubser es vorgeschlagen hat.
Also IPC per PN an VIPA und die Erweiterungen per PB im Singlemastersystem des IPC.

Ich hatte den PN-Port der VIPA tatsächlich erst nach dem Einlesen des Geräteproxys in TIA bemerkt. An der Anlage selbst war der so unscheinbar versteckt.

Ist im Grunde die bessere Lösung, nun kann ich auch über dieses PN-Netz auf die VIPA zugreifen und muss nicht den USB-Adapter hernehmen, um eine Programmänderung zu machen.

1641458131452.png

Also ich hab solch ein Profibus-Multimaster-System in der Realität noch nirgends gesehn... Jetzt geh ich mal davon aus, dass Generationen von Automatisierern jetzt nicht zu doof dazu warn, sondern aus gutem Grund sowas nicht benutzt haben. Ich vermute aber eh, dass dazu auch HW-Konfig-Änderungen in der Vipa notwendig wären....

PS: ich würd dann auf jeden Fall ne 2. Profibus-Karte in den IPC einbauen. Dann bleiben die 2 Profibusse schön getrennt
Nein, habe hierzu keine Anpassungen der HWConfig an der VIPA vornehmen müssen.

Das ganze ist ein Drechshaufen - Sorry muss es sagen.
Jop, aber so ist es nunmal^^

Es soll möglich sein die MP270B HMI von Protool nach WinCC Flexible zu migrieren und weiter nach TIA WinCC RT.
Dasselbe mit das VIPA/318-2PN/DP Prgramm, migrieren nach WinAC.
Es muss möglich sein dies in ein Tag zu erledigen inklusiv ein Test das es funktioniert.

Dann hast du ein einfachen Projekt ohne besonderheiten und es ist viel einfacher zu warten. Ich wurde zuerst die Erweiterung mit die BK3100 machen nach diese Migrierung.
Der BK3100 hatte Prio, weil die Anlage nächste Woche wieder produzieren soll.
Das wird nun sukzessiv so kommen werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In Prinzip muss in ein Profibus Netz alle Teilnehmer, masters und slaves, in die Berechnung von TTR berücksigtigt werden.
Ja, Profibus ist schon ziemlich unempfindlich. Da kann man viel falsch machen, und es funktioniert trotzdem, erstmal, ausser Sonntag Abend... ;)
 
Es funktioniert, weil das Profibus Schnittstelle in der VIPA jetzt unbenutzt ist.
In Prinzip muss in ein Profibus Netz alle Teilnehmer, masters und slaves, in die Berechnung von TTR berücksigtigt werden.
Doch doch, der Profibusport der VIPA wird benutzt. Da hängen noch 6 weitere Teilnehmer dran.
Ich wollte den BK3100 nur dort nicht direkt hin hängen und auch über die VIPA zugreifen, weil ich deren aktuelle HWConfig nicht habe.

Die eingebundene VIPA im TIA ist nur der Geräteproxy ohne Darstellung dessen Profibusnetz.
 
Zurück
Oben