Die STime Misere

[psyche]

Hi,

ich habe vor einigen Monaten ein paar größere (Industrie) Projekte begonnen und dann ziemlich begeistert festgestellt das mir die Oscat Bibliothek einiges an Arbeit sparen kann.
Also alles getestet und für gut befunden.
Mittlerweile sind bereits eine Handvoll Anlagen in (produktivem) Betrieb.

Bei der Entwicklung eines neuen Moduls lese ich Heute im Forum zufällig das die STime Funktion, offensichtlich in so gut wie jeder zeitbasierten Funktion verwendet, verbugt ist und alle 24 Tage unvorhersehbare Fehler produziert. Und das ganze ist bereits seit 2011 (!!) bekannt.
Der Autor dalbi, offensichtlich schon lange nicht mehr aktiv, hat sogar noch eine neue Version (1.5) als code gepostet.
http://www.oscat.de/community/index.php/topic,1392.msg8164.html#msg8164

Ich bin jetzt ehrlich gesagt ziemlich sauer. Einerseits weil es niemand für nötig gehalten hat den bugfix in das release einzubauen, bzw wenigstens darauf hinzuweisen  und andererseits weil ich so blöd war auf die Arbeit anderer zu vertrauen.

Wollte mir das nur mal von der Seele schreiben und evtl andere warnen. Zumindest für Siemens ist Oscat so nicht zu empfehlen.

[gkobler]

Hallo Psyche

Ich versteh jetzt deinen Ärger nicht!! Lade die neue Version STIME V1.5 herunter, ersetzte die SCL-Quelle in deinen Projekten und übersetzte die Quellen neu, danach musst du die Bausteine auf die CPU laden. Fertig!

Gruss
Gregor

[psyche]

du kannst wirklich nicht verstehen warum micht das ärgert ?
hier geht es nicht um eine Jalousie die vielleicht mal zur falschen Zeit runter fährt sondern um Industrieanlagen die unvorhersehbare Sachen machen. Inkl Produktionsausfall, Bereitschaftseinsätze, etc.
Und wie merkt man das ganze ? Richtig, entweder es treten unerklärliche Phänomene auf oder man liest zufällig 3 Jahre alte Beiträge hier im Forum.
Ein Vermerk bei den Siemens Libarys "Es sind diverse Bugs bekannt, werden aber aufgrund wasweisich nicht mehr gefixt. Bitte im Forum nachlesen" und die Sache wäre klar.

[psyche]

habe STime noch auf den Time_Tck bug bei älteren Siemens CPU's angepasst.
Kurz getestet und funktioniert, aber ist ja immer schwer zu sagen bei Zeitfunktionen. Vielleicht kann ja noch jemand drüber schauen.

Code Auswählen Erweitern

... siehe Beitrag weiter unten...

[mg]

... muß mich auch noch einmischen ...

Bitte beachte auch die letzten paar Beiträge von mir.
Ich bin auch ein bischen verärgert, daß die Siemens-Anbindung kaum mehr gewartet wird. Aber was soll man machen, man kann auch alles selber schreiben, dann gibts halt noch mehr Fehler. Trotzdem würde es mich freuen, wenn es mit der dem S7-Oscat wieder mal weiter ginge.
Nun noch ein Kommentar zu deinen Antworten ... wenn man schon eine "kostenlose" LIB irgendeines dir sicher unbekannten Programmiers verwendet, kann man schon erwarten, daß man die Meldungen des letzten Jahres in dem Forum durchgehen (Gott sei Dank gibt es das!!!). Ich habe das auch gemacht! Das braucht grad mal 1-2h. Und noch was ... ich lege mit Programmierfehlern in meinen Anlagen ganz Werke still ... nicht nur ein paar Maschinen und trotzdem verwende ich die OSCAT.

ABER TROTZDEM HOFFE ICH DASS ICH HIER WIEDER MAL WAS VON DIR HÖRE. Wir brauchen Kommentare zur LIB. DAS HILFT ALLEN!!!

Danke

Mg

[mg]

... zur STIME V1.6

Was hast Du geändert? (bin zu faul um es zu suchen)
Warum hast Du es geändert?

Ich verwende derzeit zu 100% die S7-1500 ... letztes Jahr hatte ich noch (die letzte) S7-300.
Alles mit TIA (dzt V13)

Mg

[gkobler]

Hallo Psyche

Sicher kann ich irgenwie deinen Ärger verstehen, aber "mg" hat alles gesagt, was es darüber zu sagen gibt.

Auch ich setzte die OSCAT-Library in Produktiven Anlagen ein, und hatte auch schon meinen Ärger. Aber seit der Version 1.5, konnte ich kein Fehlverhalten seitens der OSCAT-Library mehr feststellen.

