Bearbeitungszeit eines FC's oder FB's

phyrexianer

Member
Beiträge
13
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo liebe Forumgemeinde,

es ist sehr wahrscheinlich , dass hier schon etwas zu dem Thema existiert jedoch finde ich es nicht.

Konkret geht es mir darum fest zu zu stellen wie lange die Abarbeitung eines FC oder FB dauert. Kann mir jemand dazu Tips, Funktionen oder Anleitungen geben ???
Es sollte möglich sein beim betreten des Baustein einen Zeitwert oder ähnliches zu speichern und beim verlassen wieder zu speichern um diese dann zu vergleichen.

Ich möchte gerne feststellen um wie viel langsamer mein Programm wird, wenn ich zur Programmierung nicht mehr Merker sonder DB's einsetze um meine Variablen struktuiert ab zu legen. Ich nutze die 3172-PN/DD
dazu habe ich einen Baustein bei dem ich einmal Merker für Zwischenergebnisse usw. Verwende und ein mal die Werte in einen global DB schreibe. Wir verwenden ungefähr 5000 MerkerSYMBOLE daher ist es nicht unrelevant wenn der Aufruf aus dem DB länger dauern würde.

gruß und danke für Eure Hilfe
 

MSB

Well-known member
Beiträge
7.129
Punkte Reaktionen
1.613
Naja, jeder struckturierte DB-Zugriff also z.B. DB1.DBW0 besteht im Endeffekt dann auf 2 Befehlen:
AUF DB1
L DBW0

Das Auf DB benötigt natürlich auch eine gewisse Zeit (siehe Operationsliste zu deiner CPU),
L DBW oder L MW ist dann zeitlich (relativ sicher) wieder gleich, aber das steht ebenfalls in der Op-Liste.

Mfg
Manuel
 

rostiger Nagel

Forums-Knochenbrecher
Teammitglied
Beiträge
15.045
Punkte Reaktionen
4.722
Zuviel Werbung?
->Hier kostenlos registrieren
kannst du nicht einfach die Zykluszeit nutzen um so etwas in erfahrung zu bringen.
Ansonten durch den SFC64 "TIME_TCK" am Anfang und Ende des Bausteins aufrufen
und dann die Differenz berechnen. Dein FC bzw. FB sollte dann aber min. eine Laufzeit
von >1 ms haben um überhaubt etwas erkennen zu können.
 

M-Ott

Well-known member
Beiträge
1.773
Punkte Reaktionen
374
Da die Auflösung der Zeit intern "nur" millisekundengenau ist, müsste Dein Baustein schon recht lang sein, um verlässlich messen zu können. Die aktuelle Systemzeit kannst Du mit dem SFC1 auslesen, aber - wie gesagt - nur millisekundengenau.
 
OP
P

phyrexianer

Member
Beiträge
13
Punkte Reaktionen
0
Ja, das habe ich auch alles Herrausgelesen, jedoch sind wir uns in einem Punkt nicht sicher. DB öffnen kostet 6 us zugriff 3us, das heißt ich würde meine Zugriffzeit verdreifachen.
Jetzt übergebe ich ja meinem FC einen UDT eines DB.
wird denn jetzt der DB wirklich sage ich mal 30 mal geöffnet und dann darauf zugegriffen oder bleibt er geöffnet !? und es finde dann nur Zugriffe statt !?

Zudem geht es darum, meine Idee schon mal vorab testen zu können bzw. die Auswirkungen vorhersagen zu können, bevor ich ein Programm mit 5000 Merkern umschreibe. Deswegen der Wunsch eine Bearbeitungszeit eines FC oder oder FB zu bestimmen
 

rostiger Nagel

Forums-Knochenbrecher
Teammitglied
Beiträge
15.045
Punkte Reaktionen
4.722
andere Frage was hast du den für eine Zykluszeit oder wo willst du hin?

Wenn dein Programm wirklich so groß ist und du Problemme mit der Zykluszeit hast,
kann es Preiswerter sein eine Leistungsfähigere CPU zu nutzen eine 319 würde sich
da anbieten.
 

M-Ott

Well-known member
Beiträge
1.773
Punkte Reaktionen
374
Du könntest den Baustein einfach 100 Mal durchlaufen lassen, dann hättest Du brauchbare Ergebnisse.
 
OP
P

phyrexianer

Member
Beiträge
13
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Es geht um das ändern unserer Programmierphylosophie und da würde ich gerne vorab wissen ob sich das negativ auf die Zykluszeit auswirkt

andere Frage was hast du den für eine Zykluszeit oder wo willst du hin?

Wenn dein Programm wirklich so groß ist und du Problemme mit der Zykluszeit hast,
kann es Preiswerter sein eine Leistungsfähigere CPU zu nutzen eine 319 würde sich
da anbieten.
 

M-Ott

Well-known member
Beiträge
1.773
Punkte Reaktionen
374
Ich kann mich erinnern, dass die Übergabe von STRUCT oder UDT als IN an einen FC einen Sonderfall darstellt, der die Bearbeitungszeit stark erhöht, ich kriege aber nicht mehr genau zusammen wie es war. Vielleicht weiß es ja noch jemand anders.
 

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2021
Beiträge
19.493
Punkte Reaktionen
5.876
Langsame DB-Zugriffe: Es war einmal ...

Man nehme die genaue MLFB-Nummer der CPU (z.B. 6ES7317-2EK14-0AB0), schaue in die zugehörige Operationsliste und stelle fest, daß es bei dieser CPU(-Generation) keinen Unterschied (mehr) macht, auf welche Speicherbereiche (E/A/M/D/L) zugegriffen wird - die Ausführungszeit ist unabhängig vom Operanden immer gleich.
Ein teilqualifizierter DB-Zugriff auf einen erst zur Laufzeit bekannten vorher geöffneten DB dauert nun sogar etwas länger.

9.31.2 Laden der Adressen und Operanden schrieb:
Die CPUs verfügen über eine performante Unterstützung für symbolische
Programmierung. Die hier verwendeten vollqualifizierten DB-Zugriffe (z. B. DB100.DBX 1.2)
verursachen im Regelfall keine zusätzlichen Laufzeiten. Dies gilt auch für den im Zugriff
enthaltenen AUF DB Befehl.

Um ganz sicher zu gehen, kann man natürlich einen unterschiedlich programmierten Baustein 1000 mal aufrufen und die Ausführungszeiten vergleichen.

Harald
 
OP
P

phyrexianer

Member
Beiträge
13
Punkte Reaktionen
0
Man nehme die genaue MLFB-Nummer der CPU (z.B. 6ES7317-2EK14-0AB0), schaue in die zugehörige Operationsliste und stelle fest, daß es bei dieser CPU(-Generation) keinen Unterschied (mehr) macht, auf welche Speicherbereiche (E/A/M/D/L) zugegriffen wird - die Ausführungszeit ist unabhängig vom Operanden immer gleich.
Ein teilqualifizierter DB-Zugriff auf einen erst zur Laufzeit bekannten vorher geöffneten DB dauert nun sogar etwas länger.



Um ganz sicher zu gehen, kann man natürlich einen unterschiedlich programmierten Baustein 1000 mal aufrufen und die Ausführungszeiten vergleichen.

Harald

Super vielen dank.... das habe ich gebraucht... und da ich neben mir eine alte (6ES7317-2EK13-0AB0) und neue Generation habe... kann ich das mal vielleicht verifizieren .. aber gut zu wissen dass es keinen Unterschied macht, bzw. machen sollte *ggg*
 
Oben