Daniel Brenndörfer
Level-1
- Beiträge
- 9
- Reaktionspunkte
- 0
Danke, Leute, das ist genau das, was ich gesucht habe! Ohne Euch hätte ich das in tausend kalten Wintern nicht gefunden, weil ich nicht wusste, dass es sowas gibt und die Google-Suche nach "Array" niemals bei "POUs für implizite Prüfungen" rauskommen würde.Bei TwinCAT gibt es POUs für implizite Prüfungen.
Beckhoff Information System - German
Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbusinfosys.beckhoff.com
Dem Manne kann geholfen werden. Deklariere einfach eine Variable (Achtung keine Konstante), in dem Fall auch gerne Global, setze den Init-Wert auf 0 und beschreibe Sie nie, nimm diese Variable als Divisor, fertig.Allerdings lässt Twincat mich keinen Code mit so offensichtlicher Division durch 0 kompilierenDa muss ich mir noch was überlegen...
Das ist zu allgemein, die POUs zur impliziten Prüfung sind ja nicht nur zur Nutzung während der Entwicklung gedacht. Man muss halt prüfen, in wie weit einem die Auslastung zu hoch geht.Hinweis zum Checkbounds. Er geht etwas auf die CPU Last. Wenn der Code fertig ist. Sollte CheckBounds wieder entfernt werden
Das ist zu allgemein, die POUs zur impliziten Prüfung sind ja nicht nur zur Nutzung während der Entwicklung gedacht. Man muss halt prüfen, in wie weit einem die Auslastung zu hoch geht.
Die Anweisungen TRY, THROW und CATCH in C++ werden nach der Entwicklung ja auch nicht rausgeworfen.
Die Anweisungen TRY, THROW und CATCH in C++ werden nach der Entwicklung ja auch nicht rausgeworfen.
Stimmt, hatte ich irgendwann auch mal von gelesen, aber wieder vergessen. Allerdings gibt es dabei die Einschränkung, dass es derzeit "nur" bei 32 Bit Zielsystemen läuft.Man kann diese Anweisungen auch im TwinCAT Umfeld verwenden
Beckhoff Information System - German
Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbusinfosys.beckhoff.com
Diese würden dann nicht so auf die Last gehen. Zumindest meines Wissens.
Da sie nicht implizit sind, sondern - das nenn ich jetzt mal so - explizit!
FUNCTION CheckBounds : DINT
VAR_INPUT
index, lower, upper: DINT;
END_VAR
// Implicitly generated code : Only an Implementation suggestion
{noflow}
IF index < lower THEN
CheckBounds := 1/nDivisionByZero;
ELSIF index > upper THEN
CheckBounds := 1/nDivisionByZero;
ELSE
CheckBounds := index;
END_IF
{flow}
Super Info. Danke. Leider ist heutige Software nicht mehr ganz so einfach wie eine Dampfmaschine.Bei den impliziten Funktionen ist der Kostenanteil die Anzahl der Instruktionen. Eigentlich nicht viel. Wenn du aber Datacrunching machst und viele Indexe eines Arrays durchläufst summiert es sich.
Worst Case scenario das ich mal gesehen habe: Kostenanteil ca 20% der Gesamtlast. In 08/15 Applikationen fällt es gar nicht auf.
Achja - ich glaube man kann auch exlizit für Codeanteile die impliziten Checks deaktivieren (per Attribut soweit ich mich erinnere).
Bei deinen Methoden/Funktionen ist der Löwenanteil der Kosten das Allokieren der Variabeln auf dem Stack bei jedem Aufruf.
Das kann man bei häufig aufgerufenen Code dann anders gestalten.
Es ist halt manchmal hilfreich wenn man weiss wie die Dampfmaschine denn funktioniert um das eine oder andere "upsala" zu umgehen
Okay, das ist gut zu wissen. Ich refactore gerade ohnehin, um die Anzahl der Aufrufe zu minimieren.Bei den impliziten Funktionen ist der Kostenanteil die Anzahl der Instruktionen. Eigentlich nicht viel. Wenn du aber Datacrunching machst und viele Indexe eines Arrays durchläufst summiert es sich.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?