Zu deinem Problem in der V1.6. Gibt es für deine alte CPU keinen FW-Update? So wie du es beschreibst, liegt es ja nicht an der Funktion STIME sondern eher an der CPU!? Ich habe mir deine Änderung angeschaut, ich denke auch, dass es funktioniert.

Gruss
Gregor

[psyche]

... muß mich auch noch einmischen ...

Bitte beachte auch die letzten paar Beiträge von mir.
Ich bin auch ein bischen verärgert, daß die Siemens-Anbindung kaum mehr gewartet wird. Aber was soll man machen, man kann auch alles selber schreiben, dann gibts halt noch mehr Fehler. Trotzdem würde es mich freuen, wenn es mit der dem S7-Oscat wieder mal weiter ginge.
Nun noch ein Kommentar zu deinen Antworten ... wenn man schon eine "kostenlose" LIB irgendeines dir sicher unbekannten Programmiers verwendet, kann man schon erwarten, daß man die Meldungen des letzten Jahres in dem Forum durchgehen (Gott sei Dank gibt es das!!!). Ich habe das auch gemacht! Das braucht grad mal 1-2h. Und noch was ... ich lege mit Programmierfehlern in meinen Anlagen ganz Werke still ... nicht nur ein paar Maschinen und trotzdem verwende ich die OSCAT.

ABER TROTZDEM HOFFE ICH DASS ICH HIER WIEDER MAL WAS VON DIR HÖRE. Wir brauchen Kommentare zur LIB. DAS HILFT ALLEN!!!

Danke

Mg

Das Problem ist, wo fängt man an und wo hört man auf.
Wenn eine Funktion 5 andere aufruft musst du dir die auch ansehen.

Wie gesagt, wenn man das weiß, kann man damit leben.
Ich habe z.B. Oscat entdeckt, gesehen das die lib viel verwendet wird, kurz im Forum geschaut und nur ein paar Anfängerfragen gefunden.
Ergo davon ausgegangen das das alles gut funktioniert. Klar, ein paar kleine bugs kann man immer finden.

[psyche]

... zur STIME V1.6

Was hast Du geändert? (bin zu faul um es zu suchen)
Warum hast Du es geändert?

Ich verwende derzeit zu 100% die S7-1500 ... letztes Jahr hatte ich noch (die letzte) S7-300.
Alles mit TIA (dzt V13)

Mg

Im Grunde wird nur geschaut ob der letzte Aufruf länger als 5 Sekunden her ist. Wenn ja, wird liefert die Funktion die letzte erfolgreich ausgelesene Zeit zurück.
Die verworfene Zeit wird beim nächsten Zyklus aufaddiert.

Hintergrund :
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&objId=27153361&nodeid0=28377447&load=treecontent&lang=de&siteid=cseus&aktprim=0&objaction=csview&extranet=standard&viewreg=WW

Wenn du eh nur die 1500er einsetzt, kannst du das getrost ignorieren. Das ist mehr für 300er CPU's älteren Baujahres (meistens die breiten Bauformen)

[psyche]

Zu deinem Problem in der V1.6. Gibt es für deine alte CPU keinen FW-Update? So wie du es beschreibst, liegt es ja nicht an der Funktion STIME sondern eher an der CPU!? Ich habe mir deine Änderung angeschaut, ich denke auch, dass es funktioniert.

Gruss
Gregor

Aktuell läuft STime noch auf einer 314IFM, da ist nichts mit Update. Mal davon abgesehen das ja für einige CPU's nie Updates heraus gekommen sind.

Für folgende Geräte mit Firmwarestand V1.x gibt es keine Updatemöglichkeit.

    Für alle Versionen von C7-621, 623, 624, 626, 633 und 634

    Für CPU 312IFM, CPU 313, CPU 314, CPU 314IFM, CPU 315, CPU 315F, CPU 315-2DP und CPU 316-2DP

Grundsätzlich schadet ja der Code für den Bugfix nicht. Er ist bei mir daher überall vorhanden, damit muß ich mir keine gedanken mehr über den Bug machen

[psyche]

So, nachdem ich die letzten Tage größere Probleme mit Zeit basierten Oscat-Funktionen hatte, habe ich mir den STime noch mal vorgenommen.
Dabei bin ich auf noch viel mehr Probleme gestoßen.
Um es kurz zu machen :

- Die Init Prozedur über RD_SINFO funktioniert grundsätzlich nur wenn STime über OB1 aufgerufen wird. Und da bin ich mir auch nicht ganz sicher.
Wenn man andere OB's für seine Programme benutzt (z.B. OB35 Weckalarm, etc) ist Init komplett ohne Funktion.
- Die Überlauf Erkennung ist viel zu anfällig für Störungen

