TIA Umstieg auf S7-1500

[Oliver]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wir haben unbewußt den Umstieg auf die 1500 gemacht. Wir hatten bisher immer die ET200SCPU eingesetzt und haben jetzt umgeswitcht auf die ET200Sp natürlich auch mit derer CPU. Und da ist eine 1500 drin.

Das gejammer über das TIA Portal möchte ich nicht fortsetzen, da ich junge unerfahrene Programmierer erlebt habe die sich viel leichter tun im TIA als im S7.
Bei mir als "erfahrener" Programmierer ist das natürlich anders.

Und in die Fußstapfen tritt (glaube ich) die 1500 auch.

zum Beispiel haben wir festgestellt, das Teilnehmer mit einem konsistenten Datenübertragung ( bisher ) kein SFT14 und 15 benötigt wird.
Ist für einen routinierten Programmierer nicht nachvollziehbar. Ist aber so.

Nun meine Frage, hat einer von euch eine Darstellung was bei der 1500 alles anders ist, im Gegensatz zur 300er.

Bei Siemens habe ich nur Darstellungen gefunden wie toll die 1500 ist, im Zusammenspiel mit TIA.

Würde mich freuen, wenn mir da jemand helfen würde.

 

[Gleichstromer]

Vergleichsliste 300/400/1200/1500
Programmierleitfaden und Styleguide

In diversen Threads zu Leitfaden/Styleguide gibts weitere Infos zu TIA-"Features"

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

zum Beispiel haben wir festgestellt, das Teilnehmer mit einem konsistenten Datenübertragung ( bisher ) kein SFC14 und 15 benötigt wird.
Ist für einen routinierten Programmierer nicht nachvollziehbar. Ist aber so.

Ist in Wahrheit nicht viel anders als bei der 300/400.
Die 1500 legt nur von Haus aus den ganzen Teilnehmer ins Prozessabbild.
Man kann auf einen Teilnehmer dessen Daten z.B. auf Adresse 1024 dann einfach mit ED1024 zugreifen.
Das kann man bei der 300/400 eigentlich auch machen in dem man einfach die Größe des Prozessabbilds erhöht.
Machen hier viele so.

Insofern ist es bei der 1500 praktischer das man sich von Haus aus keine Gedanken machen muss wie groß jetzt das Prozessabbild eingestellt ist und ob der Teilnehmer noch drinnen liegt.

Konsistent ist die Sache aber auch nur dann wenn der Teilnehmer selbst Konsistenz (Module mit Konsistenz) unterstützt.
Egal ob 300 oder 1500. Also immer schön vorsichtig...

 

[Oliver]

Danke, mal lernt eben nie aus.

;-)

 

[vollmi]

Insofern ist es bei der 1500 praktischer das man sich von Haus aus keine Gedanken machen muss wie groß jetzt das Prozessabbild eingestellt ist und ob der Teilnehmer noch drinnen liegt.

Zu erwähnen ist noch, dass die 1500er auch Teilnehmer welche über CP eingelesen werden (sei es Profibus oder Profinet) direkt ins Prozessabbild legt. Also kein kopieren in einen DB wie bei der 300er 400er.

mfG René

 

[Oliver]

Zuviel Werbung?
-> Hier kostenlos registrieren

Des weiteren nutzen wir auch eine Netzwerkkommunikation zu einem IPC.

Dazu nutzen wir den TCON TSEND und TRECV.

Das funktioniert nach der Migration auch nicht mehr.

An den TCON legt man die IP Adresse , Port und eine ID für den Controller in der S7 CPU.
Diese ID hat man schon immer ändern müssen, ( zwischen ET200SCPU und S7-300 )


Hat mit de jemand noch einen TIP was es da bei der S7-1500 bzw. ET200Sp beachten muss.

Wäre euch sehr dankbar.

 

[Thomas_v2.1]

Zu erwähnen ist noch, dass die 1500er auch Teilnehmer welche über CP eingelesen werden (sei es Profibus oder Profinet) direkt ins Prozessabbild legt. Also kein kopieren in einen DB wie bei der 300er 400er.

