TIA 1500er CPUs Geschwindigkeit bei "classic"-Programmierung

H

heisch

Level-2
Beiträge
94
Reaktionspunkte
36
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Kollegen,

ich bin gerade dabei bei einem Kunden einen Standard von Classic nach TIA zu überarbeiten.

Als alter Inbetriebnehmer, der entsprechend oft in Fremdprogrammen Fehler suchen musste bin ich
ein Intimfeind des KY-Parameters, bzw. der Übergabe der Nummer von "irgendwas" statt des "Irgendwas" direkt.

Innerhalb der Bausteine ist Einiges los, um möglichst viel mit XREF machen zu können, habe ich an vielen Stellen
Pointer übergeben, die ich dann intern wieder auseinandergenommen habe.
( u.a. SFC 14, SFC15 <- Nummer der I/O-Adresse, findet keine S*, PEW 1024 umgenudelt nach 1024 findet die Xref )

Ich habe absolut keine Lust auf "optimiert", habe aber Bedenken, dass dann alles zu langsam wird.
( Es geht u.a. um eine neue Anlage, in der bestehenden fast identischen läuft eine CPU317-PN/DP mit 16 ms, die dirigiert
eine MoviPLC. Ich mache sogar einmal einen Rücksprung, 16 ms später wären zu spät.)

2 Sachen sind mir bekannt:
- Programm mit AWL, viel Pointer-Adressierung: S5-CPU945, 7 ms umgesetzt nach Step7 : in VIPA317 ca. 1,5 ms
weiter umgesetzt nach CPU1513 : 4 ms.

- Meine Spiel-CPU1511F
Parameter im Baustein nicht benutzt, nur für XREF ranparametriert:
Zeitunterschied Byte-Parameter zu Pointer: Byte parameter ist ca. 2,5 ns schneller.


Da ich trotz TIA weiterhin versuchen werde, so zu programmieren, dass auch meine Nachfolger oder ein Kollege
im Wartungsfall eine Chance hat, die Frage:

Hat schon mal jemand das gleiche, aus "Classic" übersetzte Programm in verschiedenenen 1500erCPUs laufen lassen
und dabei die Zeit gemessen ?

Ist der Zeitverlust durch "cassic" ungefähr proportional den angegebenenen CPU-Geschwindigkeiten ?

z.B: CPU1511F : 60 ns Binärbefehl CPU1515F 30 ns Binärbefehl.
Das wäre ca. Faktor 2 schneller.
Gilt das ungefähr auch bei "classic"-spezifischem ?

Gruss Werner
 
Zuletzt bearbeitet:
Ein komplexes Programm 1zu1 umzusetzen ist bzgl. der Geschwindigkeit nicht so einfach. Die x ns Angabe bezieht sich auf die exklusive Verwendung von Optmierten DBs.
Unser erster Versuch der Voll-Migration, von einer 319 (7ms) hinüber zu einer 1516 (21 ms), unter der Vorraussetzung so wenig wie möglich anzupassen, hat uns nicht überzeugt.
Die selben Funktionen (und noch einige neue), mit unterschiedlichen Anlagenlayouts laufen nun aber bereits auf 9 (bald 14) 1517-3 bei 1,5 bis 3,5 ms Zyklen.
Der Softwarestandard wurde allerdings komplett im Sinne der Moeglichkeiten der 1500er Steuerungen überholt.
Keine Pointer mehr (abgesehen vom variant), keine nicht optimieren DBs (außnahme für fremdvisus), nur 2 fbs ohne optimierter Einstellung (remanenz setzen im db, wegen AT-sicht) und schlussendlich auch kaum noch Bit-meldungen.

Mein persönliches Fazit:
Migrationen bestehender Anlagen von 300/400 zu 1500 machen nur bedingt Sinn.
Neuanlagen mit 1500er Steuerungen können wesentlich performanter sein, wenn man mit alten Strukturen und Standards bricht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Optimiert oder nicht optimiert ist nicht mal die so sehr Frage.
Wenn du dich mit den neuen Möglichkeiten der 1500er beschäftigst (Slice, Array-Zugriffe in allen Sprachen, SCL-Netzwerke, AT, ...) brauchst du deutlich weniger Zeiger.
Die Programme werden besser lesbar und wartbar und meist auch schneller.
Manchmal muss man eben die alten Zöpfe abschneiden!
Neben der Geschwindigkeit darfst du den Speicher bei der 1500 nicht ausser acht lassen.
Ein Projekt kann da schon mal 25% mehr Speicher brauchen.

Gruß
Blockmove
 
Zurück
Oben