# Weihnachtsrätsel 2020 - Vorschläge



## Onkel Dagobert (6 Dezember 2020)

Auch in diesem Jahr wird wieder Weihnachten sein.

Mit welchen pfiffigen Standardfunktionen habt ihr denn in den letzten Monaten eure persönliche Bibliothek bereichert? Es sollte etwas sein, was jeder brauchen kann, nichts Exotisches. Am Besten so etwas mit dem gewissen "Wow-Effekt". Jemand eine Idee?


09.12.2020 - 18:30 bisherige Vorschläge:



#03 - Wochenschaltuhr - ADS_0x1
#04 - Blinktakt synchron über LTE - vollmi
#05 - Pferdestall, Stroheinstreu - ADS_0x1
#09 - Paketierungs-Challenge (Binpacking) - Thomas_v2.1 --> hat abgesagt, da Aufgabe zu komplex
#13 - Getreide-Silos - Chräshe


----------



## Tommi (6 Dezember 2020)

> was jeder brauchen kann, und dann noch mit nem WOW Effekt


da muss ich (zunächst) passen...


----------



## ADS_0x1 (7 Dezember 2020)

Ich weiß nicht, ob das (für Könner) eventuell zu einfach ist, aber ich habe unsere "Jungen" an folgender Aufgabe verzweifeln lassen:



> Wir programmieren eine Wochenschaltuhr:Für alle 7 Tage der Woche (zählt nach, es sind wirklich sieben!) kann der Benutzer bis zu n_AnzahlSchaltpunkteJeTag festlegen, an denen für eine Zeit n_DauerSignal ein Ausgang gesetzt wird. Wird ein Schaltpunkt nicht benötigt, ist für diesen die Dauer von 0 Sekunden eingetragen. Die minimale Einschaltdauer beträgt 5 Sekunden.
> 
> 
> Bildlich gesprochen:
> ...


----------



## vollmi (7 Dezember 2020)

Ich hab da vielleicht was nettes Kleines. 
Anforderung ist ein verstellbarer Blinktakt ein/aus zeit gleichmässig (0.1 - 5 Hz). Aber der Takt soll auf allen SPSen möglichst synchron laufen, ohne dass diese eine Kommunikations- oder IOverbindung untereinander haben.

Anforderung kommt aus dem Strassenverkehr, wenn über eine gerade Fahrbahn Signalbrücken gespannt sind und man 10 Signalbrücken sieht an denen eine Ampel oder ein Abweisepfeil blinkt, sollen diese Synchron blinken. an jeder Signalbrücke ist eine CPU montiert die ihre Befehle über ein LTE Modem bekommt. Kann aber auch auf Anlagen sinnvoll sein wo man z.B. die alarmlampen von verschiedenen Schaltschränken gleichmässig blinken lassen will.

Wer soll die Lösung kriegen? Oder wollen wir einfach mal die Ansätze vergleichen?
Ist jetzt ne simple funktion aber kurzes Nachdenken wird sie schon erfordern. Und es gibt ja dann noch erschwernisse die man einbauen könnte. Was ist wenn Puls/Pause unterschiedliche Längen haben sollen?


----------



## ADS_0x1 (7 Dezember 2020)

Ich hab das noch etwas im Repertoire, das ist mit eingefallen, als ich vollmi's Beitrag gesehen habe (nicht wegen des Beitrags, aber wegen vollmi):

In einem Pferdestall stehen 41 Boxen, auf zwei Seiten des Stalls verteilt. Über diesen Boxen läuft ein Rohrkettenförderer, der Stroheinstreu zu den Boxen bringen soll. Generell läuft der Förderer zu zwei fest eingestellten Zeiten am Tag.

Über den Boxen an den Rohren befinden sich Zylinder, die einen Auslass des Strohs für die Box öffnen und schließen können. 
Ob der Zylinder zu den beiden Zeiten aufgeht, hängt davon ab, ob die Box belegt ist oder nicht.
Wie lange der Zylinder aufgeht, ist je Box einstellbar. 
Über die Summe der Öffnungszeiten kann indirekt auf den Strohverbrauch je Box ein Rückschluss gezogen werden. 

Problematisch bei der Programmierung war / ist:
- Die Boxen haben prinzipiell alle den gleichen Abstand zueinander, allerdings gibt es eine Schleuse in der Mitte, sodass der Abstand von der einen zur anderen Box doppelt so groß ist. Weiterhin muss oben am Ende des Stalls umgelenkt werden, sodass hier ebenfalls ein größerer Abstand von angenommen dem doppelten Abstand entsteht
- Es soll möglichst wenig Stroh zurück in den Bunker gefahren werden
- Die Nummerierung der Boxen anders ist, als die Reihenfolge der Boxen am Strohförderer
- Der Vereinfachung halber nehmen wir an, dass der Motor sofort anläuft und sofort stoppt, wenn er ein Signal bekommt / nicht bekommt und das immer die gleiche Menge Stroh vom Bunker in den Förderer fällt (das ist der Part, an dem ich gerade in der Inbetriebnahme hänge - da ist es nämlich anders...)

Da ein Bild mehr als tausend Worte sagt:




(Da das ganze matschig ausschaut, hier noch einmal als PDF
Anhang anzeigen Strohfoerderer.pdf


Viele Grüße!


----------



## Onkel Dagobert (7 Dezember 2020)

vollmi schrieb:


> .. Wer soll die Lösung kriegen? Oder wollen wir einfach mal die Ansätze vergleichen? ..


Ich würde sagen, wir warten mal bis zum Ende der Woche, vielleicht bis Sonntagabend? Es soll ja möglichst jeder Gelegenheit haben, teilzunehmen. Vielleicht hat Tommy auch noch eine Idee zu einer kleinen, feinen Funktion? Wenn es Sinn macht, können wir dann abstimmen. Und wenn es zwei oder drei Rätsel werden ist es doch eigentlich auch ok, oder?

Andererseits könntet ihr aber auch einfach loslegen, ihr seid ja alt genug, denke ich. Wegen der Übersichtlichkeit bitte in separaten Threads.

Die Sache mit den Pferdeboxen wäre mir persönlich eigentlich schon zu speziell und zu umfangreich. Aber vielleicht gibt es ja auch hierfür Interessenten.


----------



## Blockmove (7 Dezember 2020)

@ADS01
Gibt's da irgendeine Schleuse am Bunker oder tansporiert der Kettenförderer während der gesamten Laufzeit aus dem Bunker?


----------



## Thomas_v2.1 (7 Dezember 2020)

Also ich rätsele lieber an etwas sinnvollen Unsinnvollen, was man so niemals als Aufgabenstellung bekommt, und 'n bißchen Knobeln und um die Ecke denken dabei ist.
Ist aber gar nicht so einfach sich da was auszudenken, ich hatte letztes Jahr auch schon keine zündende Idee.


----------



## Thomas_v2.1 (7 Dezember 2020)

Ansonsten wäre vielleicht so eine kleine Paketierungs-Challenge (Binpacking) noch etwas um die grauen Zellen etwas herauszufordern. Vielleicht einschränken auf welche Pakete kommen können, und dann muss jeder seinen Algorithmus auf die Testserie einmalig loslassen und der beste Algorithmus gewinnt.


----------



## PN/DP (7 Dezember 2020)

vollmi schrieb:


> Anforderung ist ein verstellbarer Blinktakt ein/aus zeit gleichmässig (0.1 - 5 Hz). Aber der Takt soll auf allen SPSen möglichst synchron laufen, ohne dass diese eine Kommunikations- oder IOverbindung untereinander haben.


Den Blinktakt von 0.1 Hz bis 5.0 Hz in Stufen von 0.1 Hz einstellbar? Oder nur ein paar wenige verschiedene Takte?
Ich würde irgendwie den Blinktakt mit der Systemuhr synchronisieren, wenn die (NTP-)synchronisiert ist? TOD aus der Uhrzeit holen und mit den Millisekunden die Puls- und Pausenlängen des Blinktaktes abmessen, und alle 5 oder 10 Sekunden (exakt bei hh:mm:00, :05, :10, .. :55) die Blinktakt-Erzeugung neu triggern.
Ich schätze mal, bis 50 ms Zeitunterschied sieht man keinen Blink-Unterschied?

Harald


----------



## ADS_0x1 (7 Dezember 2020)

Blockmove schrieb:


> @ADS01
> Gibt's da irgendeine Schleuse am Bunker oder tansporiert der Kettenförderer während der gesamten Laufzeit aus dem Bunker?



Für die Aufgabe: Nein. Sobald der Förderer los fährt, ist Stroh drin. 

In Realität sitzen über dem Rohrkettenförderer noch zwei Rührwerke und ein Schneckenantrieb, der das Stroh über einen Einlaufschlitz "verteilt". Weiterhin sind zwei Sensoren vorhanden, die einmal melden "Stroh Tagespuffer erreicht", sowie ein weiteres Mal ein Leerlaufen verhindert wird. 

Für die Aufgabe sage ich aber: Der Strohbunker ist unendlich voll und der Füllgrad des Rohrkettenförderers ist immer konstant.

Befinde mich wie gesagt noch bei der Inbetriebnahme der "Spezialfälle", die ich für die Aufgabe weggelassen habe. 

Geht das denn jetzt schon mit dem programmieren los? Dann muss ich mal schauen, dass ich meinen "Lösungsvorschlag" wieder so herunterbreche, dass das auf die Aufgabenstellung passt  

Ihr habt aber Recht: Das ist schon sehr speziell. Aber allein darauf herumzudenken, wie wann wo welche Klappe und so gefahren wird ... ich fand es ganz schön sportlich. Weiterhin kam dann noch hinzu, dass das alles auf einer 1212C mit 75 kByte Arbeitsspeicher läuft, somit Quasi alleine schon mehrere Timer für die Boxen parallel entfallen - aber auch das möchte ich nicht Teil der Aufgabe werden lassen!


----------



## vollmi (7 Dezember 2020)

PN/DP schrieb:


> Den Blinktakt von 0.1 Hz bis 5.0 Hz in Stufen von 0.1 Hz einstellbar? Oder nur ein paar wenige verschiedene Takte?
> Ich würde irgendwie den Blinktakt mit der Systemuhr synchronisieren, wenn die (NTP-)synchronisiert ist? TOD aus der Uhrzeit holen und mit den Millisekunden die Puls- und Pausenlängen des Blinktaktes abmessen, und alle 5 oder 10 Sekunden (exakt bei hh:mm:Erzeugung neu triggern.
> Ich schätze mal, bis 50 ms Zeitunterschied sieht man keinen Blink-Unterschied?



ich denke 0.1 hz auflösung und 70ms Differenz inklusive dem sps zyklus ist okay.


----------



## Chräshe (8 Dezember 2020)

Onkel Dagobert schrieb:


> Jemand eine Idee?



Mehrere Getreide-Silos werden durch einblasen befüllt. Es existiert nur eine gemeinsame Einblasvorrichtung. Das gewünschte Silo wird durch Weichen vorgewählt.
Aufgrund von Verscheiß versagen die Weichen in unregelmäßigen Abständen. Dann kann es sein, dass 2 Silos parallel befüllt werden, was zu unerwünschten Vermischungen führt. Eine Silo-Überwachung soll das frühzeitig erkennen und melden.

Silo-Überwachungs-Funktion:
Jedes Silo verfügt über eine Füllstandmessung 0-100%.
Der Füllstand muss langsam wachsen (>0,6% /min), wenn die Beschickung aktiv ist.
Der Füllstand muss langsam sinken (>1,7% /min), wenn der Abzug aktiv ist.
Wenn sich der Füllstand ändert, während am Silo weder eine Beschickung, noch ein Abzug aktiv ist, soll das ebenfalls registriert werden.
Der Sonderfall, dass das Silo gleichzeitig beschickt und abgezogen wird, soll auch möglich sein.


----------



## Kabeläffle (9 Dezember 2020)

Chräshe schrieb:


> Mehrere Getreide-Silos werden durch einblasen befüllt. Es existiert nur eine gemeinsame Einblasvorrichtung. Das gewünschte Silo wird durch Weichen vorgewählt.
> Aufgrund von Verscheiß versagen die Weichen in unregelmäßigen Abständen. Dann kann es sein, dass 2 Silos parallel befüllt werden, was zu unerwünschten Vermischungen führt. Eine Silo-Überwachung soll das frühzeitig erkennen und melden.
> 
> Silo-Überwachungs-Funktion:
> ...



Zusatzaufgabe:
Durch Brückenbildung oder Schachtbildung kommt es vor, dass der Füllstand in kurzer Zeit stark „springt“. Das ist in die positive Richtung, als auch in die negative Richtung möglich.
Sprünge im Füllstand von >7% innerhalb 10 Sekunden, sollen als Fehler erkannt und gemeldet werden.  Die Meldung soll mit Betrag und Richtung erfolgen.


----------



## Onkel Dagobert (9 Dezember 2020)

Da sind doch schon ein paar ganz brauchbare Ideen dabei. Denkt bitte daran, dass ihr ggf. eine sehr eindeutige Aufgabenstellung formulieren müsst, falls ihr den Zuschlag erhaltet. Es gibt in diesem Forum einige penible Mitglieder, die erfahrungsgemäß sehr akribisch die Aufgabenstellung in alle Einzelteile zerlegen und alle Eventualitäten der Aufgabe hinterfragen. Das kann für euch stressig werden. War es im letzten Jahr, als das Weihnachtsrätsel durch so etwas im Sande verlaufen ist?

Ich habe erst einmal alle bisherigen Ideen in #1 aufgelistet.


----------



## Thomas_v2.1 (9 Dezember 2020)

2019 gab es doch gar kein Rätsel, oder? Davor war das ja ein Nach-Neujahrsrätsel. Die Aufgabenstellung war auch sehr einfach: Durch drei teilen - allerdings nur mit Schiebebefehlen 

Wer sonst noch mal nach-rätseln will:

2016:
Weihnachtsrätsel 2016

2017:
Weihnachtsrätsel 2017

2018:
Nach-Neujahrsrätsel

Zwar etwas abseits vom Weihnachtsrätsel, aber das hat mir selber auch richtig Spaß zu machen zu lösen:
Programmierwettbewerb 6. Aufgabe - Quine in AWL


Ich habe auch noch eine Idee im Köcher die ich aber noch nicht ausgearbeitet habe um zu sehen wie kompliziert das wird. Bzw. an Programmierkenntnissen wird Anfängerniveau ausreichend sein ;-)


----------



## Onkel Dagobert (13 Dezember 2020)

Ich habe aus dem Thema mal eine öffentliche Umfrage über 7 Tage gemacht. Thomas hat mich gebeten, seinen Vorschlag nicht mit auf zu nehmen, da seine Aufgabenstellung sehr komplex ist und dadurch sehr viele Fragen und Diskussionen aufkommen würden.

Dann erst mal viel Spaß beim Abstimmen!


----------



## Onkel Dagobert (18 Dezember 2020)

Meine Damen und Herren,

ein bisschen mehr Begeisterung bitte  !
Das Wahllokal schließt am Sonntag gegen 19:30h.


----------



## Thomas_v2.1 (20 Dezember 2020)

Die Aufgabe müsste vollmi aber noch etwas besser spezifizieren, das hier im Thread lässt doch viel Interpretationsspielraum.


----------



## Onkel Dagobert (20 Dezember 2020)

Das Wahllokal ist geschlossen. Ich würde mal sagen, die Beschlussfähigkeit ist mit 13 Teilnehmern gerade so erreicht worden. Falls jemand das Wahlergebnis anzweifelt, so möge er für immer schweigen!

Vollmi, du bist jetzt systemrelevantester SPSler!
Du weißt ja, was zu tun ist.


----------



## rostiger Nagel (20 Dezember 2020)

Onkel Dagobert schrieb:


> Das Wahllokal ist geschlossen. Ich würde mal sagen, die Beschlussfähigkeit ist mit 13 Teilnehmern gerade so erreicht worden. Falls jemand das Wahlergebnis anzweifelt, so möge er für immer schweigen!
> 
> Vollmi, du bist jetzt systemrelevantester SPSler!
> Du weißt ja, was zu tun ist.



Das sind doch „Fake News“, ich habe gewonnen.
Ich fordere eine erneute Auszählung.
Des Weiteren ziehe ich vor das Forums-Gericht, 
mein Anwalt hat schon Farbe auf sein Haar aufgetragen.
Die Wahl wurde gestohlen!


----------



## hucki (20 Dezember 2020)

rostiger Nagel schrieb:


> Das sind doch „Fake News“, ich habe gewonnen.
> Ich fordere eine erneute Auszählung.
> Des Weiteren ziehe ich vor das Forums-Gericht,
> mein Anwalt hat schon Farbe auf sein Haar aufgetragen.
> Die Wahl wurde gestohlen!


Du könntest vielleicht das Kriegsrecht ausrufen und das Militär eine Neuwahl durchführen lassen...


----------



## vollmi (20 Dezember 2020)

Onkel Dagobert schrieb:


> Vollmi, du bist jetzt systemrelevantester SPSler!
> Du weißt ja, was zu tun ist.



wow. Cool. Als erstes werden wir eine Mauer bauen. 

ich werd mir morgen noch ein paar exaktere Eckdaten heraussuchen. 
verdammt was für eine Verantwortung hab ich mir da aufgehalst?


----------



## Thomas_v2.1 (20 Dezember 2020)

vollmi schrieb:


> ein paar exaktere Eckdaten heraussuchen



Wenn man sich die letzten Rätsel ansieht, ist das schwierigste am Rätsel die Aufgabenstellung 100% wasserdicht zu verfassen ;-)


