oscat.lib > oscat.lib fuer Step 7

CLK_PRG: fehlerhafter Startwert

<< < (2/3) > >>

psyche:
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.


--- Code: ---IF #Q OR NOT "IDB_STIME".init THEN #last := #tx; END_IF;
--- Ende Code ---

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 :


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

-----


--- Code: ---"IDB_STIME"();
#tx := "IDB_STIME".tx;
--- Ende Code ---

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 :


--- Code: ---IF #Q OR #tx - #last < T#0ms THEN #last := #tx; END_IF;
--- Ende Code ---

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

mg:
Hallo Psyche

Danke für Deine Antworten. Ich habe die Änderung deshalb so ausgeführt, weil ich irgendwie gemerkt habe, daß sich die CLK_PRG nach kurzer Zeit bei einer CPU315 verrechnet. Ich habe weiters erkannt, daß CLK_PRG einen ähnlichen Inhalt wie die S5_TIME hat. Erst hatte ich die CLK_PRG so verändern wollen, daß die Änderungen von der S5_TIME in die CLK_PRG einfließen aber das habe ich gleich mal den ganzen Betrieb stillgelegt. Dann habe ich mir die Teile von der S5_Time_V1.5 nochmals angeschaut (die funktioniert bei mir) und erkannt, daß ich die "neue" S5_Time_V1.5 als Funktion in die CLK_PRG einbinden kann. Leider ist es einmal zu dem obigen Effekt gekommen, daß die CLK_Prg nach einem erneuten Änderungsdownload (bin zumindest "nach 3 Monaten" der Meinung daß es nur ein Änderungsdownlaod war) zu einem Fehler der CLK_Prg kam. Deshalb setzte ich die Werte bei einem solchen Fehler einfach gleich. Ich verwende die CLK_PRG in Zusammenhang mit der PWM_DC. Ich weiß nicht wo die CLK_PRG sonst noch verwendet wird. Zumindest in diesem Zusammenhang funktioniert das Ganze mal bis jetzt. Leider taucht der Fehler NUR im Sommer auf. Im Winter braucht die Steuerung den PWM_DC nicht.

Ich bin über jeden Kommentar froh. DANKE !!!

Mg

psyche:
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

mg:
Hallo Psyche

a) Ja STime
b) siehe Anhang
c) PWM_DC: Da gibt es viele Anwendungen dafür. In diesem Fall verwende ich es zum leistungsmäßigen Takten eines Befeuchterventilsventils für die Zusatzkühlungkühlung eines Tischkühlers (Außeneinheit). Aber auch die meisten Elektroheizungen werden so leistungsmäßig geregelt.

Die CLK_PRG Probleme gibt es nur bei der S7-315. Bei der 1500er funktioniert die erstaunlicherweise.

So nun noch was zu mir selbst, damit Du über meine Ahnungslosigkeit Bescheid weißt:  ... ich bin mit der S7 zwangsbeglückt worden (bin eigentlich aus der Prozeßtechnik). Und ich machte bis vor 2 Jahren keine S7-Steuerungen. Aber alles ändert sich mal. Wir schreiben mit der S7 eigentlich NUR Prozeßkälteanlagen und neuerdings mache ich ein bischen Lüftung dazu (und M-Bus wurde auch schon entwickelt). Ich habe meine Software natürlich nun so aufgebaut wie ich das aus der Codesys-Welt kenne (Leider geht bei der S7 der CFC noch nicht ... da muß ich mich halt mit dem FUP abfinden, aber das geht auch, wenn auch die Übersichtlichkeit stark darunter leidet). Also die ganzen OB's, DB's usw. sind mir kaum vertraut und nicht will sie auch nicht verwenden sonst schreibe ich alles im SCL. Natürlich wollte ich viele meiner eigenen Bausteine aus dem Codesys verwenden (ging auch erstaunlich gut). Inzwischen haben wir schon eine ganz gute (interne) LIB für die Siemens S7. Mein EINZIGSTER OB ist immer noch der OB1. Alles andere wird ausprogrammiert. Somit bin ich als Entwickler für das Zeugs VÖLLIG daneben. Trotzdem funktionieren bereits 4 Anlagen PERFEKT! Ich werde das System wie ich es bisher gemacht habe auch so beibehalten. Ich habe auch bereits mit mehreren ORIGINAL-SIEMENS-Programmierern darüber gesprochen und die haben mir auch zu nichts anderem geraten.

Mit besten Dank

Mg

[gelöscht durch Administrator]

psyche:
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 :


--- Code: --- "IDB_STIME"();
#tx := "IDB_STIME".tx;
--- Ende Code ---

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.


--- Code: --- IF #Q OR NOT "IDB_STIME".init THEN #last := #tx; END_IF;
--- Ende Code ---

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 :

--- Code: ---IF #Q OR #tx - #last < T#0ms THEN #last := #tx; END_IF;
--- Ende Code ---
Das verhindert das sich der Baustein "aufhängt". Obwohl das eigentlichgar nicht passieren sollte.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete