oscat.lib > oscat.lib fuer Step 7
CLK_PRG: fehlerhafter Startwert
mg:
Hallo Leute
Programmiersystem: TIA12 SCL
Controller: CPU315
Baustein im Oscat: CLK_PRG
Nach einem Änderungsdownload wurden alle (od. viele, das kann ich im nachhinein nicht mehr sagen) Baugruppen gestoppt und neu gestartet.
Danach stand der Wert für "last" auf einem niedrigen negativen Wert (3-stellig), aber der Wert für "tx" irgendwo im x-stelligen negativen Bereich (-24Tage und noch ein bischen was).
Der PWM_DC rechnet aus der Differenz der beiden eine Zeit aus die dem Taktzyklus entsprechen sollte. Das würde heißen, daß der PWM_DC dieser Wert in meinem Fall erst in 24 Tagen korrekt funktioniert.
Die Initialisierung des CLK_PRG hat offensichtlich NICHT funktioniert.
Es wäre schön, wenn man in einem der folgenden Updates auch diesen Fehler mal eliminieren könnte.
Vielen Dank
Mario
Omalik:
Hallo Mario
Hast du schon was herausgefunden? Habe auch Probleme mit dem CLK_PRG Baustein. Er macht nicht das was ich erwarte.
Gruss
mg:
Naja ich habe schon was rausgefunden.
In der STIME_V1_5 wird ein ähnliches Verfahren verwendet. Das war anscheinend ein großes Problem dort.
ABER: ... da mir die Erklärung dieses Bausteins zu sparsam ist, kann ich den CLK_PRG zwar auf das selbe System ändern, aber was dort drinnen wirklich 100%tig passiert, ist mir noch nicht bis ins letzte Detail bekannt UND solange bleibt das für mich eine Problem.
Obs funktioniert weiß ich auch nicht, ... evtl weiß jemand wie ich das am besten testen soll!
Mario
HIER WÄRE EINE HILFE VON GKOBLER ODER DALBI HILFREICH.
mg:
Hallo Leute
... die Entwickler :-X (eigentlich traurig)
Ich habe das nun selber probiert. Aber ich habe leider keine Station zum Probieren zu hause (muß das immer bei einer in Betrieb befindlichen SPS über VPN machen und dabei stelle ich bei einem Fehler u.U. gleich einen ganzen Betrieb ab!!!)
Trotzdem konnte ich nicht mehr länger warten und testete mal an dem ganzen Zeugs rum. Im Endeffekt habe ich das folgendermaßen gemacht ...
Die folgende Änderung sollte meiner Meinung funktionieren aber das Ganze kann ich erst nach 18 weiteren Tagen sagen (dann kommt es zum nächsten Überlauf)
So lange ist das Zeugs noch ungetestet!
--- Code: ---(* // START -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
(* 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);
(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));
(* reset last_time on system startup *)
IF #TOP_SI.EV_NUM = 1 OR #TOP_SI.EV_NUM = 2 OR #TOP_SI.EV_NUM = 4 THEN
#init := false;
END_IF;
(* initialize on startup *)
IF NOT #init THEN
#init := TRUE;
#last := #tx - #PT;
END_IF;
*)
// ENDE -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
// und wird ersetzt durchf die folgenden 2 Zeilen *)
"IDB_STIME"();
#tx := "IDB_STIME".tx;
(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)
(* generate output pulse when next_pulse is reached *)
#Q := #tx - #last >= #PT;
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
mg 5. aug. 2014 rev 1.4
problem with the internal-time variable after the overflow
*)
--- Ende Code ---
mg:
noch eine Änderung
Nach einem Download kann es sein, daß die Initialisierung nicht funktioniert .... deshalb folgende Änderung
--- Code: ---(* // START -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
(* 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);
(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));
(* reset last_time on system startup *)
IF #TOP_SI.EV_NUM = 1 OR #TOP_SI.EV_NUM = 2 OR #TOP_SI.EV_NUM = 4 THEN
#init := false;
END_IF;
(* initialize on startup *)
IF NOT #init THEN
#init := TRUE;
#last := #tx - #PT;
END_IF;
*)
// ENDE -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
// und wird ersetzt durchf die folgenden 2 Zeilen *)
"IDB_STIME"();
#tx := "IDB_STIME".tx;
(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)
(* generate output pulse when next_pulse is reached *)
#Q := #tx - #last >= #PT;
IF #Q OR NOT "IDB_STIME".init 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
mg 5. aug. 2014 rev 1.4
problem with the internal-time variable after the overflow
mg 18. aug. 2014 rev 1.4a
INIT after download/restart
*)
--- Ende Code ---
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln