TIA Was ist perfomanteste Art zu programmieren ?

TP-Inc

Level-3
Beiträge
1.102
Reaktionspunkte
247
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen. Mich würde mal interessieren was die performanteste, also für die CPU am schnellsten arbeitende, Art zu programmieren ist. Ich werde meinen Stil nicht ändern, es ist nur eine Interessensfrage. Angenommen ich möchte 100 Byte aus DB1 in DB2 kopieren - wie geht das am schnellsten. Sagen wir die Bytes sind einzeln deklariert und können symbolisch angesprochen werden. Würde es einen Unterschied machen ob sie als Array deklariert sind ?
Die Frage gilt für 300er, 1500er optimiert umd nicht optimiert.
 
also bei der 300er kann ich definitiv sagen das die sfc20 bedeutend schneller ist als wenn man die bytes einzeln in einer schleife kopiert.
 
Ich werde meinen Stil nicht ändern

Die übliche Einstellung bei 99% der Programmierer. Nein, die werden weiterhin ihre Excell-Tabellen zum Erstellen von Schrittketten und Steinzeit-FCs verwenden, auch wenn die Welt untergeht und in China zur selben Zeit Anlagen mit Quantencomputern gesteuert werden.
 
Die übliche Einstellung bei 99% der Programmierer. Nein, die werden weiterhin ihre Excell-Tabellen zum Erstellen von Schrittketten und Steinzeit-FCs verwenden, auch wenn die Welt untergeht und in China zur selben Zeit Anlagen mit Quantencomputern gesteuert werden.

Die Einstellung nevt mich auch.
Da werden 1500 CPUs verbaut und dann in AWL mühselig Pointer zusammen gefrickelt.
Bei vernünftiger Strukturierung der Daten wäre es in SCL eine einzelne Anweisung ( If #Transport_FP then #Station5.Daten := #Station4.Daten)
Wer will kann's sogar in KOP oder FUP lösen.
Aber Hauptsache den S5-Stil beibehalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die zwei nutzlosen Antworten. Ich dachte eigentlich das Absolutzugriffe schneller sind als symbolische Zugriffe deswegen die Aussage mit dem Stil. Ich programmiere aber rein symbolisch und möchte diesen Stil nicht ändern. Die Operationsliste werde ich mir mal ansehen. Dankeschön dafür.

Edit: Ausserdem finde ich es nicht in Ordnung über die Arbeit anderer zu stänkern, obwohl man deren Arbeit noch nie gesehen hat. Ebenso ist es nicht in Orndung über Techniken zu maulen die laut eigenen ermessen Steinzeit sind. Ich hab schon einige Maschinen gesehen die sehr sauber programmiert waren und trotzdem nicht richtig funktionieren.
 
Zuletzt bearbeitet:
Hallo Tp inc

für Tia gilt:

kein Awl
immer Symbolisch
am besten alles Optimiert ( wenn nicht möglich so wenig wie möglich misch masch)
Bei schleifen ( besonders im Scl wird ja for to gerne verwendet) überlegen ob es die wirklich braucht und eine Auswertung über mehrere Zyklen ( also die Laufzähler meist i als statische Variable deklarieren) nicht geht.
Immer überlegen ob eine Strings nötig sind bzw ob sie im Prog verarbeitet werden müssen —> oft möglich sie zu einen übt zu wandeln und dann zu verarbeiten.
Eno beim Bausteinaufruf deaktivieren.
Größere Mengen als Daten beim Basteinaufruf als PLC Datentyp am In Out Übergeben ( spart Speicherplatz)

Zu deiner Frage bei Tia die beiden Bereiche in einem PLC Datentyp Definieren und dann mit einer Move Box oder Zuweisung im Scl Kopieren das sollte schnell gehen.

bei S7 Classic

eigentlich genauso wie im Tia nur das der PLC Datentyp hier Udt heist und du im Fup kop Awl den Sfc 20 Blockmove aufrufen musst. Im Scl macht das der. Compiler selbst.

mfg Tia
 
Edit: Ausserdem finde ich es nicht in Ordnung über die Arbeit anderer zu stänkern, obwohl man deren Arbeit noch nie gesehen hat. Ebenso ist es nicht in Orndung über Techniken zu maulen die laut eigenen ermessen Steinzeit sind. Ich hab schon einige Maschinen gesehen die sehr sauber programmiert waren und trotzdem nicht richtig funktionieren.

Das Gemaule bezog sich auf diese Aussage:
Ich werde meinen Stil nicht ändern

Wenn man als Programmierer solche Aussagen trifft, dann ist das - für mich persönlich zumindest - eine Dinosaurier-Haltung.
Das hat nichts im Arbeitsweise , Sauber oder Unsauber zu tun, sondern ist einfach eine Einstellung.
Gerade wenn du Wert auf saubere Programmierung legst, bietet dir die neuen Funktionen sehr viel.
Bei einer 1500er habe ich noch nie AWL oder einen Anypointer benötigt.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Gemaule bezog sich auf diese Aussage:


Wenn man als Programmierer solche Aussagen trifft, dann ist das - für mich persönlich zumindest - eine Dinosaurier-Haltung.
Das hat nichts im Arbeitsweise , Sauber oder Unsauber zu tun, sondern ist einfach eine Einstellung.
Gerade wenn du Wert auf saubere Programmierung legst, bietet dir die neuen Funktionen sehr viel.
Bei einer 1500er habe ich noch nie AWL oder einen Anypointer benötigt.

Gruß
Blockmove

Vlt. Habe ich das falsch formuliert. Gemeint war eigentlich das ich kein konkretes Problem habe, und auch keine Grundsatzdiskussionen anzetteln möchte.

Ich will einfach nur wissen was am schnellsten in der CPU verarbeitet wird.
 
Die Zeiten wo man über Befehlskaufzeiten nachdenken musste
sind doch eigentlich vorbei, zu S5 Zeiten war das mal intressant

Na da bin ich anderer Meinung. Auch heute noch. Habe da aktuell eine Anlage bei der die Taktzeit um mehr als 5s verbessert werden konnte und das nur durch Tausch der CPU, also durch Verringerung der SPS-Zykluszeit!!!

Aber zurück auf Anfang: Nach meinem Dafürhalten...
- Performance ja, aber nicht auf Kosten der Verständlichkeit/Lesbarkeit des Programms.
- möglicht indirekte Zugriffe vermeinden, lieber ausschreiben als in Schleife programmieren. (Ja, irgendwann machts keinen Sinn mehr)
- Besser multiplizieren als dividieren ( x.x * 0.5 ist schneller als x.x / 2)
- nur notwendige Programmteile im Zyklus bearbeiten. (In BTA Automatik nicht die BTA Einrichten-Funktionen aufrufen....)
- Prüfen ob Programmteile wirklich jeden Zyklus bearbeitet werden müssen. (BTA-Generierung,Anlagenstatus...)
- ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... und auch keine Grundsatzdiskussionen anzetteln möchte.

Hast du aber mit diesem Thema, wie du selbst siehst, schon geschafft.

Also auch meine Meinung dazu :
Ich würde IMMER Code-Lesbarkeit vor Code-Effiziens setzen. So etwas zahlt sich sogar für einen selbst nach einiger Zeit aus.
Bedingte Abarbeitung von Programmteilen zugunsten einer Zykluszeit-Verbesserung würde ich IMMER vermeiden - wird die Zykluszeit des SPS-Programms zu groß dann zuzsehen, dass man die richtige CPU an den Start bringt.

Gruß
Larry
 
Na da bin ich anderer Meinung. Auch heute noch. Habe da aktuell eine Anlage bei der die Taktzeit um mehr als 5s verbessert werden konnte und das nur durch Tausch der CPU, also durch Verringerung der SPS-Zykluszeit!!!

Aber heutzutage kann man die Taktzeit vermutlich günstiger mit einer leistungsfähigeren CPU erhöhen und trotzdem ein leserliches Programm abliefern.
Ist ja heute nicht mehr so, das man für den preis einer leistungsfähigen CPU auch einen Kleinwagen kaufen könnte.
 
Bedingte Abarbeitung von Programmteilen zugunsten einer Zykluszeit-Verbesserung würde ich IMMER vermeiden

Das wird wahrscheinlich die nächste Grundsatzdiskussion :ROFLMAO:
Ich stimme dir aber in diesem Punkt zu.
Gerade das sehr beliebte bedingte Bearbeiten Hand / Automatik macht nur selten Sinn.
Durch die Umschaltung können sehr viele Seiteneffekte entstehen.
Bei komplexeren Anlagen ist dann nicht viel gespart.
 
Also gerade unter TIA würde ich (noch) Schleifen jeglicher Art vermeiden, da selbst die 1500er Reihe bis zur 1517 sehr anfällig darauf reagiert und deine Zykluszeit am Ende irgendwo zwischen 50-70ms liegt (genauso sehr schwankend).. selbst mit Firmware V2.6 haben wir noch etliche Probleme in verschiedenen Projekten.. und in dem aktuellen sind nicht mal Technologieobjekte vorhanden.. diese treiben die Zykluszeit auch noch mal hoch.

AWL würde ich in TIA einfach wirklich sein lassen und dafür lieber alles was möglich ist in SCL programmieren.. da dir SCL mehr Möglichkeiten auf einfacherer Basis bietet (z.B. Konvertierung). Desweiteren "verbieten" auch die meisten Endkunden AWL unter TIA. Mit V15.1 hat SCL zusätzlich noch mal mehr Verbesserungen bekommen.. also man merkt wohin die Richtung geht. :)

