Modulo Baustein rechnet falsch?!?

[soko]

Hallo Leute,

Anscheinend hat der Modulo-Baustein einen Fehler mit großen Zahlen. Ich hab mir zwei Modulo-Berechnungen gebastelt, die mir den Wert des Bit-0 und Bit-16 einer 32-Bit Zahl ausrechnen:



Wie ihr sehen könnt unterscheidet sich die 1. Zahl 19861749 von der 3. Zahl 2167345397 nur im Bit-31. Dennoch liefert das Modulo andere Ergebnisse...

Könnt ihr das vielleicht mal unter der aktuellen LoxConfig Version simulieren (Projekt liegt anbei).

Zudem ist mir der Ausgang AQ2 ein Mysterium. Laut Doku soll er "das Ergebnis als Dezimal" liefern. Was er aber nicht tut...

Ist euch das schon aufgefallen?

Danke
Soko

[Christian Fenzl]

Ich hab nichts nachgerechnet, aber das Ergebnis steht wohl in AQ2?

[Tico]

Config 9.3.3.26

[soko]

Christian Fenzl : Ja aber warum. Das sollte laut Definition nicht so sein!
Tico : Sehr interessant! Bit-0 macht er richtig, aber Bit-16 kriegt er auch ned hin! Danke!!

[romildo]

und das macht er in V10.0.9.24

[soko]

Aha... ist ja witzig... da macht v10 mehr Fehler als v9 und ist somit gleich auf mit v7

Loxone schreibt:
----------------------------
Danke für Ihre Anfrage,
Hier dürfte für den Ausgang AQ ein kleinerer Wertebereich erlaubt sein als für AQ2
Deshalb wird hier bei AQ2 der korrekte Wert angezeigt bei AQ jedoch nicht.
Der unterscheid bei den beiden wäre wenn Sie z.b. 1 mod 0,3 eingeben kommt hier bei AQ=0 als Ergebnis raus da als Ganzahl ohne Kommastelle raus und bei AQ2 0,1 da Dezimalzahl.
----------------------------

Hab geantwortet das die den Fehler bitte beheben sollen...

Mit der Erklärung von AQ2 werd ich wohl meine Anlage auf AQ2 umbaun müssen

[Jan W.]

Wenn Du AQ2 nimmst, wie Christian geschrieben hat, dann stimmt die Modulo Berechnung, oder?

Warum bei großen Zahlen AQ <> AQ2 ist, das hat wahrscheinlich mit der internen Berechnung und den verwendeten Zahlenformaten (Float, Int16, Int32) zu tun. Für mich ist AQ überflüssig, wenn AQ2 das korrekte Ergebnis enthält und AQ eine evtl. notwendige Umrechnung bei großen Zahlen nicht richtig durchführt. Da wir (die Mitglieder des Forums) den Quellcode des Bausteins nicht haben, kann nur Loxone den Grund erläutern. Mach doch mal ein Ticket dazu auf!

Gruß Jan

[Jan W.]

Da kam die Antwort von Dir noch schneller. Bei AQ scheint int16 verwendet zu werden, so dass die Ergebnisse bei großen Zahlen falsch sind.

[soko]

int16 kann aber nicht sein, weil in meiner echten Haussteuerungdatei ist AQ=131071 bei großen Zahlen und AQ2 eben richtig. 131071 wären 17-Bit ?!?!

[Jan W.]

Ja, int16 passt nicht. Vielleicht int32 (mit Vorzeichen), wo eine Zahl mit gesetztem Bit 31 negativ wäre. Man müsste den Code sehen (oder lange testen), um festzustellen, bei welchen Eingaben AQ falsch berechnet wird.

[romildo]

Ich verstehe eh nicht, warum da immer wieder bestehende Bausteinen geändert werden, danach nicht mehr so funktionieren wie vorher und kein Wort darüber im Changelog erwähnt wird.

[romildo]

Das sehe ich aber bei den Bausteinen nicht so, da diese ja autonom sind.
Da muss schon bewusst die Routine des Bausteins verändert werden.
Dass da nicht immer alles so läuft wie man sich das bei der Programmierung vorstellt, ist mir auch klar.
Wenn man eine Änderung mitbekommen würde, könnte der Baustein auch von verschiedenen Seiten getestet werden, zumindest wäre man sensibilisiert.

Habe auch einige Jahre Hard- und Software- Entwicklung auf dem Buckel

[Christian Fenzl]

Wenn ich als Softwareunternehmen beispielsweise Datentypen anpasse (sowas in der Art kann ich mir vorstellen, wo nicht direkt in den Baustein eingegriffen werden müsste, um ihn zu killen), dann müssen die Testfälle natürlich auch auf diese Änderungen hin optimiert sein. Ein Test von Modulo 2 von 21 wird nicht erkennen, ob das INT16 oder INT32 ist und was mit großen Zahlen passiert.

Nun, dann passiert es dann doch mal, dass etwas kaputt wird - dann erwarte ich mir zumindest eine aktive Warnung, wenn mir der Fehler bekannt ist.

Jetzt sind x Funktionen in der App, die „nach Hause telefonieren“, mich mit Update-Hinweisen zuspammen, auf allen Geräten muss ich neue Produkte zwangsweise wegklicken, aber wenn was geschrottet wird, hört man keinen Ton, keine News, keine Mail, kein Known-Issue Eintrag.

Das charakterisiert Loxone immer noch als einen Software-Zwerg, der nicht mal seine auch kritischen Fehler eingesteht.

[Jan W.]

Ja, von vielen Details im Changelog scheint Loxone nichts zu halten.Verwirrt die Anwender vielleicht zu sehr? In v10 scheint AQ bei Überschreitung des Wertebereiches für die Eingangswerte immer 0 auszugeben - ist vielleicht besser, als unsinnige Werte zu liefern. Leider gibt es nicht mal eine Online-Doku für die Funktion und in der Info werden (auch bei allen ? anderen Bausteinen) keine Wertebereiche angezeigt. Ist vielleicht zu trivial für eine Doku?

[theonlychriss]

Moin zusammen,

kleiner Warn-Hinweis: In der aktuellen public Beta (10.3.7.30) ist der Modulo-Operator (wieder?!) fehlerhaft. An AQ wird das Divisionsergebnis ausgegeben (also, z.B. 4mod2 = 2 oder 4mod4 = 1). Das war bis zu der Beta, zumindest solange ich den Baustein in der Form benutze (ca. 3 Jahre), nicht so.
Eine Änderung des Verhaltens von AQ2 habe ich nicht bemerkt, weil ich den Ausgang nicht benutze. Kann daher keine Erfahrung teilen.
Ticket ist erstellt und wird laut Support bis zum nächsten Release gefixt. Wobei, was gefixt wird, weiß man nicht - ein Fehler im Verhalten des Modulo-Operators, der sich eingeschlichen hat, so der ungefähre Wortlaut.

Viele Grüße,
Christian

[Gerd Clever]

Hallo,

die Public Beta 10.2.3.26 lief schon ganz vernünftig:



bei der Public Beta 10.3.7.30 ist man offensichtlich auf "Divison mit Rest" übergegangen, wobei etwaige Nachkommastellen von AI2 abgeschnitten werden:



Ich meine, Loxone sollte endlich mal klar dokumentieren, wie der Baustein arbeiten soll und das dann auch zuverlässig umsetzen und dann beibehalten. Wenn ich dieses Drama sehe, weiß ich nicht, wo ich das Vertrauen in andere (komplexere und wichtigere!) Bausteine hernehmen soll.

Gruß, Gerd


Ergänzung: 10.0.9.24 arbeitet wie Public Beta 10.2.3.26. AQ = Ergebnis, nachdem etwaige Nachkommastellen von AI1 und AI2 abgeschnitten wurden; AQ2 = Ergebnis ohne Abschneiden etwaiger Nachkommastellen.