cycle-time

[gravieren]

Hi

Bei der Funktion cycle-time  wird bei RST die Variable ct_min
auf  (   ct_min := t#0s - t#1ms;  )  gesetzt.

Das dürfte etwa  -1ms  sein.


Ich habe etliche Optimierungen meines Pogrammes gemacht,
die min-Zyklus-Zeit wurde nie kleiner.   ;)

Sollte die Vorbesetzung mit z.b. 2000 ms erfolgen  ?


Die Zykluszeit beim nächsten Durchlauf wird bestimmt kleiner.

[hugo]

eine time variable kennt keinen negativen wert der wertebereich liegt bei 0 ... nnnn wenn man also von 0 1 abzieht erzeugt man dadurch den größten möglichen wert im wertebereich einer time variablen

[gravieren]

Hi Hugo

Bei der OSCAT-S7 kommt jedoch "-1ms" heraus.

Code Auswählen Erweitern

(* @PATH := '\/engineering\/measurements' *)
(* @SYMFILEFLAGS := '2048' *)
FUNCTION_BLOCK cycle_time
TITLE = 'cycle_time'
//
// this function block measures the cycle time and displays the last, min and max cycle time of the current task.
// the resolution is 1ms.
// the cycles output is a dword counter which counts the cycles.
// a rst pulse on the input will reset all data.
//
VERSION : '1.1'
AUTHOR  : hugo
NAME    : CYCLE
FAMILY  : MEASURE

VAR_INPUT
    rst : BOOL;
END_VAR
VAR_OUTPUT
    ct_min : TIME := t#0s;
    ct_max : TIME := t#0s;
    ct_last : TIME;
    systime : TIME;
    sysdays : INT;
    cycles : DWORD;
    tcycles AT cycles : DINT;
END_VAR
VAR
    last_cycle : TIME;
    tx: TIME;
    init: BOOL;
END_VAR



(*
    version 1.1 12 dec 2006
    programmer  hugo
    tested BY       hans
*)

tx :=TIME_TCK() - last_cycle;
IF rst THEN
    ct_min := t#0s - t#1ms;
    ct_max := t#0ms;
    cycles := 0;
ELSIF last_cycle > t#0s THEN
    IF tx < ct_min THEN ct_min := tx;
    ELSIF tx > ct_max THEN ct_max := tx;
    END_IF;
    ct_last := tx;
ELSIF ct_min = t#0s THEN
    ct_min := t#0s - t#1ms;
END_IF;
IF init THEN
    systime := systime + tx;
        IF systime >= t#1d THEN
            systime := systime - t#1d;
            sysdays := sysdays + 1;
        END_IF;
END_IF;
init := TRUE;
last_cycle := last_cycle + tx;
tcycles := tcycles + 1;

(* hm 12.12.2006        rev 1.1

added cycles output, a dword cycle counter.

*)
END_FUNCTION_BLOCK


Oder hat sich da ein Tippfehler eingeschlichen  ?

[hugo]

kannst du mal auf der s7 von einer time variable

tn := 0ms
ty := tn - t#1s

was ergibt dann ty?

welchen wertebereich hat time bei siemens? kann time dort negativ sein?

[dalbi]

Hallo,

der Time Wertebereich bei der S7 geht von -T#24D_20H_31M_23S_647MS bis
T#24D_20H_31M_23S_647MS.


mfg
Daniel

[hugo]

dann ist mir alles klar,
ich werde die lib durchforsten und sicherstellen das alle funktionen die time benutzen auch auf siemens lauffähig sind.
an welchen stellen ist siemens eigentlich sonst noch nicht norm konform?

[hugo]

wir werden in der 1.6 eine andere technik anwenden damit wir auch s7 kompatibel sind

[hugo]

nun wenn dem wirklich so ist das siemens hier nicht der iec61131 folgt dann werden eineige unserer time und date funktionen nicht auf siemens funktionieren.
ich frage mich ob es dann überhaupt sinn macht siemens zu supporten?

[gravieren]

Hi Hugo

nun wenn dem wirklich so ist das siemens hier nicht der iec61131 folgt dann werden eineige unserer time und date funktionen nicht auf siemens funktionieren.

Durchaus möglich, beim testen werden wir es festellen.

ich frage mich ob es dann überhaupt sinn macht siemens zu supporten?

Wenn einige Bereiche NICHT funktinieren sollten, werden diese angepasst.(Siemens-Kompatibel)

Ich denke, mann sollte auf Siemens NICHT verzichten.

Hintergründe:
Enorm hohe Verbreitung von Siemens-Steuerungen.
Fehlende Quellcode-Verfügbarkeit von etlichen "Packeten"
Mischbetrieb von Siemens und CoDeSys möglich.
(Für Industrie-Maschinen verwenden wir Siemens, für den GLT-Bereich CoDeSys.)
(Aufgrund von OSCAT und OSCAT-S7 wachsen diese Systeme zusammen)
(Der Bekanntheitsgrad deiner Bibliothek KANN nur steigen.)


P.S.  Linus Thorwald (Linux)  lässt sich durch so kleine Probleme NICHT erschrecken.
Du und Daniel werden hierfür SICHERLICH Lössungen finden.
Ich werde weiterhin die OSCAT-S7 testen.
Nach Beendigung der Tests kann ich auf deine Anfrage nach WebVisu nachkommen.


Karl

[gravieren]

Anmerkung.


CoDeSys ist auch nicht Problemlos   ;)

http://forum.3s-software.com/viewtopic.php?t=550

[hugo]

die probleme und sie zu lösen stört mich nicht aber linus torwald hat sein linux ja auch nicht m kompatibel gemacht.
mich stört es einfach das sich firmen vom standard abkapseln um die anwender an sich zu binden.
aber du hast schoin recht oscat wird auch simenens kompatibel werden.
sollten wir es nicht schaffen funktionen so kompatibel zu programmieren das sie universiell auf codesys und siemens laufen müssen wir sehen wie wir das lösen (eventuell 2 bibliotheken.

wichtiger erscheint mir aber jetzt das alle funktionen unter siemens auf herz und nieren getestet werden.
bitte alle fehlermeldungern zu mir dann kann ich nach lösungen suchen.

die cycle_time have ich schon angepasst

[hugo]

ja das ist klar codesys ist an einigen stellen sogar enttäuschend, aber nichts desto trotz stellt codesys die unabhängigste entwicklungsplattform dar die meiner meinung nach am besten die norm iec61131 abbildet. codesys ist schon alleine deshalb unabhängig weil 3s keine hardware herstellt oder vertreibt.

[hugo]

hi karl danke für deine tests an der s7 übersetzung.
dank deiner inputs hat sich unsere lib schon deutlich verbessert.
für die nächsaten releases haben wir nur wenige neue funktionen vor, vielmehr sollen die vorhandenen funktionen auf kompatibilität verbessert werden und die lib 100% siemens kompatibel gemacht werden.
für jeden input zu s7 sind wir dankbar weil wir selbst keine testumgebung zu s7 haben