# oscat lib 1.5



## hugo (7 März 2007)

ab sofort steht die oscat lib in der version 1.5 zum download bereit
unter www.oscat.de.
neben zahlreichen verbesserungen und erweiterungen sind vor allem anpassungen zur besseren portierbarkeit und kompatibilität gemacht worden


----------



## hugo (10 März 2007)

die oscat lib 1.5 steht seit heute auch für s7 zum download bereit


----------



## Unregistrierter gast (11 März 2007)

hugo schrieb:


> die oscat lib 1.5 steht seit heute auch für s7 zum download bereit



Die meisten Bausteine sind nicht getestet, laut der Excel - Tabelle.

Heist dass, die sind nur unter S7 nicht getestet, oder sind hinsichtlich 
ihrer Funktion nicht getestet ?


----------



## hugo (11 März 2007)

alle bausteine sind ausnahmslos auf mehreren targets getestet
die beschreibung der testumgebungen findest du im handbuch.

in jedem release sind eine vielzahl von verbesserungen hinsichtlich funktionalität und kompatibilität.

ungetestet bedeutet im falle s7 das die funktion zwar auf s7 übersetzt aber nicht auf einem s7 target getestet wurde.

die oscat lib ist seit einen halben jahr an vielen unabhängigen stellen und anwendungen im produktiveinsatz und eine vielzahl von funktionen hat bereits mehrere revisions durchlaufen, nicht nur wegen funktioneller verbesserungen, sondern vor allem auch um die kompatibilität zu möglichst vielen systemen zu verbessern und performance zu verbessern.


----------



## Unregistrierter gast (11 März 2007)

hugo schrieb:


> die oscat lib ist seit einen halben jahr an vielen unabhängigen stellen und anwendungen im produktiveinsatz



Gibts da ne Refertenzliste ?

Ich finde die LIB nicht schlecht, aber ein paar Dinge sind IMHO zu trivial und einfacher mit S7 - Standardfunktionen zu lösen.

Aber i.g.u.g. Respekt für die viele Arbeit, die du da reinsteckst.

Ist das ein Hobby, oder verdienst du auch Geld damit ?


----------



## hugo (11 März 2007)

sicherlich lassen sich im umfeld von s7 oder codesys ein großteil der dinge die die oscat lib bereitstellt mit standard funktionen realisieren.
wir haben dies früher auch so gemacht.
aber wenn man dann ein mehrere jahre altes projekt auf eine andere hardware umziehen soll beginnt man wieder von vorne.
wir schreiben die oscat lib um der automationsindustrie endlich eine unabhängige bibliothek zu geben und die anwendungen hardware unabhängig zu machen so wie es der iec61131 standard eigentlich vorsieht.
wir verdienen unser geld mit enwendungen, und sehen die lib als unsere basis professionelle anwendungen hardawareunabhängig zu erzeugen.


----------



## Onkel Dagobert (11 März 2007)

Hallo Hugo,

ihr seht euch also dazu berufen, so zu sagen :-D . Na dann passt mal gut auf dass ihr euer Geld mit professionellen Anwendungen auch morgen noch verdient, oder ob es andere mit euren Mitteln tun  .

Was ich aber eigentlich schreiben wollte:
Ich habe mir mal eben kurz den FB "FT_PT1" angesehen. Wenn ihr die Systemzeit zur Generierung der Abtastzeit verwendet, solltet ihr auch deren Überlauf berücksichtigen. Dann ist mir die Variable "init" aufgefallen. Sie liegt in den statischen Lokaldaten. Wenn sie einmal gesetzt ist, bleibt sie gesetzt. Sie sollte besser als Bausteinparameter Verwendung finden.


Gruß, Onkel


----------



## hugo (11 März 2007)

ein überlauf bei time erzeugt keinen fehler,
den wir werten immer nur die differenz zwischen aktueller und letzter zeit aus.
auch beim überlauf erbibt die subtraktion ein gutes ergebniss, auch dann wenn der alte wert noch nicht übergelaufen wäre.
allerdings konnten wir das noch nicht auf s7 testen, sollte aber genauso funktionieren, das ist eigentlich allgemeingültige computertechnik


----------



## hugo (11 März 2007)

hallo onkel dagobert,
das wir keine s7 umgebung haben koenntest du uns mit einem kurzen test helfen:

t1 := ein wert am oberen ende des wertebereichs ( 24 tage )

t2 := t1 + 10 tage

t3 := t2 - t1

t3 muss dann wieder 10 tage ergeben
wen dem so laufen die zeitfunktionen auch auf siemens s7 einwandfrei


----------



## hugo (11 März 2007)

Onkel Dagobert schrieb:


