TIA Variable Analogeingangsadresse

[Jonathan_1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallöchen,

zuerstmal bin ich noch Student und befasse mich erst seit kurzem mit SPS-Programmierung, also kann es auch sein, dass die Antwort sehr naheliegend ist und ich einfach keine Ahnung habe.
Meine Aufgabe besteht im modularen Aufbau einer Sensorüberwachung. Im Funktionsblock wird ein Wert eines Drucksensors mit mitgegebenen Werten verglichen und bei Überschreitungen werden meine digitalen Ausgänge gesetzt. Da die Anzahl an Sensoren jedoch variabel sein soll, habe ich mit einem Merker und der Jump Funktion eine Schleife implementiert, die mein oberes Netzwerk so oft wiederholt wie ich Drucksensoren habe.
Jetzt ist meine Frage ob es möglich ist, dass ich aus dem Merker, den ich unter %MW1 habe, mir meine Analoge Eingangsadresse für meinen Drucksensor zu errechnen, um nicht immer den selben Sensorwert zu vergleichen. Also hierbei meine ich berechnen die Übergabe in TIA-Portal, dass man das prinzipiell berechnen kann ist ja logisch und an sich sehr einfach.
SPS ist eine S7-300, wobei wir auch Zugriff auf eine 1500er haben und ich glaube es ist TIA V13.

Vielen Dank schonmal,
Jonathan

 

[TP-Inc]

Hallo,

Das ist möglich, jedoch wird dir niemand hier dazu raten, da es sehr umständlich durchschaubar, schwierig zu debuggen, und in keinen Querverweisen erscheint. Besser eine Funktion schreiben und die mehrmals mit verschiedenen Parametern aufrufen.

Wenn du es unbedingt machen willst geht es in AWL mit speicherindirekter Adressierung, in SCL mit PEEK.

https://support.industry.siemens.co...cl-auf-eingangsbyte/111266?page=0&pageSize=10

 

[Howard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,
eigentlich hast du schon alles Richtig gemacht - bis auf die Schleife. Rufe deinen FB doch einfach x-mal auf und verschalte die jeweiligen Eingangswörter der Analog-Karten. Das versteht jeder und man findet jedes Eingangswort, wie von TP-Inc bereits geschrieben, auch wieder - falls man mal irgendwo einen Fehler suchen muss.
Wenn es unbedingt eine Schleife werden muss, dann solltest du deine Analogwerte und deine Parameter (Datenbaustein_1.Druck) auch "Schleifentauglich" zusammenstellen. Also am besten in Form eines Arrays. Bspw. deine Parameter als Array of UDT_Parameter und einen weiteren DB mit einem Array of Word für deine Analogsignale.

Und bedenke, dass ein FB mit seiner zugehörigen Instanz in einer Schleife auch nur bedingt Sinn macht. Wenn du einen FB gewählt hast, weil dort drin bspw. Timer laufen oder Werte in den Statics zyklusübergreifend gespeichert werden müssen, dann ist es sehr wahrscheinlich nicht richtig, diese eine Instanz mit unterschiedlichen Eingängen zu nutzen

 

[ms_gp]

SPS ist eine S7-300, wobei wir auch Zugriff auf eine 1500er haben und ich glaube es ist TIA V13.

Mein Voschlag wäre:

1. Nicht auf der S7-300 lernen, ist ohnehin veraltet. Nimm die 1500, wenn du jetzt anfängst zu lernen.
2. Vergiss AWL. Das ist ebenso veraltet.
3. Vergiss MERKER. Ebenso veraltet.

Ansonsten so machen wie Howard gesagt hat. Die Schleife aber bitte in ST/SCL programmieren, nicht mit Sprüngen. Mit Sprüngen programmiert man nicht mehr seit vor meiner Geburt.

So, und jetzt könnt ihr mich steinigen

 

[Jonathan_1]

Vielen Dank erstmal für die schnellen Antworten.
Ich bin heute dazu gekommen, die Vorschläge umzusetzen und auszuprobieren. Zuerst wusste ich nicht, dass man den OB1 nach löschen neu in SCL erstellen kann, das erleichtert natürlich vieles und ich habe die Funktionen in Schleifen aufgerufen. Außerdem sind diese Funktionen nur einfache Vergleicher, also sollte das mit der Schleife keine Probleme bereiten.
Als weiteres habe ich dann die PEEK Funktion gesucht, jedoch schlägt mir TIA hierbei keine vorgefertigte Funktion vor (Es ist V13). Also habe ich den Arrayansatz implementiert. Sieht jetzt so aus wie auf dem angehängten Screenshot, das ist halt jetzt immer Implementierungsarbeit, wenn da was geändert wird, aber war das so euer Vorschlag?
Und nochmal kurz warum ich so umständlich programmiere, an sich ist mir klar, dass wenn man neue Sensoren anschließt oder auch neue Analogmodule um die SPS zu erweitern muss man zwingend das Programm anpassen. Unsere Betreuer/Aufgabenstellung will aber darauf hinaus nur durch Anpassung modularer Werte, die ich in einem Datenbaustein gespeichert habe (die man evtl. auch von außen ändern könnte), das Verhalten des Programms, Meldungen und Sensoranzahl zu ändern und somit den Aufwand zu minimieren.

Danke für weitere Tipps
Jonathan

 

[Howard]

Zuviel Werbung?
-> Hier kostenlos registrieren

... Zuerst wusste ich nicht, dass man den OB1 nach löschen neu in SCL erstellen kann, das erleichtert natürlich vieles ...

Du kannst die Bausteine auch als FUP-Bausteine erstellen, bei den neuen Steuerungen kann man dadurch dann auch einzelne Netzwerke in unterschiedlichen Sprachen hinzufügen. Also bei einer 1500er bspw. AWL, FUP und SCL gemischt.
Tipp: Grundsätzlich sollte man sein Programm aber in Funktionen und Funktionsblöcken, also FCs und FBs gliedern und diese dann im OB1 aufrufen.

Als weiteres habe ich dann die PEEK Funktion gesucht, jedoch schlägt mir TIA hierbei keine vorgefertigte Funktion vor (Es ist V13).

Das liegt an deiner Steuerung. Peek und Poke gibt es nur auf den 1200 und 1500er Steuerungen.

Also habe ich den Arrayansatz implementiert. Sieht jetzt so aus wie auf dem angehängten Screenshot, das ist halt jetzt immer Implementierungsarbeit, wenn da was geändert wird, aber war das so euer Vorschlag?

Ja genau, sieht korrekt aus.
Tipp: Wenn die Adressen der Analogsensoren alle lückenlos hintereinander im Prozessabbild stehen, dann kann man auch eine UDT mit einem Word-Array erstellen und in den PLC-Variablen auf diesen Adressbereich mappen. (aber auch das gilt, glaub ich, nur für die neuen Steuerungen)

Und nochmal kurz warum ich so umständlich programmiere, an sich ist mir klar, dass wenn man neue Sensoren anschließt oder auch neue Analogmodule um die SPS zu erweitern muss man zwingend das Programm anpassen. Unsere Betreuer/Aufgabenstellung will aber darauf hinaus nur durch Anpassung modularer Werte, die ich in einem Datenbaustein gespeichert habe (die man evtl. auch von außen ändern könnte), das Verhalten des Programms, Meldungen und Sensoranzahl zu ändern und somit den Aufwand zu minimieren.

Das Anliegen haben viele, ist aber nicht so recht zu implementieren. Eine Siemens-SPS kann im Gegensatz zu einem PC nicht dynamisch Speicher allokieren. Man kann also nicht irgendwo am Panel sagen: "jetzt aus meinem DB mit 10 Array-Elementen 20 Elemente machen". Das heißt bei solcherlei Aufgabenstellungen kann man höchstens den Maximal-Ausbau vorbereiten (also direkt 20 Array-Elemente vorsehen) und dann bspw. über Parameter oder HMI weitere Aufrufe freigeben.

Aber diese grundlegende Überlegungen zum dynamischen Erweitern stellt wohl jeder früher oder später mal an. Ging mir zur Anfangszeit nicht anders