TIA 1 bit übertragung

litlegerman

Level-2
Beiträge
352
Reaktionspunkte
13
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
wir planene ein Projekt mit mehreren SPSn
eine Haupt SPS (1515f)
unn bis zu 13 neben SPSn (et1512-f cpus)
die sollen über pn verbunden werden.
Der Plan ist jetzt die et cpus mit dem gleichen projekt zu versehen und sie mit dem T_config (ip-adresse)zu ändern.
Die erkennung, welche cpu welche adresse bekommt wollte ich über eine einfache ein 1Bit Kommunikation realisieren.
die Haupt sps stellt 13 ein/ausgänge zur verfügung diese biden unterschiedliche impulsfolgen die et-cpus empfangen das und stellen die ip adresse passend ein.
Die frage wäre- gibt es was fertiges für die ein Bit Kommunikation
Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hatte hier mal was geschrieben:
 
Zwischen den F-CPU läuft keine Safety-Kommunikation?
Wenn Du identische Gerätekonfig auf mehrere CPU im Netz lädst, dann sind auch die Gerätenamen gleich. Stört das nicht die Profinet-IO-Kommunikation?

Wie oft soll sich Dein System umkonfigurieren? Wird das nicht einfacher und sicherer, einfach vor dem Laden in eine CPU jeweils die IP-Adresse in der Gerätekonfig zu ändern?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
Danke für die rege Diskussion.
Ja ich habe hier auch Hmis, die sind jeweils an jede neben CPU (et-sp) via Profibus angebunden.
Wenn ich das mit der „Auto-Konfiguration“ nicht hinbekomme wäre das meine nächste Idee, dass am Hmi einzustellen.
Wegen dem umstellen der IP könnte es in der Zukunft so sein, das die Plätze der der CPUs mehrmals die Woche getauscht werden, also müssten sich die IP Adressen dann umkonfigurieren.
Ja es gibt auch Safety Kommunikation, aber das sollte mittels Send/Recive Id Anpassung über F-I-device kein Problem sein.
Das mit dem DHCP ist ne interessante Sache, aber benötige es leider so:
Die ET-CPUs stehen alle hintereinander 1-13 also wenn ich jetzt 1 und 3 tausche soll es nachher trotzdem wieder 1-13 sein, das wäre ja nicht der Fall wenn ich die Mac als Orientierung benutze, außerdem könnte mir sogar in Zukunft auch eine „fremde CPU“ ins System kommen…
Und wieso sollte es ein Problem für den Instandhalter werden?
Der Gerätename wird von der 1515f geschrieben…
Gruß
 
Warum sollen sich die IP Adressen ändern? Würde doch reichen, wenn die SPSn die Position kennen und somit Ihre Logik dementsprechend abarbeiten?... Vielleicht kann die Position mit RFID oder sowas sogar automatisch erkannt werden.
 
Wird das jetzt zum Running Gag? Haben die Instandhalter auch Schuhe mit Klettverschluss?
Nein wird es sicher nicht,
aber wenn ich mich auf so ein System mit TIA draufschalte und erstmal suchen muss, welche IP für welche CPU gilt, dann ist das schon mal nicht so einfach. Klemmt dann was bei der Ein-Bit-Übertragung, dann wird's noch spannender.
Die CPUs hängen alle am gleichen Profinet ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wird das jetzt zum Running Gag? Haben die Instandhalter auch Schuhe mit Klettverschluss?
Wo ist denn das Problem, wenn die Software im Nachhinein vom Großteil des Personals gelesen und verstanden werden kann und nicht nur von den besten 10%?

Mir ist eine Lösung, die für den ursprünglichen Programmierer mehr Aufwand bedeutet, viel lieber, wenn sie dadurch für die Instandhaltung wartbarer wird. Gutes Beispiel was ich erst vor kurzem in einer neuen TIA-Anlage sehen "durfte": Mit AWL 2 Pointer zusammen basteln und danach nen Blockmove, statt das Ganze Sauber im Symbolisch zu adressieren und einfach umzukopieren. Da war nichts variabel im Code, das hätte jeder SCL-Einzeiler gelöst, aber der Programmierer meinte, dass geht so, warum soll man das anders machen?
 
Warum sollen sich die IP Adressen ändern? Würde doch reichen, wenn die SPSn die Position kennen und somit Ihre Logik dementsprechend abarbeiten?... Vielleicht kann die Position mit RFID oder sowas sogar automatisch erkannt werden.
Ja an RFID hatten wir auch schon gedacht…
Aber mir ist grad eingefallen, das es auch einfacher geht…
Ich benutze Bit-Codierung in den Steckern 4 Bits sollten reichen, mit Brücken in den Steckern
 
