Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - psyche

Seiten: [1]
1
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 29. Juli 2015, 20:14:26 »
http://www.oscat.de/community/index.php/topic,2244.msg11666.html#msg11666

Offiziell gibts die nicht, da die S7 offensichtlich schon seit Jahren nicht mehr supportet wird

2
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 15. Juni 2015, 08:31:23 »
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.

3
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 05. Oktober 2014, 20:51:17 »
Hi,

STime ist die Wurzel allen Übels, weil es ja die Zeit für alle Zeit basierten Funktionen aufbereitet. Jeder Fehler der dort passiert, wird an nachfolgende Bausteine übergeben.


FUNCTION_BLOCK CLK_PRG
TITLE = 'CLK_PRG'
//
//clk_prg uses the internal sps time to generate a clock with programmable period time.
//the period time is defined for 10ms .. 65s
//the first cycle after start is a clk pulse and then depending on the programmed period time a delay.
//every pulse is only valid for one cycle.
//the accuracy of clk_prg is depending on the accuracy of the system clock.
//
//uses: T_PLC_MS [FC64]
//      STIME [FB64],IDB_STIME [DB64]
//
VERSION : '1.4'
AUTHOR  : hugo
NAME    : CLK_PRG
FAMILY  : GENERAT

VAR_INPUT
  PT : TIME := t#10ms;
END_VAR
VAR_OUTPUT
  Q : BOOL := 0;
END_VAR
VAR
  last : TIME;
  tx: TIME;
END_VAR
VAR_TEMP
END_VAR

BEGIN
(* read system time *)
tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));
 
(* generate output pulse when next_pulse is reached *)
Q := tx - last >= pt OR tx - last < t#0ms;
IF Q THEN last := tx; END_IF;
 
 
(* revision hiostory

hm 25 feb 2007  rev 1.1
    rewritten code for higher performance
    pt can now be changed during runtime

hm  17. sep 2007    rev 1.2
    replaced time() with t_plc_ms() for compatibility reasons

hm  25. oct. 2008   rev 1.3
    optimized code
   
psyche 05.10.2014 rev 1.4
  nearly completely revised because of bugs in init procedure

*)
END_FUNCTION_BLOCK


Ich würde es so machen, wenn du meinen STime benutzt.
Maximaler Fehler ist hier  2x PT. D.H. wenn während der Programmbearbeitung ein CPU Neustart oder ein IDB download stattfindet und PT= T#1s ist, kann die Periodendauer zwischen dem letzten Impus und dem neuen Impuls zwischen T#10ms und T#2s liegen.
Wenn deine Anlage das nicht ab kann, musst du IDB_STime.Init_happened verwenden um einen geführten Neustart zu erreichen.
Aber immer daran denken, Init_happened muss nach Verwendung manuell zurück gesetzt werden.

Welche CPU du verwendest ist egal, dass ist alles Hardware neutral.
Wenn du das testest, wäre feedback nett.

4
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 01. Oktober 2014, 19:03:11 »
Sie dir mal das hier an :
http://www.oscat.de/community/index.php/topic,2244.msg11666.html#msg11666

Wenn du in deinem Programm dann noch IDB_STime.Init_happened auswertest, sollte das ganze fehlerfrei laufen.

5
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 01. Oktober 2014, 18:56:29 »
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.


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



6
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 29. September 2014, 10:56:56 »
Guten Morgen,

so, ich habe immer noch kein Step7 zur Hand aber ich hab das ganze mal in Codesys geladen.
Du hast ja nur noch 4 Zeilen Code übrig  :o Das ging in der Codebox hier im Forum irgendwie unter.

Also noch mal von vorne :

"IDB_STIME"();
#tx := "IDB_STIME".tx;

Hier öffnest du den STIME IDB und liest die aktuelle Zeit aus. Das verursacht eine Reihe von Problemen:
1. Du rufst nirgends den STime auf, also kann STime auch nicht die aktuelle Zeit in seinen IDB schreiben. Da es offensichtlich trotzdem funktioniert, benutzt du anscheinend den STime irgendwo anders im Programm. Durch Zykluszeitschwankungen kannst du hier eine Ungenauigkeit in der Zeitmessung verursachen.
2. Der Init-Abschnitt ist weg. Ich denke hier liegt auch dein Problem. Beim Anlauf der CPU (nach Fehler, Hardware download, Stromausfall (!), etc) fängt die Systemzeit wieder bei 0 an. Wird das nicht abgefangen, kann die Zeit irgendwo liegen. Im ungünstigsten Fall wartest du dann 24 Tage auf den nächsten Impuls.

