Neue Logikbausteine für den L1/X1: Formelberechnung, Statistik und mehr...

[kba]

versucht:
System.Globalization.ISOWeek.GetWeekOfYear(System.DateTime)

[hyman]

OK, da habe ich zu kurz gedacht. Man muss ja erst mal einen bestimmten Calendar instantiieren, bevor man mit dem was machen kann. Also lagst Du mit CultureInfo.CurrentCulture gar nicht so falsch, weil in jeder Culture schon ein Calendar drin ist. Nur hat auch da der Wurzelnamespace gefehlt. Also vielleicht doch eher so (ungetestet):

System.Globalization.CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(...)

[hyman]

PS: Probier' aber ruhig auch mal das von Kris (@kba) Vorgeschlagene, das ist deutlich einfacher.

[thojoh]

versucht:
System.Globalization.ISOWeek.GetWeekOfYear(System.DateTime)

Diese Formel klingt vielversprechend, da die Kalenderwochen nach ISO 8601 gezählt werden.
Für die Formel:

System.Globalization.ISOWeek.GetWeekOfYear(System.DateTime.Now)

bekomme ich aber folgenden Fehler:

Expression 5: (1,9): error CS0234: The type or namespace name `ISOWeek' does not exist in the namespace `System.Globalization'. Are you missing an assembly reference?

[thojoh]

OK, da habe ich zu kurz gedacht. Man muss ja erst mal einen bestimmten Calendar instantiieren, bevor man mit dem was machen kann. Also lagst Du mit CultureInfo.CurrentCulture gar nicht so falsch, weil in jeder Culture schon ein Calendar drin ist. Nur hat auch da der Wurzelnamespace gefehlt. Also vielleicht doch eher so (ungetestet):

System.Globalization.CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(...)

...vor lauter Bäume (Objekte, Klassen, Instanzen)...den Wald...aber jetzt läuft sie fehlerfrei!!!
Habe noch die Regeln von CalendarWeekRule angepasst, sodass die Zählung richtigerweise nach ISO 8601 erfolgt.

Folgende Formel liefert nun die aktuelle Kalenderwoche zum heutigen Datum mit Hilfe des Bausteins Formelberechnung:

System.Globalization.CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(System.DateTime.Today, System.Globalization.CalendarWeekRule.FirstFourDayWeek, System.DayOfWeek.Monday)

Danke und Gruß,
Johannes

[Parsley]

Hallo zusammen,

1. Lieber Horst, danke für deine tollen Bausteine! :-) (Gibt es irgendwo einen Hut, wo ich dir etwas hineinwerfen könnte?)

2. Ich möchte die Formelberechnung nutzen um Logiken mit meinen Rollläden umzusetzen. Ich habe also %-Ein- und -Ausgänge. Als Eingänge verwende ich für die Prozente der Positionen z.B. {soll:N}. Diese lassen sich direkt ohne Typ-Konverter mit einem 5.001 GA Eingang verbinden.
Als "Typ des Ausgangs" der Formel habe ich integer eingestellt, sodass ich z.B. (int?){soll} ausgebe. Dieser Ausgang der Formelberechnung benötigt dann aber noch einen Typkonverter, damit ich ihn an eine 5.001 GA übergeben kann. Ist das so richtig, oder kann ich an den verwendeten Datentypen noch etwas optimieren? In der Simulation im GPA habe ich so jedefalls schon mal keine Probleme bezüglich 0...100% vs 0...255 feststellen können.

