TIA CPU und Panel separieren

Computerfahrer

Level-1
Beiträge
7
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS Gemeinde,

ich stehe vor der Aufgabe ein TP1200 Comfort Panel in ein separates Projekt auszulagern.
Meine Frage hierzu ist, wie sich dann die CPU-PLC-Kommunikation mit der HMI gestaltet? Mein erster Gedanke war die Umsetzung mittels IO-Device.
Eventuell hat jemand die Erfahrung und einen Lösungsvorschlag oder einen Hinweis zu meinem Gedanken.

Mfg
Computerfahrer👷‍♂️
 
Hallo Computerfahrer,

Wenn es sich hier um S7 zu Tia Panel handelt wird Sowas normal per Device Proxy gelöst. Denn fügst du dann als Stellvertreter in das Panel Projekt ein.

Gruß Stefan
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS Gemeinde,

ich stehe vor der Aufgabe ein TP1200 Comfort Panel in ein separates Projekt auszulagern.
Meine Frage hierzu ist, wie sich dann die CPU-PLC-Kommunikation mit der HMI gestaltet? Mein erster Gedanke war die Umsetzung mittels IO-Device.
Eventuell hat jemand die Erfahrung und einen Lösungsvorschlag oder einen Hinweis zu meinem Gedanken.

Mfg
Computerfahrer👷‍♂️
Siemens FAQ:
Gemeinsames Projektieren mit WinCC (TIA Portal) und STEP 7 V5.x oder gemeinsames Projektieren von WinCC (TIA Portal) und STEP 7 (TIA Portal) in getrennten Projekten
 
Du legst einfach in der SPS ein oder mehrere DBs an, welche die Daten beinhalten, die im Panel angezeigt bzw. beschrieben werden sollen.

Diese Variablen legst Du auch im Panel mit der richtigen Adresse an und fertig.

Diese DBs incl. Kommentare sind dann auch gleich die "Schnittstellendokumentaion"

IO-Device ist was ganz anderes und bringt in dem Zusammenhang nix.

Wenn Du das nicht vernünftig in DBs sortieren kannst, weil z.B. Kraut und Rüben mäßig planlos auf irgendwelche Variablen/Merker/Sonstwas in der SPS zugegriffen wird, bzw. wenn Programalarm benutzt wird, schau Dir die Device Proxy Geschichte an, würd ich für Neuanlagen aber nicht machen.

Du willst das nächträglioch trennen, oder ist das ein neues Projekt?
 
@ducati
Du legst einfach in der SPS ein oder mehrere DBs an, welche die Daten beinhalten, die im Panel angezeigt bzw. beschrieben werden sollen.

Diese Variablen legst Du auch im Panel mit der richtigen Adresse an und fertig.

Diese DBs incl. Kommentare sind dann auch gleich die "Schnittstellendokumentaion"

IO-Device ist was ganz anderes und bringt in dem Zusammenhang nix.

Wenn Du das nicht vernünftig in DBs sortieren kannst, weil z.B. Kraut und Rüben mäßig planlos auf irgendwelche Variablen/Merker/Sonstwas in der SPS zugegriffen wird, bzw. wenn Programalarm benutzt wird, schau Dir die Device Proxy Geschichte an, würd ich für Neuanlagen aber nicht machen.

Du willst das nächträglioch trennen, oder ist das ein neues Projekt?
Das ist ein neues Projekt.
 
Ja, dann mach es so, wie ichs oben geschrieben hab. In der SPS klar strukturierte nicht optimierte DBs anlegen, die als ordentliche Schnittstelle zum Panel dienen. Also z.B. einen DB für Meldungen, einen für Messwerte usw...
 
Warum willst Du das TP1200 in ein anderes Projekt als die CPU auslagern?
Welche CPU hast Du? Mit welcher Software soll die CPU programmiert werden? Mit welcher Software soll das TP1200 programmiert werden?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Computerfahrer,

WARUM willst Du das TP1200 in ein separates Projekt legen?

@ducati: Dein Vorschlag funktioniert aber nur bei nicht optimierten Bausteinen.

VG

MFreiberger
gibt halt viele Vorteile, das zu trennen... z.B. beim Tausch eines Panels, gegen was anderes/neues. Versionskuddelmuddel, nicht möglicher Online/offline Vergleich, mehrere Bearbeiter gleichzeitig usw.
 
Zuletzt bearbeitet:
Warum willst Du das TP1200 in ein anderes Projekt als die CPU auslagern?
Welche CPU hast Du? Mit welcher Software soll die CPU programmiert werden? Mit welcher Software soll das TP1200 programmiert werden?

Harald
Hallo Harald,

wegen den hier erwähnten Vorteilen https://www.sps-forum.de/threads/cpu-und-panel-separieren.105612/post-805683 @ducati - dankesehr
Verwendet wird eine ET 200SP mit einer CPU 1512SP-1 PN. Programmiert wird das ganze in TIA V15.1.
Das Panel wird mit WinCC Advanced programmiert.

