TIA Hilfe für Funktionsbaustein Siemens TIA Portal SCL

A

A.Gashi

Level-2
Beiträge
31
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen

Eventuell kann mir einer helfen, da ich in SCL null Erfahrung habe und ich das gerne folgendermassen umsetzen möchte:

Ich befasse mich mit Messgeräte von Janitza, wo diverse Spannungen und Ströme über Profibus an meine Steuerung kommen.
Da ich etwa 100 solche Geräte habe, würde ich am liebsten ein Funktionsbaustein schreiben. Ich lese auch immer das gleiche aus den Geräten heraus.

Ein Gerät kriegt eine Eingangsadresse sagen wir PED100. Die ersten Daten erhalte ich aber im Byte-Offset 1.
Das heisst folgendermassen ist das aufgebaut

PED101 Spannung L1
PED105 Spannung L2
PED109 Spannung L3
und so weiter...

Ich habe als Input Variablen Eingangsadresse und Ausgangsadresse.
In Eingangsadresse gebe ich zum Beispiel PED100 ein.
Bei Ausgangsadresse beispielsweise DB100.DBD0.

Ich transferiere das noch in einen DB, da ein externer Integrator die Visualisierung macht. Bei Anpassungen kann ich vorne noch was ändern, ohne das gleich der Integrator auch etwas ändern muss.

Im Anhang findet ihr noch eine kleine Skizze mit den Input/Output Variablen.
Die Eingangsadresse soll eingelesen werden und mit dem entsprechendem Byte Offset in den DB transferiert werden.

Danke im Voraus für eure Unterstützung :D
 

Anhänge

  • Janitza Funktionsbaustein.png
    Janitza Funktionsbaustein.png
    24,4 KB · Aufrufe: 48
2 UDTs erstellen, eine für die Eingangsdaten und eine für die Ausgangsdaten.
Dann kannst du komfortabel die E/A Symbolik erstellen, und auch die E/A mit die UDTs an die FB oder FC übergeben.
Innderhalb von die FB oder FC arbeitest du dann mit die Symbolik.

A.Gashi schrieb:
Ein Gerät kriegt eine Eingangsadresse sagen wir PED100. Die ersten Daten erhalte ich aber im Byte-Offset 1.
Das heisst folgendermassen ist das aufgebaut

PED101 Spannung L1
PED105 Spannung L2
PED109 Spannung L3
und so weiter...
Zum Vergrößern anklicken....
Die Anfangsadresse spezifizierst du ja selber bei die Gerätekonfiguration.
Kannst du nicht eine gerade Bytenummer wählen ?
Da ist kein Zwang dass zwischen Geräte müssen keine unbenutzte Adressen sein.
 
JesperMP schrieb:
2 UDTs erstellen, eine für die Eingangsdaten und eine für die Ausgangsdaten.
Dann kannst du komfortabel die E/A Symbolik erstellen, und auch die E/A mit die UDTs an die FB oder FC übergeben.
Innderhalb von die FB oder FC arbeitest du dann mit die Symbolik.


Die Anfangsadresse spezifizierst du ja selber bei die Gerätekonfiguration.
Kannst du nicht eine gerade Bytenummer wählen ?
Da ist kein Zwang dass zwischen Geräte müssen keine unbenutzte Adressen sein.
Zum Vergrößern anklicken....
Also meine Idee war folgendermassen: Ich habe einen UDT erstellt für ein Messgerät mit den Daten die ich auslesen will.
Diese füge ich dann ich dann in meinen DB in einen Array 0..50 of udt ein und habe schonmal sämtliche Datencontainer bereit.
Die Eingangsadresse ist gerade jedoch befinden sich im ersten Byte für mich keine relevanten Daten.
Die relevanten Daten erhalte ich im Byteoffset 1.
 

Anhänge

  • Datenbaustein.png
    Datenbaustein.png
    13,9 KB · Aufrufe: 18
A.Gashi schrieb:
Die Eingangsadresse ist gerade jedoch befinden sich im ersten Byte für mich keine relevanten Daten.
Die relevanten Daten erhalte ich im Byteoffset 1.
Zum Vergrößern anklicken....
OK, ist kein Problem. Das Programm ist halt nur ein klein bisschen langsahmer.
In dein Bild sieht man aber die erste Byte nicht.

Die Messwerte wurde ich nich als ein Array[0..6] OF REAL machen.
Da ist kein Grund dafür. Es macht nur die Programmcode unlesbar.
Definiere die Messwerte einzeln und mit erklärender Namen. Z.b. ".Spannung_L1" anstatt ".Messwert[0]".

