Sekundentakt ermitteln

mitchih

Level-2
Beiträge
806
Reaktionspunkte
32
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich muss jeweils Sekundenweise einen Wert hochzählen. (Zeit)
Diese wird dann zyklisch von einem PC ausgelesen. Es handelt sich um Verfahrensparameter.

Da die Zeiten als DINT vorliegen scheidet meines Wissene eine Benutzung von Timern aus. Ich habe daraufhin erstmal den Sekunden Blinktakt genommmen. Leider musste ich festtsellen, das dieser zu ungenaus ist. Ungenauigkeit ca. 10s auf 3 min. Da dies nicht akzeptabel ist wollte ich mir eine Flanke aus der CPU Zeit erzeugen, Leider komme ich dabei nicht so wirklich weiter. Ich weiß nicht wie ich die Zeit zerlegen soll. Datum und Tag etc.. bekomme ich ausgelesen, nur bei der Zeit bekam ich irgendwas mit Millisekunden.

Weiteres Problem ist, das das Programm Zyklisch durch den OB35 aufgrund einer Reglerfunktionalität unterbrochen wird.

Hat jemand eine Idee wie mann soetwas elegant lösen kann??

mfg
mitchih
 
Weiteres Problem ist, das das Programm Zyklisch durch den OB35 aufgrund einer Reglerfunktionalität unterbrochen wird.

Hat jemand eine Idee wie mann soetwas elegant lösen kann??

nutze doch den ob35 ... einen zähler inkrementieren und je nach aufrufhäufigkeit dann den wert hochzählen und den anderen zähler zurücksetzen...

bei 10ms müßteste dann bis 100 zählen und dann zuschlagen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Universallösung

Hallo,
wenn es bei dieser Anlage läuft soll es an anderen Anlagen auch erweitert werden. Diese nutzen aber den OB35 für z.B. andere Zwecke und mit anderen Zyklen.
Daher war meine Idee mit der Uhrzeit, denn diese ist ja immer identisch, d.h. ich hätte einen Baustein für alle Anlagen. Wäre erheblich einfacher.

Trotzdem ist das mit dem OB35 eine gute Idee
 
Was hindert Dich daran, die Millisekunden durch 1000 zu teilen.
Den Wert merken, und wenn er sich ändert ist eine Sekunde vorbei.

Vielleicht etwas zu einfach?
 
Was hindert Dich daran, die Millisekunden durch 1000 zu teilen.
Den Wert merken, und wenn er sich ändert ist eine Sekunde vorbei.

Vielleicht etwas zu einfach?

Nun ja, die Lösung, einen zeitzyklisch- aufgerufenen OB zu verwenden hat den Vorteil, dass es keine Zeitsprünge gibt, wenn, z.B. die CPU-Uhr gestellt wird.

Ich finde beide Varianten einfach zu realisieren - da muss man halt nur das Passende wählen :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich muss jeweils Sekundenweise einen Wert hochzählen. (Zeit)
Diese wird dann zyklisch von einem PC ausgelesen. Es handelt sich um Verfahrensparameter.

Da die Zeiten als DINT vorliegen scheidet meines Wissene eine Benutzung von Timern aus. Ich habe daraufhin erstmal den Sekunden Blinktakt genommmen. Leider musste ich festtsellen, das dieser zu ungenaus ist. Ungenauigkeit ca. 10s auf 3 min.

Der Sekundentakt der CPU hat die gleiche Genauigkeit wie die Uhrzeit der CPU. (wenige Sekunden /Tag)
Bei einer derart großen Abweichung scheint irgendwo ein Fehler zu sein.
 
nimm doch einen iec timer
eine SE wird mit sfb4 gemacht.

der datentyp TIME der verwendet wird ist nix anderes als ein dint mit ms auflösung.

also eifach durch 100 teilen und in deine variable transferieren.

dein 10s abweichung kommen durch die zykluszeit der sps. da hilft nur der ob35 oder das aufaddieren der tatsächlichen zykluszeit des ob1 (in den lokaldaten von ob1) und bei jedem überlauf über 1000ms den dint erhöhen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ja eben die zykluszeit die immer mitaddiert wird!

da würde ich noch mal drüber nachdenken.:ROFLMAO:

die zeit zwischen zwei sekundentakten beträgt genau eine sekunde egal wann du den takt in deinem programm erfasst.
du erfasst in nur ein paar ms später aber deswegen verlängert sich doch nicht die zeit des taktes.
ich habe mal nur so zum testen mit dem sekundentakt eine uhr realisiert.
die lief auch nach wochen absolut synchron zur uhrzeit der cpu.

auch sonst habe ich schon viel mit den taktmerkern gemacht.
 
da würde ich noch mal drüber nachdenken.:ROFLMAO:

denke lieber du nochmal darüber nach... :rolleyes:

die zeit zwischen zwei sekundentakten ist nämlich "exakt" 2s

die taktmerler sind 1s TRUE und dann 1s FALSE und 1s TRUE...

deinn programm hat also jedesmal eine sekunde Zeit die positive Flanke auszuwerten, und die Zeit die die Zykluszeit in dieses Sekundenfenster kommt, wird als Fehler mit aufaddiert...
 
Wenn die Zyklus-Zeit zu der normalen CPU-Zeit dazuaddiert wird dann müßte ja jede CPU eine ganz andere Zeitrechnung haben und keine ginge auch nur annähernd richtig.

Oder sehe ich das jetzt falsch?:confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur mal so am Rande:

Wenn nebenbei noch Kommunikation betrieben wird (Ist bei Ihm ja der Fall DV mit PC) wird der OB35 auch nicht mehr perfekt genau aufgerufen.
Bei einem Aufrufintervall von 10ms kann da schon mal ein Fehler von 1ms auftauchen (bei einer 315-2 DP z.B.) Da kommt auf die Dauer schon mal was zusammen.
 
denke lieber du nochmal darüber nach... :rolleyes:

die zeit zwischen zwei sekundentakten ist nämlich "exakt" 2s

die taktmerler sind 1s TRUE und dann 1s FALSE und 1s TRUE...

deinn programm hat also jedesmal eine sekunde Zeit die positive Flanke auszuwerten, und die Zeit die die Zykluszeit in dieses Sekundenfenster kommt, wird als Fehler mit aufaddiert...

Taktmerker Mx.5 = 1Hz --> 0.5s true / 0.5s False
d.h. jede sekunde eine positive flanke.
wann ich das nun auswerte ist doch scheiss egal.
wenn ich es erst 50ms später mache dann sind es bis zur nächsten flanke nur noch 950ms.

probiere es doch einfach mal aus
ich habe 500ms zeit die flanke zu erfassen.
brauche ich länger (unwahrscheinlich) dann wird es ungenau.
fakt: der x0.5 geht jede sekunde auf true.
ich schaue vom programm aus eben nur ein bischen später drauf,
daß ändert aber nix an der taktfrequenz des Mx.5.
wenn du nicht ständig auf deine armbanduhr schaust geht sie doch deswegen auch nicht ungenau.
 
MarkusZitat:
Zitat von crash
Der Sekundentakt der CPU hat die gleiche Genauigkeit wie die Uhrzeit der CPU. (wenige Sekunden /Tag)
Bei einer derart großen Abweichung scheint irgendwo ein Fehler zu sein.

ja eben die zykluszeit die immer mitaddiert wird!



Wie oft muß ich denn die Zykluszeit innerhalb einer Sekunde dazuzählen? 1x, 2x...:confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Taktmerker Mx.5 = 1Hz --> 0.5s true / 0.5s False
d.h. jede sekunde eine positive flanke.
wann ich das nun auswerte ist doch scheiss egal.
wenn ich es erst 50ms später mache dann sind es bis zur nächsten flanke nur noch 950ms.

probiere es doch einfach mal aus
ich habe 500ms zeit die flanke zu erfassen.
brauche ich länger (unwahrscheinlich) dann wird es ungenau.
fakt: der x0.5 geht jede sekunde auf true.
ich schaue vom programm aus eben nur ein bischen später drauf,
daß ändert aber nix an der taktfrequenz des Mx.5.
wenn du nicht ständig auf deine armbanduhr schaust geht sie doch deswegen auch nicht ungenau.

Wo er Recht hat, hat er Recht !

Der Erfassungsfehler ist ein absoluter Fehler!
 
können wir bitte noch mal auf die möglichkeit der OB35-nutzung zurückkommen?

auch wenn der zu programmierende baustein in vielen steuerungen zum einsatz kommen soll, würde ich diese möglichkeit in betracht ziehen. wie schwer kann es denn sein, die aufrufhäufigkeit (den zählwert) an der schnittstelle des bausteins anzugeben? - siehste ...

und das der ob35 durch kommunikation beeinflußt wird ist mir neu. kann das mal einer belegen? ich habe diese beobachtungen noch nicht gemacht und würde vorerst behaupten: diese aussage ist kokolores! :rolleyes:
 
nana, wer wird denn gleich in die Luft gehen....

Anbei ein Siemens Paper wo Du das nachlesen kannst.

nana, in die luft gehen ist anders ;)

danke für das siemens-paper ... und hier nochmal für alle zum mitlesen:

Vom Auftreten des Weckalarms bis zur Bearbeitung der ersten STEP7-
Anweisung im Weckalarm-OB vergeht eine gewisse Zeit. Die Gründe da
sind:
• Bei jeder Unterbrechung des OB1 rettet das Betriebssystem der
S7-CPU die Inhalte der Akkumulatoren.
• In der S7-CPU sind gerade nicht unterbrechbare Betriebssystem-
Routinen aktiv.

Wenn ein Aufruf des Weckalarm-OB verzögert wird, steuert das Betriebs-
system der S7-CPU dagegen und verkürzt die Zeit bis zum nächsten Aufruf
des Weckalarm-OB. Durch diesen Mechanismus gewährleistet das Be-
triebssystem, dass der Mittelwert der Zeitabstände genau der projektierten
Aufrufzeit entspricht.

Die Verzögerung des Aufrufes des Weckalarm-OBs hat unterschiedliche
Ursachen:
Verzögerung durch das Betriebssystem der S7-CPU:
• Umschaltzeit vom aktuellen OB auf den Weckalarm-OB
• Laufende PG-Testfunktionen (Status/Steuern)

Verzögerung durch die Kommunikation der S7-CPU:
• PG-Kommunikation
• PG-Routing
• OP-Kommunikation
• Kommunikation über Subnetze unter Verwendung von CPs

Verzögerung durch das Anwenderprogramm der S7-CPU:
• Verwendung des Kopierbefehls SFC81 (UBLKMOV)
• Verwendung von höherprioren OBs
• Sperren des Weckalarm-OBs durch den SFC39

aber liegt das dann schon im ms-bereich? und: dieser fehler wird nicht addiert, da die zeit bis zum nächsten weckalarm ja verkürzt wird ... eine ms bei einer sekunde entspricht übrigens 1‰ :rolleyes:
 
Danke an Grubba ...

ja, da in Kapitel 5 stehen ein paar Infos, die mir persönlich dringend davon abraten, jemals diesen OB35 für was echtzeitfähiges einzusetzen.
 
Zurück
Oben