Beiträge

Hallo Benjamin

Wenn du die Version 1.5 von STIME hast, dann passt es! Ich hatte auch mal ein Problem mit dem Überlauf. Hatte damals von sämtlichen Bausteinen die ich eingesetzt hatte ein update auf die neueste OSCAT-Version gemacht. Seit dem läuft es bei mir ohne Probleme.

Lade die neueste Bibliothek herunter und vergleiche die Versionsnummer in deinem Projkekt mit denen in der Bibliothek!

Gruss
Gregor

Hallo Justi

Ich habe mir das Programm mal angeschaut. Du hast nichts falsch gemacht. Vermutlich hat der Baustein ein Fehler!

Der Parameter ARE muss beim Starten der CPU auf True sein, sonst bleibt der Status immer auf "0"! Der Status sollte glaube ich 100 sein, damit er arbeitet.

Ich Empfehle dir den Baustein STIME mit der Version 1.5 einzusetzten. Sonst kommt es beim Überlauf zu Fehlern.

Gruss
Gregor

[gelöscht durch Administrator]

Hallo

Du kannst die Datei downloaden und anschliessen von "index.php" in "irgend_ein_name.7z" umbenennen. Danach lässt sie sich mit dem 7-Zip Manager problemlos öffnen! (http://www.7-zip.org)

Anscheinend ist da noch ein Problem im Umgang mit Anhängen in diesem Forum.

Gruss
Gregor

Ich habe den Baustein HEAT_METER in meinem Programm zweimal aufgerufen (FB)

Normalerweise funktioniert er prima. Doch gelegentlich wird der berechnete Verbrauch um einen Offsetwert zurück gerechnet (siehe Anhang Snap2). Dies ist in diesem Jahr schon 4 mal passiert. Soweit konnte ich die Zeitpunkte ungefähr eingrenzen! Es muss was mit dem Überlaufen des Zeitgeber im STIME zu tun haben. Auffällig ist das es immer ungefähr zu diesem Zeitpunkt passiert ist! Auch habe ich einen Screenshot des Instanzen-DB's gemacht (Snap3), dort sieht man das die Zeit falsch berechnet wurde!

Heute habe ich die V1.5 von STIME geladen!

@Stefan: Ich glaube die Probleme die auch der ACTUATOR_2P und der ACTUATOR_3P haben, in diese Kategorie fallen!

Gruss
Gregor

[gelöscht durch Administrator]

Hallo Stefan

Wir hatten kürzlich wieder Probleme mit dem ACTUATOR_3P.

Die "Pos" wurde mit -41000 angezeigt, anstelle von irgenwo zwischen 0..100 %!

Irgenwie ist da immer noch der Wurm drin!

Gruss
Gregor

Hallo Stefan

Konntest du den Baustein schon korrigieren?

Gruss und Danke
Gregor

Hallo Stefan

Der Baustein STIME läuft soweit gut. Aber heute als die Zeit bei T#24d... in negative von T#-24h... kippte, hat der ACTUATOR_2P einen falschen Wert berechnent (siehe Anhang)!! Der Wert von pwgen.tx und pwgen.tn dürfte nie mehr wie 10min abweichen, da ich für die Pulsweitenmodulation eine Periodendauer von 10min definiert habe!

Somit "steht" der Ausgang quasi immer auf "1", zum Teil bis zu mehrere Tage!!

Gruss
Gregor

[gelöscht durch Administrator]

Danke Daniel!

Habe den Baustein gestern korrigiert! Werde es weiter im Auge behalten.

Gruss
Gregor

Der Code von STIME der bei mir läuft (Version 1.4)!

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.4'
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 := true;
END_VAR
VAR_TEMP
  TOP_SI: struct
    EV_CLASS: byte;
    EV_NUM:   byte;
    PRIORITY: byte;
    NUM:      byte;
    TYP2_3:   byte;
    TYP1:     byte;
    ZI1:      word;
    ZI2_3:    dword;
  end_struct;
  START_UP_SI: struct
    EV_CLASS: byte;
    EV_NUM:   byte;
    PRIORITY: byte;
    NUM:      byte;
    TYP2_3:   byte;
    TYP1:     byte;
    ZI1:      word;
    ZI2_3:    dword;
  end_struct;
  ERR : INT;
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 actual startup info *)
(* OB1_SCAN_1  BYTE  -  B#16#01: Abschluss des Neustarts (Warmstarts)
                     -  B#16#02: Abschluss des Wiederanlaufs
                     -  B#16#03: Abschluss des freien Zyklus
                     -  B#16#04: Abschluss des Kaltstarts
                     -  B#16#05: Erster OB 1-Zyklus der neuen Master-CPU nach
                                 Master-Reserve-Umschaltung und STOP des
                                 bisherigen Masters *)

ERR := RD_SINFO (TOP_SI := TOP_SI, START_UP_SI := START_UP_SI);

(* reset last_time on system startup *)
IF TOP_SI.EV_NUM = 1 OR TOP_SI.EV_NUM = 2 OR TOP_SI.EV_NUM = 4 OR NOT init THEN
    last_time := 0;
    bit31 := false;
    init := true;
END_IF;
 
(* read the system timer *)
tx := DINT_TO_DWORD(TIME_TO_DINT(TIME_TCK()));
 
(* check for overrun *)
IF DWORD_TO_DINT(tx) < DWORD_TO_DINT(last_time) 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;
 
(* remember the last system time for the next overrun check *)
last_time := tx;
 

(* 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
  corect a problem running under OB35

DA  12.3.2009 rev 1.3
  corect a problem run on different CPUs

DA  22.12.2009 rev 1.4
  corect a problem on startup
*)
END_FUNCTION_BLOCK


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

END_DATA_BLOCK

Folgend noch ein Printscreen des DB64!

[gelöscht durch Administrator]

Hallo Stefan

Heute konnte ich es grad Beobachten wie es zum Fehler kommt!!

tx: war so T#-1m... und lief gegen "0".
tn: wurde korrekt auf einen positiven Wert berechnet so ca. T#6m...

Aber als die Zeit bei "0" ankamm, wurde plötzlich wieder bei T#-24d20h... weiter gemacht!!! Hätte die Zeit nicht einen positiven Wert erhalten, und aufwärts zählen sollen??

Meiner Meinung stimmt im STIME immer noch was nicht!!

Gruss
Gregor

The complete OSCAT-Library Version 3.22 are now compiled without any fault. The migration should be complete!

Use it on your own risk!

Gregor

[gelöscht durch Administrator]

Hallo Stefan

Als ich heute wiedermal den Actuator kontrolliert habe, ist mir wieder aufgefallen, dass er sich aufgehängt hat!!

Als ich letzte Woche kontrolliert habe lief alles einwandfrei (Zeit: ~T#20d...)

Heute ist die Zeit bei T#-23d39m... und läuft rückwärts! Irgenwie kommt es zu einem Fehler, wenn die Zeit vom Positiven ins Negative läuft. Das ist glaube ich so um ca. T#24d... oder?

Die beiden Zeiten im DB64 sind identisch!!

Konntest du den Fehler schon reproduzieren?

Gruss
Gregor

Hello

I have migrate the OSCAT-Library 3.22 Basic from Step7 V5.5 Classic to the TIA11+SP1+Hotfix 1.

There was no fault durring the migration! But i didnt test it now!!

Gregor


[gelöscht durch Administrator]

Ja beide Doppelwörter haben den gleichen Wert!

Irgenwie habe ich den Verdacht das es zu einem Überlauf kommt!

Gruss
Gregor