Auch die übergeordnete Niveau wurde ich nicht als ein ARRAY[0..50} OF UDT machen, und auch nicht die FB mit eine FOR Schleife machen.
Dies ist für die Online Fehlersuche problematisch.
Das man 50-mal ein FB aufrufen muss und die E/A für jeden FB angeben muss ist aufwendiger als 1 FB mit eine FOR Schleife, aber das ist ja in eine halbe Stunde erldigt.
 
Ich würde die Schnittstellendaten einfach mittels DPRD_DAT und DPWR_DAT auslesen und beschreiben. Dann einfach die HW_IO-Adressen außen vom Baustein als Eingänge übergeben lassen und fertig.

Dann muss man nurnoch die HW_IO-Adressen symbolisch von Baustein zu Baustein anpassen.

Die symbolischen Adressen kann man dann via Suchen und Ersetzen super schnell und einfach in den jeweiligen Aufrufen passend ändern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DPRD_DAT und DPWR_DAT bitte nur nur auf E/A-Bereiche anwenden, die keinem Prozessabbild zugeordnet sind. Gibt sonst Probleme (PN-Störungen). Ist zwar vom Handling in der Entwicklung angenehm, nach meiner Erfahrung im Betrieb aber problematisch.
Allgemein ist es jetzt bei den 1500er schneller alles ins jeweilige PA zu legen und das Aktualisieren der CPU zu überlassen.
Laut Beschreibung sind die Daten für die üblichen Clients jetzt konsistent. Wahrscheinlich ist die Packetgröße die Grenze.
 
Ingmar64 schrieb:
DPRD_DAT und DPWR_DAT bitte nur nur auf E/A-Bereiche anwenden, die keinem Prozessabbild zugeordnet sind. Gibt sonst Probleme (PN-Störungen). Ist zwar vom Handling in der Entwicklung angenehm, nach meiner Erfahrung im Betrieb aber problematisch.
Allgemein ist es jetzt bei den 1500er schneller alles ins jeweilige PA zu legen und das Aktualisieren der CPU zu überlassen.
Laut Beschreibung sind die Daten für die üblichen Clients jetzt konsistent. Wahrscheinlich ist die Packetgröße die Grenze.
Zum Vergrößern anklicken....
Welche Probleme gibt es denn genau mit DPRD_DAT und DPWR_DAT?
 
Ich wundere mich auch, wieso für eine S7-1500 DPRD_DAT und DPWR_DAT empfohlen werden. Liegen bei der S7-1500 nicht alle E/A automatisch im PA?
Bei S7-300/400 soll man tatsächlich DPRD_DAT und DPWR_DAT nicht verwenden, wenn die E/A im PA liegen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nach unseren Erfahrungen gibt es zufällige PN-Verbindungsabbrüche zu Clients, die mittels dieser Funktionen und dem Prozessabbild, also doppelt, angesprochen werden. Die Hilfe schweigt sich da ein bißchen aus, ich vermute aber, daß DPRD_DAT und DPWR_DAT analog zu PE und PA direkte Zugriffe auf die Hardware, also die Clients, durchführen und so den Bus aus dem Tritt bringen. Wenn meine Vermutung stimmt, ist der Zugriff über das Prozessabbild auch schneller, da die Aktualisierung ja außerhalb des Zyklus stattfindet.
Das Problem existiert nach meinen Erfahrungen sowohl bei der Einstellung "Automatisch" als auch bei der Zuordnung zu einem konkreten Prozessabbild.
Wie gut es funktioniert, wenn die Einstellung "Ohne Aktualisierung" ausgewählt wird, haben wir nicht getestet. Ich meine aber, irgendwo die Empfehlung gelesen zu haben, diese Einstellung dann anzuwenden.

Bei 300er CPU war es noch verboten, per Prozessabbild und DPRD_DAT und DPWR_DAT auf Clients zuzugreifen, da kam eine Fehlermeldung zurück.
 
@PN/DP: Die Standardbausteine mindestens einiger FU-Hersteller (SEW, Festo, LinMot, ...) und etlicher Messsysteme verwenden DPRD_DAT und DPWR_DAT. Das erkennt man daran, daß die Schnittstelle die HW_Id enthält und keine E/A-Adressen. Ich habe für uns diese Bausteine entsprechend abgeändert. Seitdem haben wir deutlich weniger Kommunikationsprobleme.
 
PN/DP schrieb:
Liegen bei der S7-1500 nicht alle E/A automatisch im PA?
Zum Vergrößern anklicken....
Wenn in die Gerätekonfiguration für den E/A Modul Process Image auf Automatic update eingestellt ist, dann ja. Dies ist den normalen Wert. Man muss es manuell auf none einstellen wenn es in den PA nicht sein soll.