Ich habe mir das mal zum Anlass genommen und den STime komplett überarbeitet.
Darin neu :
- Wenn man die Plattform Unabhängigkeit bewahren will, ist es unmöglich im Baustein einen Neustart der CPU, und damit einen Systemuhr Reset zu erkennen.
Ich habe kurz mit dem Gedanken gespielt im OB100 (Wird beim Warmstart aufgerufen) ein IDB_STime.init := false einzufügen. Das ist zwar sicher aber man muss es manuell erledigen. Deswegen habe ich das wieder verworfen. Alle anderen Methoden die mir eingefallen sind, kann man auch nur als "dirty" bezeichnen.
Ich habe mich daher entschieden eine max_Cycletime einzuführen, auf dessen Grundlage ich die Plausibilität der zurückgelieferten Systemzeit bewerten kann.
- Ein Systemzeit Überlauf wird jetzt nur noch erkannt wenn last_time > T#24D_20H_31M_23S_647MS - max_Cycletime ist, also wenn der Systemtimer im letzten Zyklus bereits kurz vor dem Überlauf stand. Selbst für den extrem unwahrscheinlichen Fall das in diesem Zeitfenster ein CPU Neustart stattfindet, ist der Zeitfehler maximal max_Cycletime, was man in den meisten Fällen verschmerzen kann (zumindest in meinen Fällen).
- Ein CPU Neustart wird jetzt dadurch erkannt, dass  der Systemtimer < max_Cycletime ist und last_time nicht kurz vor dem Überlauf stand.
In diesem Fall wird ein Init ausgelöst, die Zeit auf 0 gesetzt und das Bit Init_happened gesetzt.
- Mit Init_happened habe ich eine Möglichkeit hinzugefügt, in nachfolgenden Funktionen einen erfolgten Init auszuwerten. Da STime ja durchaus mehrmals pro Zyklus aufgerufen werden kann, kann Init_happened leider nicht automatisch zurückgesetzt werden. Wenn man das Bit auswerten will, muss man es am Ende des Zyklusses manuell zurücksetzen.
- Der Time_Tck Bug bei CPU's <V2.01 Firmware wird gefixt. Tritt der Bug auf, wird der Zyklus ignoriert und die verstrichene Zeit im nächsten Zyklus aufgeholt.

Ich habe das Ganze ziemlich ausführlich im Simulator getestet, aber falls jemandem noch was einfällt, immer raus damit.

getestete Reaktionen des Bausteins :
- Überlauf Systemtimer --> tx wird auf Negativ gesetzt, beziehungsweise auf Positivs falls tx vorher schon Negativ war.
- Neustart CPU --> Init wird ausgelöst, tx beginnt wieder bei Positiv 0, Init_happened wird gesetzt
- IDB download oder manuelles IDB_STime.init setzen --> tx wird einen Zyklus lang 0, im nächsten Zyklus wird tx auf Systemtimer gesetzt mit positivem Wert. --> Nicht empfehlenswert, verursacht ganz sicher Probleme.
- Time_Tck Bug tritt auf --> Fehlerhafte Zeit wird ignoriert und im nächsten Zyklus nachgeholt.

Code Auswählen Erweitern

FUNCTION_BLOCK STIME
TITLE = 'STIME'
//
//this function block makes sure that the timer of a siemens sps counts from 0 - 2^32-1.
//
VERSION : '1.6'
AUTHOR  : dalbi
NAME    : STIME
FAMILY  : MEASURE

VAR_INPUT
END_VAR
VAR_OUTPUT
  tx : DWORD;
    at_tx AT tx : ARRAY[0..31] OF BOOL;
END_VAR
VAR
  last_time: DWORD;
  bit31: BOOL;
  init: BOOL := false;                       
  max_Cycletime : TIME := t#2s;             // Max cycletime default 2 second. Can be adjust when you need longer cycletimes.
  Init_happened : BOOL := false;            // An Init happened (CPU restart, etc). Time resetted to T#0ms or actual Timer value. Reset this manuell when you use it
  cycle : INT := 0;                         // Value of error Cycles
(*  TX_Sim : TIME;                            // Actual time ONLY for simulation
*)
END_VAR
VAR_TEMP
  lastBit31:BOOL;
  TimeDiff:TIME;   
  last_time_temp : DWORD;                   // last_time but always positive
    at_last_time_temp AT last_time_temp : ARRAY[0..31] OF BOOL;
END_VAR

(* this FB is only necessary for siemens sps
the siemens sps timer counts from 0 to 2^31-1 and starts at 0 sfter overrun.
this means that the bit 31 (the highest bit ) will never be used and therefore
a problem arises when t2 - t1 is checked.
t2 - t1 is always valid also in an timer overrun situation where the time t1 is very high and t2 is very low.
the result of the subtraction t2 - t1 however is still valid.
this calculation does not work for soiemens because the highest bit is not used.

this module stores the highest bit, changes the highest bit at every overrun occurence and stuffs ther highest bit in the output.
the output is then used by t_plc_us and t_plc_ms.

the correction needs and fb and not a function because the value of the highest bit has to be stored.

do never use this function block in a codesys environment. the timer in codesys is correct and runs from 0 to 2^32-1
*)
 