das hätte jeder SCL-Einzeiler gelöst
und welcher Instandhalter versteht SCL?

zurück zum Thema...

Die IP-Adressen ändern finde ich auch eine extrem schlechte Idee.
Mit der ersten kleinen Änderung im Programm (nach der Inbetriebnahme) bricht das Chaos aus.
Auch das Profinet wird extrem undurchsichtig (Namensvergebung)

Kurzum, am besten für jede CPU ein eigenes Programm im Projekt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem ist dass die Maschinen standardisiert und 100% identisch sein muss ?
Ich hatte alles auf Ethernet/PN gehalten, und mit ein NAT die identische Maschinen zusammengebunden.
Mit die NAT werden die Maschinen Netzwerke getrennt, die IPs werden in die NAT getauscht so dass alle Maschinen miteinander kommunizieren können.
So machen wir es wenn wir parallel installierte und identische Maschinen hat.
Wäre einfacher, flexibler, vermutlich kostengünstiger, und mMn. Stand der Technik.

edit:
Wenn die Maschinen umgetauscht werden dann muss der Instandhalter nichts tun (*). Wenn die getauschte Maschinen verbunden werden mit die Netzwerkkabeln die nach den NAT geht, dann passiert die 'Umverdrahtung' automatisch.
*: Ausser die Sicherheitsfunktionen, die muss er testen und protokollieren.
 
Zuletzt bearbeitet:
wenn nur 1 Projekt für alle 13CPUs verwendet wird, sind Code-Änderungen leichter umzusetzen, als bei 13 Einzelprojekten.
Sollte zusätzlich Safety Kommunikation zum Einsatz kommen, sind die F-Kommunikations-IDs auch zu verwalten
 
Also ich würde da folgendes machen:

Alle CPU gleiches Programm aber individuelle IP und Name.

Wird CPU X am Platz Y eingesetzt dann über deine HW Lösung den "Platz" im Programm auswerten und entsprechend reagieren.

Jetzt ist noch die Frage: HMI, soll das dem Platz zugeordnet sein oder der variablen CPU?

ich vermute mal wechselt den Platz mit der CPU.

Dann auf alle HMI die Selbe Software, die kann ja dann Fix der CPU zugeordnet sein und über die CPU dann über den Platz die entsprechenden Bilder darstellen.

Wenn das HMI am Platz bleibt wird es etwas komplizierter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich würde da folgendes machen:

Alle CPU gleiches Programm aber individuelle IP und Name.

Wird CPU X am Platz Y eingesetzt dann über deine HW Lösung den "Platz" im Programm auswerten und entsprechend reagieren.

Jetzt ist noch die Frage: HMI, soll das dem Platz zugeordnet sein oder der variablen CPU?

ich vermute mal wechselt den Platz mit der CPU.

Dann auf alle HMI die Selbe Software, die kann ja dann Fix der CPU zugeordnet sein und über die CPU dann über den Platz die entsprechenden Bilder darstellen.

Wenn das HMI am Platz bleibt wird es etwas komplizierter.
ja, warum sich die IP-Adressen ändern sollen, hat der TE ja noch nicht verraten... 🤷‍♂️

ich würds auch so machen... Die IP bleibt fix.. je nach Position wird halt FC1 oder FC2 ... oder FC13 in der Steuerung abgearbeitet...
 
Vielleicht macht mal jemand einen Verbesserungsvorschlag an Siemens an die TIA-Entwickler, wie man mehrere PLC mit identischem Programm im TIA-Projekt besser organisieren kann. Anscheinend ist das ja eine hochkomplizierte und aufwändige Sache, 15 PLC mit (teilweise oder voll) identischem Programm im TIA zu verwalten und identisch zu halten? Oder gibt es in TIA schon ein dafür vorgesehenes Verfahren?

Ich hatte mal mit dem alten PG5 Projekt Manager Entwicklungssystem von SAIA zu tun, da war sowas wesentlich besser organisiert. Da kann man im Program Files Ordner der einzelnen PLC auf gemeinsame Quellcode-Dateien in gemeinsamen Ordnern verlinken und braucht dann z.B. nur eine einzige Quelle bearbeiten und kann sofort anschließend alle PLC komplett übersetzen. Oder ist das zu einfach für Siemens?

Harald
 
Geht das vielleicht, wenn man alles in Bibliotheken programmiert, und diese dann in den SPS verlinkt?

Update der Lib -> Alle SPS neu übersetzen -> Happy?!

Grüße

Marcel
 
Zurück
Oben