Ingmar64 schrieb:
Bei 300er CPU war es noch verboten, per Prozessabbild und DPRD_DAT und DPWR_DAT auf Clients zuzugreifen, da kam eine Fehlermeldung zurück.
Zum Vergrößern anklicken....
Was meinst du hier mit 'Clients' ?
Bei die S7-300/400 muss man DPRD_DAT/DPWR_DAT verwenden wenn die E/A ausserhalb von das Prozesabbild liegen und man mehr als 4 Bytes konsistent lesen oder schreiben will.
Nach den zweiten lesen kapiere ich was du meinst.
Versucht man DPRD_DAT oder DPWR_DAT mit Adressen die innerhalb von PA befindet, dann bekommt man ein Fehlermeldung.
Das stimmt.
Laut die online Hilfe in TIA gelt dies auch für S7-1500.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist Quatsch zu behaupten, dass mit den genannten Bausteinen, pauschal Fehler im ProfiNet auftreten.

Dass mit DPRD_DAT / DPWR_DAT mehr Zyklusbelastung / Netzwerklast auftritt, ist auch klar, da eben mit den Peripherie-E/A's gearbeitet wird.
Wenn man mit den Peripherie E/A's arbeitet, sollte man auch nicht mehr mit den "gleichen Adressen" vom Prozessabbild arbeiten, auch klar.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich behaupte nichts, ich berichte meine Erfahrungen.
300er CPU: DPXX_DAT wird immer mit Fehler (nicht erlaubt) beendet, wenn Adresse im E/A-Abbild.
1500er CPU: DPXX_DAT wird dann alle paar Zyklen mit Fehler (Kommunikationsfehler) beendet. Das hat mich auf die Idee gebracht, dort zu suchen.

Ich habe dann die FB umgestrickt und war damit auch die sporadischen PN-Fehler los. (Client nicht erreichbar) Es gab auch keine Fehlpositionierungen mehr, die vorher auch hin und wieder auftraten.
.
Ich habe nicht untersucht, ob das immer mit allen Geräten so ist, dazu fehlt mir die Zeit. Deshalb behaupte ich auch nicht, dass es immer so sein muß. Meine Erfahrung basiert auf SEW- und Festo - FU, mehr als 15 je Anlage.
 
Zuletzt bearbeitet:
Ich arbeite seit 15 Jahren mit DPXX_DAT-Bausteinen in meinen Anlagen und Standardbausteinen.

Die laufen in etlichen großen Produktionslinien seit Jahren ohne Probleme, Ausfälle oder Ungenauigkeiten.

Deswegen kann ich diese pauschalen Aussagen von Einzelnen, die behaupten das würde nur Probleme mitsich bringen nicht nachvollziehen.
 
Ich habe das nicht pauschal behauptet, sondern ein Fehlerbild beschrieben.

Als ich vor 19 Jahren mit SPS unter Classic angefangen habe, war die Anwendung der DPXXX_DAT die einzige und richtige Möglichkeit, um Daten>4Byte konsistent von einem Client einzulesen und das PA stand auf 128Byte Standardgröße. Gab es Kollisionen wie oben von mir beschrieben, gab es einen entsprechenden Fehler und man konnte und musste den Konflikt auflösen.

Die 1500er Serie läßt nun beides parallel zu, aus welchen Gründen auch immer. Tatsache ist, daß dies unter bestimmten Bedingungen z.B. Gerätekombinationen zu Problemen führen kann. Darauf habe ich aus meiner Erfahrung hingewiesen.
Der oben von mir beschriebene Fehler im Ret_Val ist auch keine Behauptung von mir sondern eine Beobachtung und insofern keinesfalls pauschal.
Technisch vorstellbar ist für mich auf jeden Fall, das Erzwingen von direkten Client-Zugriffen außerhalb des normalen PN-Zxklus durch Anwendung von DPXXX_DAT zu Überläufen im PN(IP)-Stack führen kann, da dieser nur eine bestimmte Größe hat. Das passiert wahrscheinlich noch nicht bei wenigen Geräten, doch bei >20 Geräten scheint es so zu sein, sicher auch abhängig von der CPU, bei einer 1511 sicher eher als bei einer 1518.

Allgemeine Bemerkung: Ich hatte das Anliegen des Forums bisher so verstanden, daß hier Erfahrungen geteilt werden um anderen bei der Lösung von Problemen zu helfen. Ich bin dankbar für für alle Tipps, die ich hier gefunden habe.
 

Similar threads

D
TIA SCL Anfänger
2
Antworten
23
Aufrufe
1K
Dekuika
Dekuika
D
Step 7 Funktionsbausteine in STEP 7 in SCL
Antworten
10
Aufrufe
2K
Oberchefe
O
A
Step 7 Programmierung erleichtern
Antworten
7
Aufrufe
2K
sunny22
S
T
TIA SICK RFU630-13100 Daten lesen in TIA
Antworten
8
Aufrufe
1K
TIA1234TIA
T
A
TIA Adresse in AWL generieren
Antworten
3
Aufrufe
2K
--alex--
A
Zurück
Oben