----------



## Thomas_v2.1 (21 Dezember 2020)

Also ich habe auch noch ein SPS Rätsel geschnitzt bei dem nicht programmiert werden muss, falls jemand sein Werkzeug schon in den Ruhestand geschickt hat ;-)


----------



## Hesse (21 Dezember 2020)

Thomas_v2.1 schrieb:


> .....t, ist das schwierigste am Rätsel die Aufgabenstellung 100% wasserdicht zu verfassen ;-)



  Das müssten Auftraggeber nur mal annähernd hinbekommen mit ihrem Ausschreibugen …


----------



## Thomas_v2.1 (22 Dezember 2020)

Wann geht's denn los? :s11:


----------



## hucki (22 Dezember 2020)

Thomas_v2.1 schrieb:


> Wann geht's denn los? :s11:


Nüschts zu tun?


----------



## Thomas_v2.1 (22 Dezember 2020)

hucki schrieb:


> Nüschts zu tun?



Nicht das eigentlich geplante, im Dezember war mit Mistwetter und Dauerregen aber ja auch nicht zu rechnen ;-)

Weiß ja nicht wie lange vollmi noch braucht, sonst mach ich mal mein kleines Rätselchen rein, das ist auch etwas anders.


----------



## Onkel Dagobert (22 Dezember 2020)

So ganz ohne Abstimmung?
Das geht natürlich auch  .


----------



## Thomas_v2.1 (22 Dezember 2020)

Es besitzt auch keine der von dir geforderten Eigenschaften:
- es ist keine Standardfunktion
- es kann niemand gebrauchen
- es ist womöglich etwas exotisch
- der "Wow"-Effekt ist der gleiche der sich beim Lösen eines Rätsels aus der Apotheken-Rundschau einstellt


