ACTUATOR_2P bleibt stehen

[Fussel0804]

Ja, genau das ist auch meine vermutung.

[gkobler]

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

[Fussel0804]

Ich habe den Actuator_2P bei mir im Test und bisher noch keine schwierigkeiten gehabt.

In dem Baustein fehlt die initialisierung.
Ich kümmerte mich darum.

Gruß Stefan

[gkobler]

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

[gkobler]

Folgend noch ein Printscreen des DB64!

[gelöscht durch Administrator]

[gkobler]

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

[dalbi]

Hi,

Fussel hat recht in dem Baustein ist noch ein Fehler drin.

Ich hoffe ich komme am Wochenende dazu. Die geänderten Bausteine stelle ich dann hier rein.

Gruss Daniel

[dalbi]

Hi,

oha, wie lange ist das jetzt schon so. Ist ja der Hammer.

Bitte den Baustein STIME gegen die Version im Anhang tauschen.

Vielen Dank für eure Unterstützung.

Gruss Daniel

[gelöscht durch Administrator]

[Fussel0804]

Danke,

ich werde den Baustein nun ausgiebig testen

Gruß Stefan

[gkobler]

Danke Daniel!

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

Gruss
Gregor

[gkobler]

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]

[Fussel0804]

Ja, ich habe heute nacht das gleiche festgestellt.

Das problem ist glaube ich der Baustein ACTUATOR_2P selbst.
Ich werde ne initialisierungsroutine reinbasteln.

Gruß Stefan

[gkobler]

Hallo Stefan

Konntest du den Baustein schon korrigieren?

Gruss und Danke
Gregor