TIA Performanceunterscheid zwischen Real und USInt

R

RucksackSepp

Level-2
Beiträge
24
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen.

beim schreiben eines Instanz-FBs für eine Umrichter-Ansteuerung bin ich eher auf ein Luxus-Problem gestoßen.
In den Baustein (wird als Instanz öfters aufgerufen) gehen 4x Geschwindigkeitsvorwahlen (0..100%) rein, für verschiedene Betriebsarten. Diese sind im Moment als USINT deklariert. Der Gedanke war, da im Programm bei der Umrechnung zu einem Analogwert die Variablen konvertiert werden müssen, ob es einen überhaupt auffälligen Performance-Unterschied macht, wenn diese Sollwerte als REAL zugeführt werden. Zum einen könnte man bei bedarf die Drehzahl auf 0,1/0,01...% genau vorgeben, zum andern ist der SCL-Code etwas übersichtlicher, da nur noch Berechnungen und keine Konvertierung mehr dabei stehen.

Was meint ihr dazu? Wenn nichts groß dagegen spricht, werde ich das ganze zu REAL ändern.

TIA V18 Upd. 3
CPU 1511-1PN (..AL03..)
 
Leider ist die S5-Zeit nahezu vorbei, aber die Anleitungen dafür waren (meiner Meinung nach) besser. So gab es z.B. je CPU eine Operatorenliste, in der (im Hemdentaschenformat) alle Befehle kurz mit Funktion und Zeitbedarf beschrieben wurde.
Das übriggebliebene Relikt bei S7 ist das (ohne Zeitbedarf):

SIOS

support.industry.siemens.com support.industry.siemens.com

Du hast schon recht, wenn du die Unterschiede als Luxusbedarf bezeichnest, für einige Umrechnungen werden der zusätzliche Speicherplatz und die zusätzliche Prozesszeit vernachlässig sein. Aber je nach Leistungsfähigkeit deiner Steuerung und Anzahl der Berechnungen kann das immer noch Auswirkungen haben.
Speicherbedarf kannst du ansehen bei den Bausteineigenschaften (Übersetzung).
Den Zeitbedarf wird du die ausrechnen müssen, z.B. deine unterschiedlichen Programmabläufe (USINT vs. REAL) jeweils 1000 oder 10000 mal (in Schleife) aufrufen und mit dem RUNTIME Baustein feststellen.
 
Zuletzt bearbeitet:
DeltaMikeAir schrieb:
In den technischen Daten der CPU ist doch alles definiert:
Anhang anzeigen 77363
Zum Vergrößern anklicken....
Ja, da hast du recht, aber das Wort typ. heißt für mich durchschnittlich. Als Beispiel hier mal die Zeiten der S5 CPU 928, dort benötigt die Punktrechnung z.T. wesentlich mehr Zeit als die Strichrechnung.
Die heutigen CPU's sind bestimmt wesentlich schneller, aber das Verhältnis von Punkt zu Strichrechnung bzw. von mal zu geteilt müsste ungefähr bleiben.
1713424875565.png1713424910351.png
 
Ich habe solche Bausteine immer so geschrieben, dass ich sie mit dem Wert versorgen konnte, der meinem Zielgedanken entspricht. Bei einem Umrichter war das selten Prozent sondern meißt Fördergeschwindigkeit oder Drehzahl. Das heißt, dass der Baustein dann dies als Sollwert-Eingang hatte (also REAL in z.B. m/Min.) und zusätzlich einen Anpassungsfaktor (auch REAL), der dem Baustein intern dann ermöglicht es für den Regler passend umzurechnen.
Natürlich braucht das mehr Zeit, vor Allem wenn der Baustein dutzende Male aufgerufen wird - war mit aber egal - Komfort first !!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ursprünglich war es so geplant, aber da das meiste Pumpen, Schnecken und Rührwerke sind. Einigten sich die Herren von Oben auf eine überall gleichgültige % Vorwahl. Um damit z.B. 70% der Pumpen Leistung vorzugeben. Somit ist angeblich auch die Beobachtung in der Visu einfacher. Pumpe hat volle Drehzahl, Rührer gerade nur 60%.
Bin bei der Anwendung muss ich leider als Füger mitspielen.
 
Larry Laffer schrieb:
Natürlich braucht das mehr Zeit, vor Allem wenn der Baustein dutzende Male aufgerufen wird - war mit aber egal - Komfort first !!!
Zum Vergrößern anklicken....
Der Gedanke heute ist halt. Es soll möglichst lesbar und auch für andere verständlich sein. Lieber kauft man sich ne grössere Steuerung, das ist billiger als die Zeitkosten die aus Performancegründen effizient undurchsichtig aufgebautes Programm aufwirft.
 
Und am Ende entscheidet der Kunde, ob er das Programm so abnimmt oder nicht.
Hier mal wieder mein schönes Uraltbeispiel einer Hallenlicht-Steuerung, die ein Informatiker unheimlich durchdacht mit AWL gelöst hat. Schiebe links, schiebe rechts, Bitmaske usw.

Musste ein Kollege am Ende komplett auf FUP umschreiben, weil der Kunde gesagt hat "Das versteht kein Mensch, ist daher unmöglich zu warten, nehmen wir nicht ab."
 
schwimmer schrieb:
Nur dann hat der Kunde eigentlich auch eine Handhabe die Abnahme zu verweigern. Wenn es keine Vorgaben gibt und das Programm vernünftig dokumentiert ist, kann er nichts dagegen sagen, selbst wenn seine Instandhalter es nicht verstehen
Zum Vergrößern anklicken....
Solche Programme hatte ich schon in der Hand.. gab da mal einen Externen mit dem wir viele Projekte gemacht hatten.. das waren immer nur so kleine Maschinen. Wenn da mal wieder eine von denen gebaut wurde und jemand von uns hin musste.. war mal froh dass die Kiste nach vier Tagen lief und man das Programm nicht mehr anschauen musste.. nur AWL geschubse.

Auf der anderen Seite hatte er sich damit auch etwas "unabdingbar" gemacht, da in der Anfangszeit von den Projekten der Kunde immer wieder auf ihn zugehen musste.. weil eben AWL Dschungel, war ganz witzig. Wenn man ungefähr verstanden hatte worans liegt, dann hat man sich im Projekt zurechtgefunden.. und dementsprechend auch freitags mit der Vorabnahme durch
 
Zurück
Oben