----------



## Onkel Dagobert (22 Dezember 2020)

War das die Aufgabenstellung?
Kommt es aus China?


----------



## vollmi (22 Dezember 2020)

*Die Ausgangslage:
*Eine Autobahn 10km Schnurgerade. Alle 300m eine Signalbrücke mit blinkenden Signalen. 
Jede Signalbrücke hat eine SPS welche die Blinker per DA ansteuert. die Blinker blinken nicht synchron und auch nicht gleich schnell. Das irritiert die Autofahrer und hat schon etliche Unfälle ausgelöst. *

So die Aufgabenstellung:*
Gefordert ist ein synchroner Blinktakt auf mehreren SPS sichtbar gemacht über einen digitalen Ausgang mit LED.
Die SPS haben keinen direkten Kontakt zueinander, sind aber am Internet.
Der Blinktakt wird in einer Frequenz (Hz) angegeben. Die Endwerte sind 0.1Hz bis 3Hz. TRUE time und FALSE time sind gleich lang
Ein Drift bis 70ms ist akzeptabel.
Die CPUs verlieren alle zwei Stunden die Internetverbindung für 15Min. der Takt muss dabei Synchron bleiben.

*Gegeben ist. *
3 SPS in verschiedenen nicht näher definierten Ausführungen (z.B. s7-1200, s7-1500, codesysV3). Alle haben eine Internetanbindung.

Es dürfen keine Timer oder statische Variablen für den Aufbau des Taktes verwendet werden.
Ziel ist eine Funktion für den Takt mit maximal einem Eingang als Basisdatentyp (dint, int, udint etc.), neben dem basisdatentyp für die sollfrequenz und einen rückgabewert als Bool (der Takt). Bitte nicht bescheissen indem ihr einen DINT eingebt mit 0101 Takt der vorgängig irgendwie generiert wurde.

*Synchronisationstests:*
Ich kann zum Testen eine S7-1510sp S7-1212 ein Raspberrypi mit CodesysV3 Softplc bieten. Plus ein Logikanalyzer. 
Bei abgefahrenen CPUs wäre ich froh wenn dieser der diese benutzt auch mindestens einen Logikanalyzer anhängen könnte um die Zeitabstände der steigenden und fallenden Flanke zu messen.

edit: kleine Vorgabe zur Funktion hinzugefügt.


----------



## Thomas_v2.1 (23 Dezember 2020)

Zweizeiler?


----------



## vollmi (23 Dezember 2020)

Thomas_v2.1 schrieb:


> Zweizeiler?



Kriegt man in scl hin. Wird aber nicht sehr übersichtlich. Man kann in scl ja ziemlich viel auf eine Zeile mosten. 

ich würde vorschlagen wird gehen den Weg an und die Probleme die sich zeigen werden. 
durch Wegnahme von Timern und stats hab ich den Weg schon ziemlich vorgegeben. 
wenn ich IFThen oder case ebenfalls entferne wirds für manche sehr (zu) anspruchsvoll.  
ausserdem wollte ich die Sprachen offen lassen, denke aber, wenn mans nach codesys bringen will. AWL eine schlechte Wahl ist. 

aber so anspruchsvoll wie deine Rätsel ist es sicherlich nicht, das krieg ich nicht hin. Ich hoffe trotzdem es gibt dem einen oder andern eine Knacknuss.


----------



## Onkel Dagobert (23 Dezember 2020)

Genügt es, wenn es auf einer der genannten Steuerungen läuft?
Müssen wir es testen, oder genügt ein Baustein und ggf. eine zusätzliche Bemerkung?
Wie sollen wir mit der Lösung verfahren? Dir zuschicken?


----------



## de vliegende hollander (23 Dezember 2020)

vollmi schrieb:


> Es dürfen keine Timer oder *statische Variablen* für den Aufbau des Taktes verwendet werden.



Globale Datenbaustein oder sogar Merker darf?


----------



## vollmi (23 Dezember 2020)

Onkel Dagobert schrieb:


> Genügt es, wenn es auf einer der genannten Steuerungen läuft?
> Müssen wir es testen, oder genügt ein Baustein und ggf. eine zusätzliche Bemerkung?
> Wie sollen wir mit der Lösung verfahren? Dir zuschicken?



es soll schon auf allen Steuerungen einfach übertragbar sein. Darum die drei Steuerungen. Ich wollte damit vermeiden das wir unnötige proprietäre Befehle verwenden (slice). 

Wie wollt ihr mit den Lösungen verfahren. Ich weiss, dass die üblichen Pro‘s eh schon alles fertig und optimiert haben. Hatte allerdings gehofft, da die Aufgabe nicht übermässig schwer ist und man schnell erste Ergebnisse erzielen kann, vielleicht auch ein paar nicht so versierte Coder mitmachen, und wir zusammen die Basis diskutieren und weiterentwickeln.


----------



## vollmi (23 Dezember 2020)

de vliegende hollander schrieb:


> Globale Datenbaustein oder sogar Merker darf?



nein nix was über den Zyklus gespeichert wird. Also nur für den Taktgenerator. Wenn ihr bei einer CPU eine Kommunikation  aufbauen müsst um Grundlagen zu schaffen, wird man nicht auf n biblotheksbaustein verzichten können.
ich hab die Vorgabe noch etwas verfeinert.


----------



## Thomas_v2.1 (23 Dezember 2020)

Dann können anschließend alle die das Rätsel gelöst haben, ihre Weihnachtsbeleuchtung synchron blinken lassen :TOOL:


----------



## Onkel Dagobert (23 Dezember 2020)

Für eine S7-1500 hätte ich eine sehr einfache Lösung, glaube ich zumindest. Die läuft aber schon mal nicht auf einer S7-1200.

Frage:
Die Sollwertvorgabe in [Hz] ist begrenzt auf 0,1Hz bis 3,0Hz. In welchen Schritten soll denn der Sollwert veränderbar sein? Darf man ihn eventuell auf x Kommastellen runden? Wenn ja, wie groß ist x?


----------



## vollmi (23 Dezember 2020)

Onkel Dagobert schrieb:


> Die Sollwertvorgabe in [Hz] ist begrenzt auf 0,1Hz bis 3,0Hz. In welchen Schritten soll denn der Sollwert veränderbar sein? Darf man ihn eventuell auf x Kommastellen runden? Wenn ja, wie groß ist x?



Eine nachkommastelle ist mehr als genug. Es muss auch nicht zwingend eine fliesspunktzahl sein, wenn die cpu das nicht kann, wieso nicht ein int Faktor zehn.


----------



## vollmi (23 Dezember 2020)

Thomas_v2.1 schrieb:


> Dann können anschließend alle die das Rätsel gelöst haben, ihre Weihnachtsbeleuchtung synchron blinken lassen :TOOL:



idealerweise können die von der ISS uns dann sagen obs geklappt hat.


----------



## PN/DP (23 Dezember 2020)

vollmi schrieb:


> idealerweise können die von der ISS uns dann sagen obs geklappt hat.


oder die Energieversorger 

Wenn die Funktion die Uhrzeit braucht, dann darf/soll sie die selber abfragen?

Harald


----------



## vollmi (23 Dezember 2020)

PN/DP schrieb:


> oder die Energieversorger
> 
> Wenn die Funktion die Uhrzeit braucht, dann darf/soll sie die selber abfragen?



wenn sie die Uhrzeit braucht, wäre der eine basisdatentypeneingang dafür zu nehmen. Die Uhrzeit intern abzufragen macht ihn wieder weniger portierbar, jede cpu und jeder Hersteller hat da andere Funktionen.


----------



## Onkel Dagobert (23 Dezember 2020)

vollmi schrieb:


> wenn sie die Uhrzeit braucht, wäre der eine basisdatentypeneingang dafür zu nehmen. ...


Wie immer. Kaum ist man fertig, kommt der Kunde mit Wünschen. Ich lass das jetzt so  .


----------



## DeltaMikeAir (23 Dezember 2020)

Onkel Dagobert schrieb:


> Wie immer. Kaum ist man fertig, kommt der Kunde mit Wünschen. Ich lass das jetzt so  .



Soll doch so realitätsnahe wie möglich sein. Also alles wie immer


----------



## Thomas_v2.1 (23 Dezember 2020)

Da bin ich ja mal gespannt wie das ohne Verwendung der Uhrzeit funktioniert.

Ich habe eine 1200 mit Relais-Ausgängen und einen Raspberry mit Codesys V3 parallel laufen. Wegen den Relais-Ausgängen ergibt das Messen auf Millisekunden nicht viel Sinn, vom Auge her sieht es auf jeden Fall gut aus.
Wobei ich nicht nachvollziehen kann woher sich der Raspberry die Uhrzeit holt. Ein NTP Dienst scheint nicht zu laufen. Dabei habe ich gestern spät abends programmiert, heute gegen Mittag beide eingeschaltet und so nach ca. 30 Sekunden waren beide wieder synchron. Also irgendwoher muss der Raspberry sich die Zeit holen, eine Echtzeituhr hat der ja nicht.


----------



## vollmi (23 Dezember 2020)

Onkel Dagobert schrieb:


> Wie immer. Kaum ist man fertig, kommt der Kunde mit Wünschen. Ich lass das jetzt so  .



ich sag nicht dass die Uhrzeit von aussen kommen Muss. Aber das Portieren auf andere Hersteller dürfte so einfacher werden. Da hier ja jeder sein eigenes Süppchen kocht wie man die Systemzeit ausliest, und in welchem Format diese daherkommt.


----------



## PN/DP (24 Dezember 2020)

vollmi schrieb:


> Gefordert ist ein synchroner Blinktakt auf mehreren SPS sichtbar gemacht über einen digitalen Ausgang mit LED. (...)
> Ein Drift bis 70ms ist akzeptabel. (...)
> Ziel ist eine Funktion für den Takt mit maximal einem Eingang als Basisdatentyp (dint, int, udint etc.), neben dem basisdatentyp für die sollfrequenz und einen rückgabewert als Bool (der Takt).


Wenn die vielen SPS keine Synchronisiersignale austauschen, aber Uhrzeitsynchronisation regelmäßig stattfindet, dann ist die Uhrzeit etwas, was auf allen CPU synchron läuft und als Basis für einen synchronen Takt genutzt werden kann.

Ich habe eine Function mit 2 Input-Parametern:

```
FUNCTION "ClockBlink" : Bool
VAR_INPUT 
  TOD_ms : UDInt;  // Time of Day in ms
  Takt10 : UInt;   // Solltakt: 1..30 = 0.1 .. 3.0 Hz
END_VAR
```
In der Function habe ich dann einen Dreizeiler in SCL (der auf jeder SPS geht, die SCL/ST kann).
Oder darf man bei den Verkehrsampeln nicht direkt die Uhrzeit verwenden? Dann bräuchte ich vermutlich noch zusätzlich eine Merkvariable (TIME oder DINT).

Ich nehme eigentlich sehr ungern die Uhrzeit zum Zeit messen, doch wenn die Uhr regelmäßig per NTP synchronisiert wird, dann sollten eigentlich keine größeren Zeitsprünge mehr vorkommen (je nachdem wie das in der Firmware implementiert ist). Hat jemand Erfahrungen, wie groß die Uhrzeitsprünge wegen NTP-Uhrzeitsynchronisation real werden? Wie Siemens die NTP-Uhrzeitsynchronisation in z.B. S7-1200 und S7-1500 realisiert hat?
Was passiert wenn die CPU-Uhr vorgeht? Wird sie dann bei der NTP-Korrektur zurückgestellt oder angehalten oder wird die Zeitdifferenz schrittweise abgebaut?

In den technischen Daten der CPUs ist angegeben:
S7-1200 Genauigkeit Echtzeituhr: +/- 60 Sekunden/Monat
S7-1500 Uhr Abweichung pro Tag: max. 10 s; typ.: 2 s

Dann kann man wohl annähernd davon ausgehen:
Abweichung pro 24 Stunden: ca. 2 Sekunden
Abweichung pro 15 Minuten: ca. 21 ms

Wenn die Uhrzeitsynchronisation alle 15 Minuten durchgeführt wird, dann sollte die Uhr jedesmal um höchstens 21 ms korrigiert werden. Sehe ich das richtig?

In meiner einfachen Lösung kommt es alle 10 s zu max 24 ms längeren Pulsen und zusätzlich zu Sprüngen durch die Uhrzeitsynchronisation von geschätzt max 21 ms (alle 15 Minuten?). Das dürfte in der OB1-Zykluszeit untergehen und unsichtbar bleiben und daher praktisch vernachlässigbar sein.

Harald


----------



## Thomas_v2.1 (24 Dezember 2020)

PN/DP schrieb:


> Ich nehme eigentlich sehr ungern die Uhrzeit zum Zeit messen, doch wenn die Uhr regelmäßig per NTP synchronisiert wird, dann sollten eigentlich keine größeren Zeitsprünge mehr vorkommen (je nachdem wie das in der Firmware implementiert ist). Hat jemand Erfahrungen, wie groß die Uhrzeitsprünge wegen NTP-Uhrzeitsynchronisation real werden? Wie Siemens die NTP-Uhrzeitsynchronisation in z.B. S7-1200 und S7-1500 realisiert hat?
> Was passiert wenn die CPU-Uhr vorgeht? Wird sie dann bei der NTP-Korrektur zurückgestellt oder angehalten oder wird die Zeitdifferenz schrittweise abgebaut?



Es passiert so wie es aussieht das gleiche, wie wenn du von PG aus die SPS Uhrzeit stellst: sie übernimmt direkt die neue Zeit. Ich habe mir bei Schaltuhren in der SPS auch schon oft genug Gedanken gemacht was denn wohl passiert wenn jetzt mal die Uhrzeit verstellt wird, bei der Umstellung Sommer- / Winterzeit . Denn ich habe Schaltuhrvarianten die auf einen Zeitpunkt reagieren (um beispielsweise Tage zu überbrücken) wo dann etwas entweder ausfällt oder doppelt ausgeführt wird.

Bei Google wird darum selbst bei eingefügten Schaltsekunden diese eine Sekunde über den Tag "verschmiert". Gerade die Schaltsekunden sind ja interessant, da gibt es dann auf mal eine Uhrzeit wie UTC 23:59:60. Einige Komponentenhersteller wie Meinberg umgehen das und die Uhrzeit bleibt dann eine Sekunde stehen. Wenn du ein System hast was wirklich kritisch von der Uhrzeit abhängig ist wird es wirklich interessant, ich würde mal sagen bei Energieversorgern könnte das durchaus kritisch sein. Bei der PTB kannst du dir auch einen verschlüsselten NTP Zugang kaufen, damit du dir sicher sein kannst, dass die Uhrzeit nicht von jemand anderem kommt.


----------



## Blockmove (25 Dezember 2020)

Thomas_v2.1 schrieb:


> Es passiert so wie es aussieht das gleiche, wie wenn du von PG aus die SPS Uhrzeit stellst: sie übernimmt direkt die neue Zeit.



Muss ich mal in der Firma testen, ich hatte es anders in Erinnerung.
Ich war der Meinung, dass die S7 im laufenden Betrieb versucht - solange die Abweichung nicht zu groß ist - schleichend anzupassen.


----------



## Thomas_v2.1 (25 Dezember 2020)

Bei der S7-1200 geht es in Sprüngen direkt vor oder zurück, auch bei kleinen Abweichungen von 3-4 Sekunden. Noch kleinere Zeiten kann ich so mit dem Einstelldialog nicht testen.


----------



## Thomas_v2.1 (25 Dezember 2020)

Ich habe nochmal einen kurzen Test bei einer ET200S CPU gemacht, da wird die Uhrzeit auch direkt verstellt wie bei der 1200.

Ich bin immer noch nicht dahinter gekommen über welchen Dienst sich der Raspberry sich die Uhrzeit holt. Kennt sich damit jemand aus?


----------



## Onkel Dagobert (26 Dezember 2020)

Ich kann leider nicht behaupten, mich mit dem Raspberry Pi aus zu kennen. Genau genommen weiß ich nicht einmal, wie so ein Teil aussieht. Ich hatte jedoch neulich schon einmal nach der Problematik gegoogelt. Vielleicht hilft dir der link.

How to sync time with a server on Raspberry Pi?


----------



## vollmi (26 Dezember 2020)

Ich hab noch bei keiner s7 cpu eine schleichende Anpassung gesehen. Einzige Ausnahme ist der OpenController und die softcontroller welche ja von der windows ebene ihre zeit bekommen können. 

wollte man also eine schleichende aufsynchronisierung haben, müsste man dieses von Hand machen.


----------



## Blockmove (26 Dezember 2020)

Thomas_v2.1 schrieb:


> Ich bin immer noch nicht dahinter gekommen über welchen Dienst sich der Raspberry sich die Uhrzeit holt. Kennt sich damit jemand aus?



Hallo Thomas,
beim Raspi läuft das mittlerweile über systemd.
Genauer gesagt über systemd-timesyncd.
https://manpages.debian.org/buster/systemd/systemd-timesyncd.8.en.html


Gruß
Blockmove


----------



## PN/DP (30 Dezember 2020)

Weihnachten ist vorbei, die genaue Aufgabenstellung ist 8 Tage her.
Rätselt noch jemand? Wann ist Rätselschluss? Wann dürfen wir wo unsere Lösungen posten?

Harald


----------



## Onkel Dagobert (30 Dezember 2020)

Harald, du kannst es wohl gar nicht abwarten, mit deinem Dreizeiler zerlegt zu werden  ?

Wir müssen wohl oder übel den Anpfiff von vollmi abwarten.


----------



## Heinileini (30 Dezember 2020)

Onkel Dagobert schrieb:


> Wir müssen wohl oder übel den Anpfiff von vollmi abwarten.


Weiss vollmi das?


----------



## Onkel Dagobert (30 Dezember 2020)

Vollmi, weißt du das?


----------



## PN/DP (30 Dezember 2020)

Onkel Dagobert schrieb:


> Harald, du kannst es wohl gar nicht abwarten, mit deinem Dreizeiler zerlegt zu werden  ?


Das ist jetzt ein Zweizeiler in 2 Varianten.  Wenn ich noch lange weiterdenke wird es womöglich ein Einzeiler 

Harald


----------



## Onkel Dagobert (30 Dezember 2020)

Ich habe mich mit acht Programm-Zeilen völlig verausgabt :icon_rolleyes: .


----------



## vollmi (30 Dezember 2020)

Und anpfiff. Zum testen müsst ihr euch aber bis Dienstag gedulden. Harald hat mir seine Lösung schon geschickt. Aber ich würd sagen ihr (inkl Harald) postet eure und wir vergleichen. Und optimieren. 
ich hoffe immer noch dass auch ein paar Beginner mitmachen.


----------



## Onkel Dagobert (30 Dezember 2020)

Na dann wollen wir mal.

Die Uhrzeit muss natürlich über einen entsprechenden Time-Server synchronisiert sein. Ob eine Ortszeit oder die UTC-Zeit verwendet wird, ist hierbei egal. Es werden nur die Sekunden und Nanosekunden ausgewertet.