Lesbarkeit geht trotzdem vor Performance, da es noch viel zu viel Einflüsse von verschiedenen Programm-Situationen auf die Zykluszeit gibt.
 
Bedingte Abarbeitung von Programmteilen zugunsten einer Zykluszeit-Verbesserung würde ich IMMER vermeiden
Sehe ich mal ganz anders.
Ein Beispiel:
Das Laden einer "Rezeptur" vom HMI. Dieses schreibt Werte in einen DB (und zwar einmalig).
Ich würde nun niemals jeden Zyklus diese Werte nehmen und ggf. umgerechnet an die einzelnen Achsen; Messgeräte usw. weiterreichen. Das reicht nun wirklich EINMALIG.

Habe mal gelernt: Eine Information ist nur dann eine Information wenn sie eine neue Erkenntnis mit sich bringt (oder so ähnlich...).
Beispiel: Ein Geber gibt einen Analogwert aus, aus dem in einer aufwendigen Rechnung die Position eines Teiles berechnet wird. Der Analogwert wird nur alle 20ms aktualisiert und die Zykluszeit beträgt < 2ms.
Warum sollte man nun diese Berechnung denn jetzt zyklisch durchführen wenn doch bei Wertänderung reicht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Na da bin ich anderer Meinung. Auch heute noch. Habe da aktuell eine Anlage bei der die Taktzeit um mehr als 5s verbessert werden konnte und das nur durch Tausch der CPU, also durch Verringerung der SPS-Zykluszeit!!!
Interessant. Eine Verbesserung um 5 Sekunden finde ich Ekstrem.

Wenn eine Maschinen Taktzeit durch CPU Rechenzeit verringert werden soll, handelt es sich vermutlich um die Wartezeiten die durch den Bearbeitung in den CPU 'unnötig' verlängert werden. Also, wenn ein Geber sein Zustand ändert, bis ein Aktuator-Zustand durch den CPU geändert wird.
Wenn es eine Sequenz gibt der viele Schritten hat, dann werden pro Sequenz-Durchlauf den Sequenz verlängert mit ungefähr das hälfte von den CPU-Zykluszeit multipliziert mit den Anzahl von Schritten in einen Sequenzdurchlauf.

Wenn den CPU Zukluszeit z.B. von 20 ms auf 5 ms verringert wurde und dadurch eine Besserung von 15 ms, dann um ein Maschinentaktzeit Minderung von 5s zu erzeugen muss es ungf. 667 Schritten in den Sequenz sein.
5000 ms / (15 ms * 0.5) ~ 667
Dass sind ziemlich viele Schritten.

Den relative Besserung muss auch in Verhältniss zu den Gesammte Zykluszeit gesehen werden. 5 Sekunden ist wirklich merkbar, wenn den Maschinenzyklus von 20 Sekunden auf 15 Sekunden verbessert werden kann, aber nicht so merkbar wenn von 3600 auf 3595 Sekunden.

Wenn es handelt um eine Maschine mit Kurze zykluszeiten, und viele Schritten in sein Sequenz, dann wurde ich überlegen Hardware-Interrupts zu verwenden.
Oder, wenn es geht den Sequenz in eine Zyklische Interrupt aktualisieren. In den Fall muss den Sequenz nicht abhängig sein von z.B. Berechnungen die nicht durch den Interrupt aktualisiert werden.
 
Moin,
Sehe ich mal ganz anders.
Das ist dein gutes Recht.
Ich glaube man sollte sich mal grundsätzlich von der Idee trennen, dass die eigene Vorgehensweise immer die einzig wahre ist. Dein Vorgehen mag für deine Applikationen genau richtig sein. Für andere Anwendungen mag sie halt nicht so gut passen.
Ich mag diese bedingten Anweisungen auch nicht so gern, da ich ganz gerne eine möglichst konstante Zykluszeit habe. Ob die nun 10 oder 20 ms ist, ist mir eigentlich erstmal egal - sie sollte halt nur nicht jeden Zyklus unkontrolliert schwanken. Wenn nun große Programmteile je nach Bedingung ausgehangen werden, hab ich im Worst Case einen ganz langen und sonst ganz kurze Zyklen. Das passt dann einfach für einige Anwendungen nicht.
 
Warum sollte man nun diese Berechnung denn jetzt zyklisch durchführen wenn doch bei Wertänderung reicht?
Damit bei einer vom Programmierer unvorhergesehenen gleichzeitigen Änderung der Werte von mehreren Sensoren nicht plötzlich die Zykluszeit überschritten wird und die CPU in STOP geht. Wenn man die Berechnungen immer zyklisch ausführt, dann sieht man schon vor dem Malheur daß man eigentlich eine schnellere CPU oder eine Designänderung braucht.

Harald
 
Zurück
Oben