Der Zieldatenbereich der SFC kann auch der Eingangsbereich sein, solange dieser noch nicht vom Prozessabbild verwendet wird. Dann kann man auch bei den Daten von DP-Baugruppen an externen CPs mit Ex.y zugreifen, oder Ax.y schreiben.

 

[RONIN]

Was 2 der größeren Unterschiede zwischen 1500 und 300er sind, die wir hier in letzter Zeit hatten:

S7-1500 HMI-Kommunikation (Zykluskontrollpunkt)

Die 1500 kommuniziert mit dem HMI nicht mehr zwischen Zyklusende/Anfang sondern zwischen drinnen.
Also nicht mehr an einem fixen Punkt (Zykluskontrollpunkt), heißt die HMI liest/schreibt irgendwo mitten im Programm rein.
Das muss man im Hinterkopf haben. Vor allem bei IN/OUT-Paramtern in FB's oder generell wenn man im Programm
an mehren Stellen einen Datenpunkt einliest den z.B. auch die Visu beschreibt. Da hat man dann eventuell 2 verschiedene Werte im Zyklus.
Die 1500 arbeitet hier so wie die 400 oder die 300 mit aktivierter Option "priorisierte BuB-Kommunikation".
Bei Migration von alten Fremdprogrammen kann man nicht garantieren dass die Steuerung dabei nicht auf die Nase fällt

Hier muss man aufpassen, sonst fällt man schnell auf die Nase.
http://www.sps-forum.de/simatic/71057-zykluskontrollpunkt-s7-1200-und-s7-1500-mit-hmi.html?highlight=BuB
http://www.sps-forum.de/simatic/683...on-zykluskontrollpunkt.html?highlight=TiA+BuB

Hier hat Siemens das Problem auch nochmal offiziell erklärt.
https://support.industry.siemens.com/cs/de/de/view/109478253


​

Verhalten der IEC-Timer

Aktualisierungsverhalten - Siehe Hier
http://www.sps-forum.de/simatic/79331-s7-ton-timer-funktioniert-nicht.html​

Resetverhalten - Siehe Hier​

http://www.sps-forum.de/simatic/77908-s7-1500-timer-resetieren.html
Bei der 300/400 kann man einen TOF/TP resetten in dem man die Instanz einmal mit T#0ms am PT aufruft.
Das setzt natürlich auch voraus dass die Timer nur Zeitvorgaben > T#1ms bekommen dürfen.
Bei der 1200/1500 schaltet der Timer jetzt bei T#0ms sofort durch. Für Reset gibt es eigene Befehle.

Wenn man die T#0ms bei 300/400 verwendet hat, ist das ein weiterer Punkt den man bei einer etwaigen Hochrüstung nicht vergessen darf.
Das neue Verhalten bei T#0ms ist aber logischer.

Geändertes Verhalten bei Änderung des Zeitwerts wenn der Timer läuft.
IEC Timer, wesentliche Unterschied zwischen S7-300 und S7-1500 !?
​

Peripheriezugriff via DPRD_DAT oder DPWR_DAT

Die Bausteine der 300/400 erwarten am Parameter ADDR den Peripherie-Adresse (IO-Adresse).
Bei der 1500 muss die Hardware-ID übergeben werden. Damit müssen schon mal sehr viele Bibliotheks-FBs angepasst werden.
Schlimmer noch wenn die einen KnowHowProtect haben und der DPRD/DPWR drinnen verwendet werden.


​

Allein durch die 3 Punkte wird in Wahrheit ein Migrieren von 300 auf 1500 schon sehr schwierig.
Am besten man versucht es gar nicht erst.

​

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Des weiteren nutzen wir auch eine Netzwerkkommunikation zu einem IPC.
Dazu nutzen wir den TCON TSEND und TRECV.
Das funktioniert nach der Migration auch nicht mehr.

Hab ich heute auch feststellen müssen als ich aus Zeitgründen versucht hab schnell nen Baustein zum Auslesen eines Messgerät zu konvertieren.