3. Lassen sich auch direkt in den Formeln Verzögerungen einbauen, oder muss man dafür auf einen Telegrammverzögerer-Baustein zurückgreifen?
(In der Hilfe verweist du für Funktionen zwar auf die 'Klassen der .NET 4.0 API', aber da ich in C# nicht zuhause bin, bin ich von dieser Dokumentation doch etwas erschlagen. Sorry :-( )

4. Gibt es schon eine Art "best practise", wie man im X1 eine State Machine bauen kann? Meine erste entsteht gerade auf der Basis eines Formelberechnung-Bausteins: Ich habe aktuell 4 States. Jeder State hat eine eigene Formel, welche die Bedingungen zum Wechsel in einen andere States enthält. Alle 4 Formel-Ausgänge schreiben ein den selben Ausgang-Baustein, wobei die Formel des aktuellen States einen Wert ungleich NULL einträgt. (Habe ich das verständlich beschrieben?)
Gibt es schon andere, erprobte Ansätze?

Viele Grüße

[hyman]

Hallo Lukas,

zu 1.: Danke für die Blumen. Nein, Hut gibt es keinen. Spende gern stattdessen an eine gemeinnützige Organisation. Oder hilf den in Deinem Umfeld von COVID besonders Betroffenen.

zu 2.: DPT 5.001 ist an sich ein 8-Bit-Integer. Durch die Abbildung 0..255 ↔ 0,0 ..100,0 % ergeben sich aber Nachkommastellen. Damit die auf internen Daten nicht verloren gehen, muss der Typ Dezimalzahl verwendet werden. Du solltest daher Deinen Ausgangstyp auf NUMBER stellen, sonst verlierst Du Genauigkeit. Der Typkonverter wird damit auch überflüssig.

zu 3.: DIe Formelberechnung hat keine Möglichkeit "nach Zeit" ausgelöst zu werden. Daher brauchst Du für sowas immer externe Telegrammverzögerer.

zu 4. Würde ich genau so machen. Ich kenne nichts einfacheres. Außer, wenn man nur 2 Zustände braucht, das RS-Flipflop.

Grüße von Horst

[Parsley]

hyman Danke!

[Parsley]

"nach Zeit" ausgelöst zu werden

Ähm, da fällt mir auf: es ging mir nicht um das Starten einer Berechnugn, sondern um verzögerte Ausgabe. Also

({a} == {b}) ? /*sofortige Ausgabe*/ {c} : /*verzögerte Ausgabe*/ {c}.delay_n_minuten(10)

Man verzeihe mir diesen abschäulichen Pseudocode, aber damit sollte klar werden, was ich meinte. Das Ziel ist es in einer State Machine eine Art "Warte-State" zu haben, der nach Zeit n automatisch weiterschaltet. Aber ich vermute mal, dass auch das so nicht möglich sein wird, da die Formelberechnung intern keine Zeitbasis kennt oder so ähnlich?

[hyman]

Selbst wenn sowas geht, würde ich es nicht machen, weil Du möglicherweise auch die Bearbeitung anderen Logiken damit blockierst.

[meti]

Hi!
Ich versuche gerade eine einfache Logik mit den Statistikfunktionen zu bauen. Irgendwie scheint der Index des Maximalwerts aber nicht richtig zu aktualisieren. Im Bild müsste doch der Index auf 3 stehen.
Verwende ich das falsch? Oder geht das einfach nur in der Simulation nicht (habs noch nicht aufs Gerät geladen)?

Gibt es evtl auch eine einfacher Lösung für das Problem die ich übersehen hab? Mir ist einfach keine Lösung mit X1 Bordmitteln eingefallen um diese simple Logik zu bauen.

Die Eingänge sind Binär mit Typ-Konverter. Die werden mit fixer Priorität multipliziert und die Größte soll die LED-Farbe über den Eingangswahlschalter+ angeben. Der fixe Eingang 1 steht für die Farbe 0 -> Aus
Screenshot 2021-03-20 093320.png

[thojoh]

Hi!
Ich versuche gerade eine einfache Logik mit den Statistikfunktionen zu bauen. Irgendwie scheint der Index des Maximalwerts aber nicht richtig zu aktualisieren. Im Bild müsste doch der Index auf 3 stehen.
Verwende ich das falsch? Oder geht das einfach nur in der Simulation nicht (habs noch nicht aufs Gerät geladen)?
Gibt es evtl auch eine einfacher Lösung für das Problem die ich übersehen hab? Mir ist einfach keine Lösung mit X1 Bordmitteln eingefallen um diese simple Logik zu bauen.
Die Eingänge sind Binär mit Typ-Konverter. Die werden mit fixer Priorität multipliziert und die Größte soll die LED-Farbe über den Eingangswahlschalter+ angeben. Der fixe Eingang 1 steht für die Farbe 0 -> Aus

Hallo,
habe es versucht zu rekonstruieren und es funktioniert laut Hilfebeschreibung (VORSICHT: Index geht 0 bis n-1):

• Parameter "Index des Maximalwertes" liefert eine "2", entspricht Eingang 3
• Parameter "Index des Minimalwertes" liefert eine "1", entspricht Eingang 2

Kontrolliere doch mal deine Parametereinstellungen?!

P.S. Deinen "Eingang 1 = fix 1" könntest du dir dann auch sparen, denn der Index für den ausgewählten Eingang am Eingangswahlschalter+ startet auch bei 0 und geht bis n-1.

Gruß
Johannes

[meti]

Oh danke! Ich hab tatsächlich den "Index des Minimalwertes" ausgewählt gehabt 🤦♂️

Den Eingang 1 fix brauch ich aber trotzdem weil der den Ruhezustand definiert - dh wenn alle anderen Eingänge 0 sind soll die LED nicht leuchten. Dafür gibts dann im Farb-Eingangswahlschalter ja auch einen eigenen Eingang.

[thojoh]

Den Eingang 1 fix brauch ich aber trotzdem weil der den Ruhezustand definiert - dh wenn alle anderen Eingänge 0 sind soll die LED nicht leuchten. Dafür gibts dann im Farb-Eingangswahlschalter ja auch einen eigenen Eingang.

Stimmt...

[Sral1987]

Sorry, Falscher Beitrag.

Sollte in den Abfallkalenderthred vom X1