VG
Computerfahrer👷‍♂️
 
Ich hatte jetzt mehrere Jahre SPS und Panel im selben Projekt... Das macht auf Dauer echt viel Ärger. Seit geraumer Zeit trenne ich Steuerung von Visu strikt.

Z.B. kann ich jetzt problemlos das Panel auf ne neue TIA Version hochziehen, oder sogar auf Unified umziehen, oder nen anderen Hersteller nehmen, ohne die SPS in Stop zu setzen oder auch nur anfassen zu müssen ;)
 
Zuletzt bearbeitet:
vielleicht...

dann funktioniert aber sicherlich nicht SPS in TIA V17 und Panel in TIA V19...

also so richtig getrennt ist es dann eigentlich nicht...
Wieso sollte das nicht funktionieren? Dafür gibt es extra die *.IPE-Dateien. Die werden im Quellprojekt exportiert und dann damit der Proxy im Zielprojekt initialisiert bzw. aktualisiert. Die sollten auch Versionsübergreifend kompatibel sein.
 
Bei verwendung vom Proxy hat mann naturlich auch das Vorteil das alle Variabelen dir zu verfügung stehen. (Attribute nicht vergessen an zu haken im Baustein).
Du musst die nicht aufwendig mit der Hand anlegen.
Und die Systemmeldungen funktionieren auch.

In meine Praxis:
Bei Migrierung von Flexible MP-Panels nach Comfortpanels hab ich das Problem nicht.
Bei uns sind die ältere Projekte mit ein Flex Panel immer Absolut adressiert worden.
Also mach ich die immer ohne Proxy.

Im Neubau und Retrofit Trennen wir jetz auch. "Uns vom TIA Vusualisierung!!!!!!!!"
Im Moment verkaufen wir nur WinCC7.4 und 7.5
 
Bei verwendung vom Proxy hat mann naturlich auch das Vorteil das alle Variabelen dir zu verfügung stehen. (Attribute nicht vergessen an zu haken im Baustein).
Du musst die nicht aufwendig mit der Hand anlegen.
Bei getrennter Projektierung des HMI-Panels würde ich zwar nicht die Siemens Proxy-PLC verwenden (weil dann kommt man wieder in den TIA-Versions-Abhängigkeits-Dschungel), ich würde aber trotzdem eine PLC wie die reale PLC im Projekt anlegen und da in den Programmbausteine-Ordner aber nur die offiziellen HMI-Koppel-DB aus dem PLC-Projekt hineinkopieren (wie von Ducati beschrieben). Dann kann man die HMI-Verbindungen und HMI-Variablen symbolisch anbinden (z.B. per Drag'n'Drop). Und der HMI/Visu-Projektierer verwendet nur die in den HMI-Koppel-DB verwendeten Variablen der somit sauber dokumentierten HMI-Schnittstelle, und kommt nicht in Versuchung auf alle möglichen (evtl. zufällig gefundenen) PLC-Variablen und -Instanzvariablen zuzugreifen.


Bei uns sind die ältere Projekte mit ein Flex Panel immer Absolut adressiert worden.
Also mach ich die immer ohne Proxy.
Alle HMI-Variablen händisch anlegen mit eintippen der absoluten Adressen?? *omg* Das ging auch in WinCC flexible und ProTool schon komfortabler durch Integration ins Step7-Projekt. Dann kann man durch die PLC-Variablen browsen und sie symbolisch auswählen ohne die Adressen eintippen zu müssen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Alle HMI-Variablen händisch anlegen mit eintippen der absoluten Adressen?? *omg*
Wenn man die Koppel-DBs sinnvoll aufbaut, ist das nicht viel Arbeit, evtl. hilft auch Excel.
Ansonsten macht man das ja nur einmal, beim nächste Projekt ist es ja schon da... ;)
 
Hallo,

ich/wir separieren seit Jahren Steuerungs- und HMI-Projekte nach dem Modell "Ducati" (und von Harald nochmals anschaulich beschrieben), und zwar neben den erwähnten Vorteilen hauptsächlich deshalb, damit UNABHÄNGIG die jeweiligen Spezialisten an den Projekten arbeiten können.

Ich brauche in meiner Firma nur die Entwicklungsfortschritte unserer Projekte/Programme mit der jeweiligen Bearbeitungsweise ins Verhältnis setzen:
+ EIN Programmierer für ALLE Automatisierungsbereiche -> Diese Person versank/versinkt im Tagesgeschäft, Weiterentwicklung fast Fehlanzeige
+ Steuerungs- plus HMI-Spezialist -> Verbesserung/Weiterentwicklung der Projektbasis findet endlich statt, Funktionsumfang der Maschinen vergrößert(e) sich.


Gruß, Fred
 
Zurück
Oben