(* read the system timer *)
tx := DINT_TO_DWORD(TIME_TO_DINT(TIME_TCK()));
(* only for simulation
TX_Sim := TX_Sim + t#10ms;
tx := DINT_TO_DWORD(TIME_TO_DINT(TX_Sim));*)


(* Check if Init necessary*)
(* On warmstarts the Siemens CPU's sets the systemtimer to 0 and also when a overrun occurs*)
last_time_temp := last_time;
at_last_time_temp[7] := false; (*set the last_time to a positiv value. Make savings on calculations*)
IF DWORD_TO_DINT(tx) < TIME_TO_DINT(max_Cycletime) AND DWORD_TO_DINT(last_time_temp) < TIME_TO_DINT(T#24D_20H_31M_23S_647MS - max_Cycletime) AND DWORD_TO_DINT(last_time_temp) > TIME_TO_DINT(max_Cycletime)THEN
  init := false;
END_IF;

(* reset last_time on system startup *)
IF NOT init THEN
    last_time := 0;
    bit31 := false;
    init := true;
    Init_happened := true;
END_IF;

(* check for overrun *)
IF DWORD_TO_DINT(tx) < TIME_TO_DINT(max_Cycletime) AND DWORD_TO_DINT(last_time_temp) > TIME_TO_DINT(T#24D_20H_31M_23S_647MS - max_Cycletime) THEN
    (* an overrun has occured, change the value of the highest bit *)
    bit31 := NOT bit31;
END_IF;

(* stuff the highest bit into the timer value *)
at_tx[7] := bit31;

(* Check for Time_Tck bug on older S/-300 CPU's Firmware < 2.01*)
TimeDiff := DINT_TO_TIME(DWORD_TO_DINT(tx)) - DINT_TO_TIME(DWORD_TO_DINT(last_time));
IF (TimeDiff > max_Cycletime OR TimeDiff <T#0ms) AND cycle = 0 THEN
    tx := last_time;
    cycle := cycle +1;
ELSE
(* remember the last system time for the next overrun check *)
    last_time := tx;
    cycle := 0;
END_IF;

(* revision history
DA  14.9.2007 rev 1.0
  original version

DA  24.2.2008 rev 1.1
  added self reset on system startup

DA   2.5.2008 rev 1.2
  correct a problem running under OB35

DA  12.3.2009 rev 1.3
  correct a problem run on different CPUs

DA  22.12.2009 rev 1.4
  correct a problem on startup

DA  19.09.2011 rev 1.5
  correct a error in code
 
psyche 01.10.2014 rev 1.6
  nearly completely revised because of many bugs
*)
END_FUNCTION_BLOCK


DATA_BLOCK IDB_STIME  STIME
//
// Instance data block for "STIME"
//
BEGIN

END_DATA_BLOCK


[mg]

Hallo Psyche

Ich habe seit ein paar Tagen die neue STime V1.6 bei einer 315 DP/PN (neueste FW) am laufen. (die STime 1.5 war untragbar ... hatte immer wieder Fehler, aber ich war lange nicht mehr vorort so hat sich das Ganze hinausgezögert)
Die Anlage bezeichne ich als SEHR kritisch.
Es sind massenhaft Regelbausteine drinnen und ich sollte in 1-2 Monaten eine Rückmeldung erhalten.

Mg

(hatte den diesen Kommentar ursprünglich bei http://www.oscat.de/community/index.php/topic,2195.0.html platziert ... nun korrigiert)
allerdings ACHTUNG: Es betrifft zumindest den Originalen CLK-PRG auch

[mg]

Wäre schön wenn ich auch mal was vom OSCAT-TEAM zu diesem Thema höre. Das betrifft ja einen Großteil aller Bausteine!!!

Mg

[psyche]

Ich habe vor 8 Monaten komplett auf die V1.6 umgestellt.
~10 CPU's, Laufzeitmessungen, Presszeitrechner, Zykluszeitmessungen, etc.
Seit dem kein einziges Problem mehr gehabt.

Ich benutze allerdings großteils Siemens Regler und selbst geschriebene Routinen, teilweise auf OSCAT Basis.
Wie das ganze mit den OSCAT Bausteinen harmoniert weiß ich also nicht, gehe aber davon aus, dass das ebenfalls passt.

[wo]

@psyche:

Danke für die Mühe, ich hatte auch schon einige Probleme damit.

MfG
wo