IF #Q OR NOT "IDB_STIME".init THEN #last := #tx; END_IF;
Wie schon geschrieben, das "IDB_STIME".init ist nutzlos. Ausser du hast ein Konstrukt geschaffen in dem STime erst nach CLK_PRG aufgerufen wird. Was aus verschiedenen Gründen auch nicht sonderlich Schlau wäre.

Es übrigens praktisch wenn STime ein Bit ausgeben würde das im Init-Zyklus true ist. Das würde einem die Init Routine in den Nachfolgebausteinen ersparen.
Im Nachhinein leider umständlich einzubauen.

Zusammengefasst reagieren Zeit-Funktionen immer sehr sensibel auf Störungen (Downloads, Neustarts, etc).
Aber mit deinen Änderungen hast du es meiner Meinung nach mehr schlechter als besser gemacht. So wie der Code war, müsste er schon funktionieren.
Die Probleme lagen hauptsächlich im STime <= V1.4.

Wie schon geschrieben, wenn du noch ein wenig Sicherheit reinbringen willst dann mach lieber was in der Richtung :
IF #Q OR #tx - #last < T#0ms THEN #last := #tx; END_IF;Das verhindert das sich der Baustein "aufhängt". Obwohl das eigentlichgar nicht passieren sollte.

7
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 28. September 2014, 11:55:15 »
S5_Time ? Meinst du STime ?

Poste mal deinen kompletten aktuellen CLK_PRG. Sonst kenn ich mich jetzt gar nicht mehr aus.

Btw, für was braucht man denn PWM_DC ? Kann mir gerade keine praktische Anwendung vorstellen  ;D

8
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 24. September 2014, 23:17:14 »
also ich interpretiere mir das gerade aus deinen geposteten codeschnippseln. habe gerade kein step7 zur hand.

wenn du beim download probleme bekommst, liegt das meine meinung nach daran das du den STime IDB mit runter lädst. Das ist eine ganz schlechte idee.
wenn Stime gerade einen negativen wert hat und du lädst den Stime IDB neu runter, wird der wert auf einmal positiv werden, da du das gespeicherte bit31 zurücksetzt und ausserdem einen init auslöst.

IF #Q OR NOT "IDB_STIME".init THEN #last := #tx; END_IF;
diese änderung ist meiner meinung nach nutzlos, da "IDB_STIME".init nur nach einem CPU neustart oder IDB download false ist. Nach dem ersten Aufruf von STime ist init wieder true. Und das passiert, wenn ich mich richtig erinnere hier :

(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));

-----

"IDB_STIME"();
#tx := "IDB_STIME".tx;

oben alles wegschneiden und das hier stehenlassen wird auch nicht funktionieren.
erstens wird dann STime nicht mehr ausgeführt, die Zeit ändert sich also nicht mehr.
zweitens ist die initialisierungs routine wichtig für einen cpu neustart. Ohne kann die zeit #last irgendwo stehen.

der code passt meiner meinung nach so wie er ist. probleme entstehen nur wenn die zeit unvorhergesehene sprünge macht. z.B. durch einen IDB download.
das einzige was ich mir hier zur sicherheit noch vorstellen kann wäre sowas :

IF #Q OR #tx - #last < T#0ms THEN #last := #tx; END_IF;
das hält zumindest die auswirkungen in grenzen. sprich die zeit des ersten impulses nach dem fehler stimmt nicht mehr. im schlimmsten fall 2x #PT


oder aber ich habe dich komplett falsch verstanden und habe nur bullshit geschrieben  ;D

9
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 24. September 2014, 11:07:57 »

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.

Zitat
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

10
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 24. September 2014, 11:00:58 »
... 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)

11
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 24. September 2014, 10:45:56 »
... 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.

12
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 18. September 2014, 14:06:16 »
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.

... siehe Beitrag weiter unten...

13
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 18. September 2014, 13:34:45 »
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.

14
oscat.lib fuer Step 7 / Die STime Misere
« am: 17. September 2014, 21:21:31 »
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.


Seiten: [1]