Vergangene Sekunden ab Zeit X berechnen in SCL

[ssyn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum per 'TIME_TO_LREAL' in LREAL konvertieren? Dann müsstest aber beide zu vergleichenden Werte in LREAL konvertieren --> unnötiger, überflüssiger, irreführender Umweg!

Sorry, ich bin nur ein paar Wochen in SCL und mache natürlich viel dummes.

 

[Frohnius]

hmm also wenn du einen klaren startzeitpunkt hast und die zeit stoppen willst ...
dann nimm doch einfach ein TON (wie hier schon einige geschrieben haben)

egalTON(IN:=start, PT:=t#max ........ usw
und über egalTON.ET erhälst du doch die aktuell abgelaufene zeit

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum soll er einen TON nehmen, wenn er ihn gar nicht braucht. Bei Start- und Endzeitpunkt mit der TIME()-Funktion die aktuelle Zeit lesen und die Differenz bilden ist doch weit effizienter als in jedem Zyklus einen TON aufzurufen, der niemals ablaufen soll.

 

[Frohnius]

hmm da hast du wohl schon recht ....
die abfrage "if ereignis zeit merken" und "if ereignis differenz berechnen" muss ja auch in jedem zyklus laufen ...
spart mal angenommen sogar zykluszeit - aber meinst dass der cpu-load unterschied tatsächlich messbar, oder einer beachtung wert ist ?

ich habe sogar recht aktuell beides ausprobiert und getestet ... um die exakte laufzeit eines schiebers zu messen ....
und zumindest bei einer schneider / codesys M251 lässt sich kein unterschied feststellen bei 2ms Zykluszeit ...

 

[idtell]

Naja da wird der ms-Sekundenwert natürlich nicht mehr viel bringen. Da gibs nur noch den Weg über die us .. aber die Funktion ist nicht immer verfügbar. "verfügbar" Ausdruck unglücklich gewählt, eher so : wenn das System darunter die Zeit einfach nur in ms-Auflösung liefert, dann springt der Wert einfach in eben

 

[Frohnius]

Zuviel Werbung?
-> Hier kostenlos registrieren

jupp .. naja und in meinem fall muss ich die exakte zeit stoppen, wenn der schieber die endlage verlässt ... also sind soweiso trigger abfragen nötig .. was TON mit erledigt ...
ich verwende bei sowas ganz gerne die zuverlässigen standard bausteine, die schon immer funktioniert haben.

aber das ist eben geschmackssache weder die eine, noch die andere möglichkeit halte ich für besser, schlechter oder falsch.

 

[StructuredTrash]

aber meinst dass der cpu-load unterschied tatsächlich messbar, oder einer beachtung wert ist ?

Heutzutage wohl nicht mehr, es sei denn Du hättest sehr, sehr viele solcher Messungen im Programm.
Dass ich solchen Dingen Beachtung schenke, liegt wohl daran, dass ich schon Programmier-Opa bin. Früher musste man um jede Mikrosekunde kämpfen.

 

[Frohnius]

Dass ich solchen Dingen Beachtung schenke, liegt wohl daran, dass ich schon Programmier-Opa bin. Früher musste man um jede Mikrosekunde kämpfen.

was sps angeht bin ich noch nicht sooo lange dabei und deshalb wohl durchaus verwöhnt
aber ich weiß genau was du meinst ... als ich in früher jugend C64 in assembler programmiert habe, war das oft am limit mit 0,9 MHz taktfrequenz und bei jedem rasterzeilen-interupt gings um millisekunden

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

... war das oft am limit mit 0,9 MHz taktfrequenz und bei jedem rasterzeilen-interupt gings um millisekunden

Jetzt mal für einen SPS-Opa, der - warum auch immer - den C64 übersprungen hat: was ist denn ein RasterZeilen-Interrupt? Interrupt ist klar, aber diese ominösen RasterZeilen? Hat das was mit dem Glotzophon als AnzeigeMedium zu tun?

 

[Frohnius]

der video-chip des c64 lieferte bei jedem zeilenwechsel einen interupt den man nutzen konnte um z.b. etwas darzustellen was nicht "flackern" darf oder im rand des bildschirmes die farbe zu wechseln ... und hier blieben auch nur ein paar wenige taktzyklen zeit man konnte z.b. dadurch einen sprite (=bewegliches bitmap mit 16x16 pixel - das limit des chips waren 8 stück ) einfach am bildschirm weiter unten noch einmal verwenden ... und ihn natürlich rechtzeitig oben wieder einblenden bevor das nächste bild aufgebaut wird ....
vergleicht man software von damals - und heute, unter berücksichtigung der enormen leistungsfähigkeit aktueller hardware - ist die software einfach nur dramatisch schlechter geworden.

 

[ssyn]

Ich habe selbst neue Lösung gefunden:

VAR
aaa : BOOL;
ttt2 :RTC;
ttt0: DINT;
END_VAR
...
ttt2(EN:=aaa);
ttt0 := TIME_TO_DINT(ttt2.CDT - ttt2.PDT) / 1000;