OSCAT Forum
oscat.lib => oscat.lib fuer Step 7 => Thema gestartet von: gkobler am 21. Juni 2011, 09:08:32
-
Hallo Zusammen
Vor ein paar Tagen hatte ich das Problem, dass der ACTUATOR_2P stehen geblieben ist! (Werte siehe Anhang)
Bausteine sind aus der neuesten Library V3.11 und der Baustein STIME ist die V1.4 (korrigierte Version) und er wird im OB1 zyklisch Aufgerufen!
Aufgefallen ist die Differenz zwischen "tx" und "tn" (Negative Werte). Als wir "tn" auf T#-23D17H51M gesetzt haben, und die Zeit in "tx" abgelaufen war, funktionierte der Baustein plötzlich wieder! Eventuell ein altbekanntes Problem?
Besten Dank für die Hilfe!
Gregor
[gelöscht durch Administrator]
-
Hi
Für den korrekten lauf auf Step7 muß einiges beachtet werden.
Schau doch mal hier: http://www.oscat.de/community/index.php/topic,827.0.html
Möglicherweise lösst das dein Problem.
Gruß
-
Hallo Karl
Danke für die Info, ich habe schon alles berücksichtigt, was in dem Thread beschrieben wurde. War ja selber daran beteiligt!
Gruss
Gregor
-
Hi!
Bitte steige auf die aktuelle release 3.32 um und erneurer den FB64 (STIME neue Version)
Dann sollte es gehen.
WICHTIG:
OB1:
CALL FB64, DB64
Dieser aufruf muss erfolgen!!!
Dann geht Actuator 2P auf jeden Fall.
Gruß Stefan
-
Hallo Stefan
Ich habe bereits den neuen STIME Baustein eingesetzt!! V1.4 Ich habe es extra nochmals verglichen!
Gregor
-
OK, ich werde mir das am Wochenende mal ansehen.
Gruß Stefan
-
Hallo Stefan
Habe heute wieder das gleiche Problem mit dem Actuator! Siehe Anhang!
Konntest du schon schauen?
Gruss und Danke.
Gregor
[gelöscht durch Administrator]
-
Hi!
Leider habe ich es vergessen
Ich schaue es mir gleich heute nachmittag nochmal an.
Wie lange ist denn der Actuator 2P jetzt gelaufen?
-
So, nun habe ich mal zu Testzwecken den Actuator_2P bei mir zuhause am laufen.
Mal sehen, wann er kapituliert.
Mich würde mal folgendes interessieren:
Wenn der Act_2P auf "Störung" geht, und im Feld [pwgen.tx] der Wert ins Negative fällt,
was steht dann im DB64.DBD0 ["IDB_STIME".tx]?
Steht da ebenfalls der gleiche negative Wert?
Sobald mein Act_2P auf Störung geht, werde ich mal nachforschen.
-
Hallo Stefan
Werde mir den Wert beim nächsten Mal im DB64 anschauen. Ich war jetzt 2 Wochen im Urlaub. Aber ich hätte bestimmt gehört wenn es nicht gegangen wäre, somit war der Aussetzter warscheinlich in den letzten Tagen. Wenn ich das mit meinem ersten Posting vergleiche, ist der Actuator etwas mehr wie ein Monat gelaufen!
Gruss
Gregor
-
Welche Hardware setzt du ein?
Was passiert mit den Werten, wenn du die SPS abschaltest (Spannungsausfall und Spannungswiederkehr) und dann wieder neu Starten lässt?
Dann müssten, wenn der FB64, DB64 richtig arbeitet, die Werte wieder bei 0 anfangen zu laufen.
Falls dabei ein Fehler auftritt, beginnt er bei -24d20h31m23s647ms neu zu zählen.
Und somit geht nix mehr.
Teste bitte mal nen Spannungsausfall.
Gruß Stefan
-
Hallo Stefan
Ich setze eine S7-414-3DP ein (414-3XJ04-0AB0). Heute muss ich die CPU sowieso grad wegen einens Garantiefalls von Siemens ersetzten, dann kann ich das mit dem Spannungsausfall mal kontrolieren.
Gruss und Danke
Gregor
-
Hallo Stefan
Der Wert im DB64 fängt richtigerweise wieder bei 0 an zu laufen!
Gruss
Gregor
-
und welcher Zeitwert steht im ACTUATOR_2P?
Identischer Wert wie im DB64?
-
Ja beide Doppelwörter haben den gleichen Wert!
Irgenwie habe ich den Verdacht das es zu einem Überlauf kommt!
Gruss
Gregor
-
Ja, genau das ist auch meine vermutung.
-
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
-
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
-
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
-
Folgend noch ein Printscreen des DB64!
[gelöscht durch Administrator]
-
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
-
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
-
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]
-
Danke,
ich werde den Baustein nun ausgiebig testen
Gruß Stefan
-
Danke Daniel!
Habe den Baustein gestern korrigiert! Werde es weiter im Auge behalten.
Gruss
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]
-
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
-
Hallo Stefan
Konntest du den Baustein schon korrigieren?
Gruss und Danke
Gregor