```
FUNCTION "BLINKTAKT_SYSTIME" : Bool
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1

   VAR_IN_OUT 
      F : Real;   // Sollwert Frequenz [Hz], intern begrenzt und gerundet (0,1 .. 3,0Hz)
   END_VAR

   VAR_TEMP 
      TEMP_INT : Int;
      DTL {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;   // Datum und Uhrzeit
      F1 : Real;   // Blink-Frequenz [Hz]
      T1 : DInt;   // Periodendauer [ms]
      RT1 : DInt;   // Laufzeit [ms]
   END_VAR


BEGIN
    
    (* Kommentar vorübergehend entfernt *)
    
    // SP Frequenz [Hz] begrenzen, auf eine Kommastelle runden und wieder ausgeben (IN_OUT)
    #F1 := LIMIT_REAL(IN := #F, MN := 0.1, MX := 3.0);
    #F1 := ROUND_REAL(#F1 * 10) / 10;
    #F := #F1;
    
    // SP Periodendauer [ms]
    #T1 := ROUND(1000 / #F1);
    
    // Systemzeit, Laufzeit [ms]
    #TEMP_INT := RD_SYS_T(#DTL);
    #RT1 := (USINT_TO_DINT(#DTL.SECOND) * 1_000) + (UDINT_TO_DINT(#DTL.NANOSECOND) / 1_000_000);
    #RT1 := #RT1 MOD #T1;
    
    // Ausgabe Verhältnis 50/50
    #BLINKTAKT_SYSTIME := #RT1 < (#T1 / 2);
    
END_FUNCTION
```


----------



## PN/DP (31 Dezember 2020)

Meine Lösung geht davon aus, daß die Uhren der SPSen alle (auf UTC) synchronisiert werden. Dann kann die Uhrzeit als Basis für einen synchronen Takt genutzt werden. Wenn das alle 15 Minuten geschieht, dann dürfte die Uhr bei z.B. S7-1200/S7-1500 alle 15 Minuten Nachstell-Sprünge von höchstens 21 ms machen.

```
FUNCTION "ClockBlink" : Bool
  VAR_INPUT
    TOD_ms : UDInt;  [COLOR="#008000"]// Time of Day in ms[/COLOR]
    Takt10 : UInt;   [COLOR="#008000"]// Solltakt: 1 .. 30 = 0.1 .. 3.0 Hz[/COLOR]
  END_VAR
  VAR_TEMP
    Periode_ms : UDInt;
  END_VAR

BEGIN

  Periode_ms := 10000 / Takt10;
  ClockBlink := ((TOD_ms MOD (60 * 60 * 1000)) MOD Periode_ms) < (Periode_ms / 2);

END_FUNCTION
```
Der Code ergibt jede volle Stunde bei manchen Frequenzen eine Restperiode bis zu 27 ms (meistens 0 bis < 10 ms), die den nächsten Puls verlängert. Zusätzlich kommen noch alle 15 Minuten die Sprünge durch die Uhrzeitsynchronisation von geschätzt max 21 ms. Das dürfte in der OB1-Zykluszeit untergehen und unsichtbar bleiben und daher praktisch vernachlässigbar sein.

Der Code funktioniert wenn die Uhrzeit-Abfrage UTC oder irgendeine Lokalzeit (+/- ganze Stunden) liefert, z.B. wenn die SPS-Uhr nicht in UTC läuft, weil eine falsche Zeitzone der Uhr eingestellt ist (z.B. S7-300 + CP343-1) oder die Uhr kennt keine Zeitzone, und unabhängig ob/wann eine Sommerzeit-Umschaltung stattfindet.

Bei S7-1200/S7-1500 ist die Uhrzeit mit RD_SYS_T zu lesen, das liefert bei korrekter Uhrzeitsynchronisation die Uhrzeit in UTC.

Wenn sicher ist, daß die Uhrzeit-Abfrage UTC liefert (der Input TOD_ms enthält Time of Day in UTC-Zeit), dann reicht dieser kürzere Code:

```
Periode_ms := 10000 / Takt10;
  ClockBlink := (TOD_ms MOD Periode_ms) < (Periode_ms / 2); [COLOR="#008000"]// TOD_ms in UTC ![/COLOR]
```
Dieser Code ergibt nur um Mitternacht (UTC) bei manchen Frequenzen eine Restperiode bis zu 24 ms (meistens 0 bis < 10 ms), die den nächsten Puls verlängert. (Beispiel: bei 2.6 Hz wird der Puls von normal 192 ms auf 216 ms verlängert.)

Harald


----------



## Onkel Dagobert (31 Dezember 2020)

*außer Wertung*

Harald (der Erbsenzähler ) hat mich zurecht kritisiert :???: . Durch meine Berechnung mit DINT entstehen am Ende u.U. Ungenauigkeiten von bis zu 144ms. Das kann ich natürlich nicht auf mir sitzen lassen und schiebe noch einen nach, außer Wertung natürlich.




```
FUNCTION "BLINKTAKT_SYSTIME_LREAL" : Bool

   VAR_IN_OUT 
      F : Real;   // Sollwert Frequenz [Hz], intern begrenzt (0,1 .. 3,0Hz)
   END_VAR


   VAR_TEMP 
      TEMP_INT : Int;
      DTL {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;   // Datum und Uhrzeit
      F1 : Real;   // Blink-Frequenz [Hz]
      T1 : LReal;   // Periodendauer [s]
      RT1 : LReal;   // Laufzeit [s]
   END_VAR


BEGIN
    
    // SP Frequenz [Hz] begrenzen
    #F1 := LIMIT_REAL(IN := #F, MN := 0.1, MX := 3.0);
    #F := #F1;
    
    // SP Periodendauer [s]
    #T1 := 1.0 / REAL_TO_LREAL(#F1);
    
    // Laufzeit [s]
    #TEMP_INT := RD_SYS_T(#DTL);
    #RT1 := #DTL.SECOND MOD 10 + #DTL.NANOSECOND / 1_000_000_000.0;
    [COLOR="#0000FF"]#RT1 := #RT1 - (TRUNC_LREAL(#RT1 / #T1) * #T1);[/COLOR]

    // Ausgabe Verhältnis 50/50
    #BLINKTAKT_SYSTIME_LREAL := #RT1 < (#T1 / 2.0);
    
END_FUNCTION
```

Harald, was sprichst du nun?  

Wo bleiben eigentlich die zahlreichen Lösungen, die in euren Schubladen schlummern?
Ich bin mir sicher, es haben sich viele von euch daran versucht.


----------



## Heinileini (20 Januar 2021)