> Hallo Hugo,
> 
> ihr seht euch also dazu berufen, so zu sagen :-D . Na dann passt mal gut auf dass ihr euer Geld mit professionellen Anwendungen auch morgen noch verdient, oder ob es andere mit euren Mitteln tun  .
> 
> ...




wir sehen das ganz anders, den je mehr leute unsere lib benutzen, und uns feedback geben dann wuird sie besser als alle anderen und wir profitieren davon
schau dir mal den satz ganz oben im forum an:
"wissen ist das einzige gut das sich vermehrt wenn man es teilt"
unsere lib mit allen zu teilen erzeugt mehr als wenn wir das nicht tun, also haben wir auch mehr davon


----------



## Onkel Dagobert (11 März 2007)

Hallo hugo,

deinen Test mit t1, t2 und t3 habe ich durchgeführt, funktioniert natürlich.



hugo schrieb:


> ..auch beim überlauf erbibt die subtraktion ein gutes ergebniss, auch dann wenn der alte wert noch nicht übergelaufen wäre..


Wenn (Tx - last) für nur einen einzigen Zyklus einen sehr großen negativen Wert annimmt, findet sich dein PT1-Glied nicht wieder.


Die Korrektur bei Überlauf müsste ungefähr so aussehen:

```
#dt := TIME_TCK() - last;
IF #dt < T#0ms THEN
    #dt := #dt + T#24D_20H_31M_23S_647MS;
END_IF;
```
 
Gruß, Onkel


----------



## hugo (12 März 2007)

hi dagobert,
danke das du den überlauf test für mich gemacht hast.
da er funktioniert wird es auch kein überlaufproblem geben.
den wir werten nie auf gropßer kleiner aus, sondern vielmehr machen wir immer tx := time() - last
und tx wird dann ausgewertet.

tx ergibt aber nie einen unsinnigen wert den wie dein test ja beweist ist die subtraktion auch bei überlauf ok.

eventuelle startup probleme beheben wir durch init direkt beim ersten aufruf.

eine korrektur wie du sie vorschlägst sollte also nicht nötig sein.

es ist völlig egal ob time nun negativ ode positiv ist. die differenz zweier zeiten ergibt immer das gleiche


----------



## Werner54 (12 März 2007)

*Wirklich immer?*



hugo schrieb:


> es ist völlig egal ob time nun negativ ode positiv ist. die differenz zweier zeiten ergibt immer das gleiche


Hallo,

solange das mehrmalige schnelle Drücken derselben Taste unter Windoof "Schwerer Ausnahmefehler" erzeugen kann, bin ich da nicht so sicher. Tatsächlich halte ich es für sicherer, z.B. beim Zeitformat die kleinere Zahl von der größeren abzuziehen, statt umgekehrt.


----------



## Onkel Dagobert (12 März 2007)

Hugo, Hugo,

vielleicht überdenkst du das nochmal? Grundrechenarten erkläre ich hier nicht.


```
T#24D_20H_31M_23S_637MS - T#24D_20H_31M_23S_617MS = T#20ms
--> ok
 
 
einen Zyklus später:
 
T#10ms - T#24D_20H_31M_23S_637MS = [COLOR=red]-T#24D_20H_31M_23S_627MS[/COLOR]
--> fatal error for oscad lib ?
```
 

Gruß, Onkel


----------



## hugo (12 März 2007)

nun ich verstehe es immer noch nicht
:

1. ein überlauf einer variablen erzeugt keinen fatal error weil bei einer variablen sowas auch zur laufzeit nicht geprüft wird.

wenn der wert üner 24d geht und ein überlauf stattfindet dann erhalten wir bei siemens time etwas mit -24d ....
der alte gespeicherte wert liegt noch bei etwas unter 24d.

wenn ich nun von einem ganz am unteren werttebereich liegenden wert mit etwa -24d nehme und davon einen wert von ca +24d abziehe bekomme ich wieder die normale differenz wie wenn ich auch von 23d 22d abziehe, dagobert hat das ja siehe oben auch auf siemens für uns getestet.
unter codesys sieht das im prinzip genauso aus lediglich mit dem unterschied das wir dort den wertebereich von 0 - 48d haben.

zahlen in der edv sind absichtlich so kodiert das genau dieses mit überlauf funktioniert. wieso wollt ihr dann korrigieren wo es gar nichts zu korrigieren gibt.

ich darf nur nicht operationen wie t1 < t2 oder sowas machen aber t2 - t1 ergibt immer sinn.


----------



## hugo (12 März 2007)

nun ich verstehe es immer noch nicht
:

1. ein überlauf einer variablen erzeugt keinen fatal error weil bei einer variablen sowas auch zur laufzeit nicht geprüft wird.