An den TCON legt man die IP Adresse , Port und eine ID für den Controller in der S7 CPU.
Diese ID hat man schon immer ändern müssen, ( zwischen ET200SCPU und S7-300 )

Hat mit de jemand noch einen TIP was es da bei der S7-1500 bzw. ET200Sp beachten muss.
Wäre euch sehr dankbar.

Anscheinend hat sich da mehr getan.
Der TCON hat bei mir, als ich ihn mit nem ANY-Pointer (auf einen TCON_PARAM im STAT-Bereich des Vorgänger-FBs) gefüttert habe,
den Fehlercode für "Länge das Paramtrierdatensatzes inkorreket" rausgeworfen.
Ein im OB1 aufgerufener TCON mit dem TCON_PARAM in einem Global-DB war auch nicht zufrieden.

Wenn man den TCON dann mit der Parametrierhilfe einstellt legt TIA einen DB, abgeleitet vom Datentyp "TCON_IP_V4", an.
Der Datentyp ist ein wenig kürzer und enthält nur die nötigen Dinge für den Verbindungstyp TCP-Verbindung.

Im migrierten Baustein hab ich dann den TCON_PARAM gegen den TCON_IP_V4 ersetzt, mit allen Änderungen die dem folgen.
Und siehe da, nach ein wenig hin und her geht's wieder.

Laut dem dicken TIA-Handbuch sollte der TCON auf der 1500er eigentlich in der Lage sein sowohl den TCON_PARAM, TCON_IP_v4 als auch
den TCON_IP_RFC am Eingang für die Verbindungsbeschreibung zu akzeptieren.

Meine 1510-ET200SP-CPU v1.7 hat sich aber gegen den TCON_PARAM strikt gewehrt.
Keine Ahnung ob des ein Bug ist oder ob die 1500er den TCON_PARAM gar nicht mehr nehmen will.
Wenn ich Zeit hab mach ich noch ein paar Versuche, aber vielleicht weiß ja hier einer was dazu.

UPDATE:
Da beim S7-1500-TCON der Parametrierdatensatz über VARIANT übergeben wird, wird dann (vermutlich) intern mit VARIANT_EQ_TYPE auf "TCON_PARAM", "TCON_IP_V4", oder andere geprüft.
So kann der TCON auf die verschiedenen Parametrier-Typen reagieren. Wenn das Ergebnis der Typenabfrage allerdings "Struct" lautet, dann streikt er und wirft den Fehlercode raus.
Sofern man den TCON mit einem Datensatz der Type "TCON_PARAM" (also "TCON_PARAM" in der Spalte "Datentyp") füttert müsste dieser auch wieder gehen.
Die Info müsste noch verifiziert werden.

UPDATE2:
Ist verifiziert. TCON nimmt nur die UDTs. Keine Structs und keine Any-Pointer (auch wenn diese auf den korrekten UDT zeigen)

und eine ID für den Controller in der S7 CPU.

Der TCON_IP_V4 verwendet eine andere Kennung, die sog. "interface_id" welche auch mit "Hardware-Kennung der lokalen Schnittstelle" beschrieben wird.
Die interface_id ist aber die HW-Kennung die du bei den Systemkonstanten in der PLC-Variablen-Tabelle findest.
Das sind die Konstanten die man symbolisch anhängen kann.

Welche ID man dem TCON_PARAM bei der 1500 bekommt ist eine Frage, bei der 300er war's einfach die Nummer die in der Hardware-Konfig beim Steckplatz dabei Stand (X3 -> ID = 3).

Ich möchte aber meinen dass du auch das selbe Problem wie ich hast und der TCON deinen TCON_PARAM nicht schluckt...

obwohl eigentlich

Hinweis
TCON_Param für S7-1500 CPU
Der Verbindungsbeschreibungs-DB mit der Struktur nach TCON_Param wird aus
Migrationsgründen auch von CPUs der S7-1500 unterstützt. Es wird jedoch empfohlen, die
neuen Strukturen TCON_IP_v4 und TCON_IP_RFC zu verwenden.

Sehr komisch.... - Siehe Update oben