Onkel Dagobert schrieb:


> Wir müssen wohl oder übel den Anpfiff von vollmi abwarten.


Apropos Anpfiff, ist schon etwas in puncto Abpfiff/Auflösung geplant? 

Hier im Thread sehe ich gar keine Bewegung mehr. Erfolgen mittlerweile alle Aktivitäten per PN?


----------



## vollmi (20 Januar 2021)

Heinileini schrieb:


> Apropos Anpfiff, ist schon etwas in puncto Abpfiff/Auflösung geplant?
> 
> Hier im Thread sehe ich gar keine Bewegung mehr. Erfolgen mittlerweile alle Aktivitäten per PN?



Ne irgendwie keine Aktivitäten. Leider nur die Beispiele von Onkel Dagobert und PN/DP bekommen. Die Funktionieren natürlich beide. Ich bin am Schluss der Entwicklung bei Haralds Aufbau gelandet. 
Und Haralds Beispiel ist ja auch das wo man sieht das man Zeile um Zeile abbauen kann. Nur es macht halt nicht immer Sinn. Man könnte hier ja auch alles in eine Zeile schreiben ohne Vorberechnung der Periodendauer. Aber dann hat man zwei gleiche Berechnungen in einer Zeile. Das sieht dann auch nur superoptimal aus, aber reel vergeudet man vermutlich eher Rechenoperationen.

Gab aber diverse Zwischenschritte. Einen möchte ich euch noch präsentieren.
Meine ersten Versuche haben damit gestartet dass ich erstmal die Taktmenge pro Minute errechnet habe. 
Später hab ich dann auf TOD gewechselt. Da gibt's nämlich unter Umständen maximal nur noch einmal am Tag einen Versatz im Takt und der ist bei Datumswechsel. Also wird er kaum jemandem auffallen.


```
#Periodendauer := 1000.0 * (1.0 / #Period); // Periodendauer in Millisekunden errechnen#Halbwelle := #Periodendauer / 2.0; // halbe Periode errechnen in Millisekunden


#status := RD_SYS_T(#Systime); // aktuelle Systemzeit auslesen
#MilisecOfMin := (#Systime.NANOSECOND / 1000000) + (USINT_TO_UDINT(#Systime.SECOND) * 1000); // die aktuelle Millisekunde der aktuellen Minute errechnen


#wechselProMin := #MaxMsPerMin / REAL_TO_UDINT(#Halbwelle); // Wie viele Nulldurchgänge pro Minute?
#Per := #MilisecOfMin / REAL_TO_UDINT(#Halbwelle);


(* wenn eine ungerade Anzahl Durchgänge pro Minute passieren muss bei
jedem Minutenwechsel die Taktrichtung invertiert werden 
um keine doppelte Zeit anstehend zu haben beim Minutenwechsel *)
IF #wechselProMin.%X0 = True THEN
    IF #Systime.MINUTE.%X0 = true THEN
        #FC_Fut_Frequenz := #Per.%X0;
    ELSE
        #FC_Fut_Frequenz := NOT #Per.%X0;
    END_IF;
ELSE
    #FC_Fut_Frequenz := #Per.%X0;
END_IF;
```

Das hat auch durchaus gut funktioniert. Weiterentwickelt habe ich erst, als ich die ganze Sache auch auf alten Codesys V2 Steuerungen zum laufen bringen musste.
Ich glaube die Aufgabenstellung war zu einfach fürs Weihnachtsrätsel. Vielleicht waren alle so beschäftigt mit Skifahren und Weihnachtsmärkte besuchen.


----------



## Heinileini (24 Januar 2021)

vollmi schrieb:


> Später hab ich dann auf TOD gewechselt. Da gibt's nämlich unter Umständen maximal nur noch einmal am Tag einen Versatz im Takt und der ist bei Datumswechsel.
> 
> Ich glaube die Aufgabenstellung war zu einfach fürs Weihnachtsrätsel.


Für mich war das WeihnachtsRätsel eher zu rätselhaft. 
Wie soll denn z.B. zwischen den einzelnen SignalBrücken die Einigung auf eine der 30 zur Auswahl stehenden Frequenzen "synchronisiert" werden?

Ich war bei meinen Überlegungen direkt mit dem "TOD-Format" angefangen und hatte mich darauf geeinigt, mit DINTs zu rechnen. 
Bei UDINT hätte ich Bedenken, dass die eine oder andere SPS diesen Datentyp nicht kennt.
Bei REAL wiederum habe ich Bedenken, dass die Genauigkeit zu gering ist. Habe es mir verkniffen, das näher zu betrachten und LREAL wollte ich in Hinblick auf Verfügbarkeit auch nicht in Erwägung ziehen.
Also DINT. 
Dass die Werte von TOD im Bereich 0..86399999 [ms] liegen (falls erforderlich per MOD auf diesen Bereich beschränken) und bei den Frequenzen die entsprechenden PeriodenDauern 333..10.000 [ms] sind, brachte mich dann auf die Idee, die Einheit ms in 50µs zu ändern (ms-Werte mit 20 multiplizieren), damit die abgerundeten Quotienten näher bei der "WunschRealität" liegen, die man mit genügend genauen GleitpunktZahlen erreichen könnte. Die Anzahl der BlinkImpulse verringert sich dadurch im ExtremFall 2,9 Hz um immerhin 582 pro Tag.

So, was ist nun mit den erzielten Abweichungen, die beim TagesWechsel auftreten? 
Bei den Frequenzen 0,1 - 0,2 - 0,4 - 0,5 - 0,8 - 1,0 - 1,6 - 2,0 - 2,5 Hz kein Problem, aber ... ansonsten darf man keine allzu engen Massstäbe anlegen! 

Im folgenden Bild sind drei der ProblemFälle, nämlich 0,3 Hz, 1,4 Hz und 3 Hz zu sehen. Der Tageswechsel ist bei Abszisse 84.600.000 zu sehen und die Beschriftung der Abszisse rechts davon ist als 'x MOD 84.600.00' zu interpretieren.

Edit: habe Probleme, hier das Bild einzufügen. Versuche es nochmal im nächsten Beitrag ...

Andererseits, wenn man nur Wert auf die Synchronität zwischen den einzelnen SPS legt, so ist nur wichtig, dass sie alle nach demselben Prinzip rechnen.
 Unterschiede der ZyklusZeiten der einzelnen SPS dürften nicht wirklich sichtbar werden.


----------



## Heinileini (24 Januar 2021)

Sooo, scheint jetzt geklappt zu haben.


----------