wenn der wert üner 24d geht und ein überlauf stattfindet dann erhalten wir bei siemens time etwas mit -24d ....
der alte gespeicherte wert liegt noch bei etwas unter 24d.

wenn ich nun von einem ganz am unteren werttebereich liegenden wert mit etwa -24d nehme und davon einen wert von ca +24d abziehe bekomme ich wieder die normale differenz wie wenn ich auch von 23d 22d abziehe, dagobert hat das ja siehe oben auch auf siemens für uns getestet.
unter codesys sieht das im prinzip genauso aus lediglich mit dem unterschied das wir dort den wertebereich von 0 - 48d haben.

zahlen in der edv sind absichtlich so kodiert das genau dieses mit überlauf funktioniert. wieso wollt ihr dann korrigieren wo es gar nichts zu korrigieren gibt.

ich darf nur nicht operationen wie t1 < t2 oder sowas machen aber t2 - t1 ergibt immer sinn.

wie dagobert für mich ja auch auf simens getestet hat:
deinen Test mit t1, t2 und t3 habe ich durchgeführt, funktioniert natürlich.
deinen Test mit t1, t2 und t3 habe ich durchgeführt, funktioniert natürlich.


----------



## Onkel Dagobert (12 März 2007)

Hallo Hugo,

aha, jetzt verstehe ich, wo unser Missverständnis liegt. Bei der S7 ist es so dass von 0 bis 2147483647ms (=24d) gezählt wird. Bei Überlauf wird wieder bei 0 begonnen!



			
				Auszug aus der Step7-Onlinehilfe zur SFC64 schrieb:
			
		

> Beschreibung
> Mit der SFC 64 "TIME_TCK" (time tick) lesen Sie die Systemzeit der CPU. Die Systemzeit ist ein "Zeitzähler", der von 0 bis max. 2147483647 ms zählt. Bei einem Überlauf der Systemzeit wird wieder ab 0 gezählt. Das Zeitraster und die Genauigkeit der Systemzeit betragen bei S7-400 und bei der CPU 318 1 ms, bei allen anderen CPUs der S7-300 10 ms. Die Systemzeit wird nur von den Betriebszuständen der CPU beeinflußt.


 
Ich versuche das mittels SCL auch noch mal zu belegen.

In codesys geht es nach 48D mit -48D weiter?


Gruß, Onkel


----------



## Onkel Dagobert (12 März 2007)

Onkel Dagobert schrieb:


> ..Ich versuche das mittels SCL auch noch mal zu belegen...


Kann ich ja garnicht. Wenn ich den tatsächlichen Zeitpunkt des Überlaufs sehen möchte, müsste ich ja 24 Tage warten. Manipulieren lässt sich die Systemzeit nicht, und eine Simulation bringt auch nichts.

Aber ich denke mal, das es schon so ist.


Gruß, Onkel


/edit/
Hier noch ein paar links zum Thema.
http://support.automation.siemens.com/WW/view/de/640451  (Bsp. als pdf-File)
http://support.automation.siemens.com/WW/view/de/8736315
http://support.automation.siemens.com/WW/view/de/8736822


----------



## dalbi (13 März 2007)

Danke,

soweit habe ich noch gar nicht gedacht.
Werde die Funktionen die TIME_TCK nutzen um eine Überlaufkorrektur
demnächst ergänzen.

mfg
Daniel


----------



## hugo (13 März 2007)

hi leute,
jetzt haben wir aber die verschiedensten widersprüchlichen aussagen:

fakten:
1. iec61131 sieht für den typ time den wertebereich 0 .. 49 tage vor
also keine negativen zeiten.

in codeesys ist dies auch so implementiert.

2. nach euren aussagen in diesem thread hat s7 typ time den wertebereich -24 tage .. + 24 tage.

3. meine aussage das bei beiden implementationen ein überlauf oben und unten im wertebeich stattfindet.
beim überlauf ist zu beachten das nach einem überlauf:

A. eine vergleich größer kleiner scheitert weil ja der vermeintlich größere werte plötzlich ein ganz kleiner ist. in so einem fall muss eine korrektur in software gemacht werden.

B. in den funktioinen von oscat verwenden wir bei system time abfragen solche größer kleiner vergleiche nicht um der überlaufproblematik aus dem weg zu gehen.
egal welcher wertebereich vorliegt, eine subtraktion zweier werte gleichen abstands ergibt immer die gleiche differenz egal ob ein überlauf stattgefunden hat oder nicht, auch wenn nur einer der beiden werte übergelaufen ist.
in diesem fall der anwendung ist somit keine korrektur am oberen oder unteren ende des wertebereichs nötig.


----------



## hugo (4 April 2007)

die aktuelle version der oscat lib für s7 behebt etliche timing probleme und steht auf der oscat web page unter www.oscat.de zum download bereit


----------

