Hallo,
ich bin gerade bei der Verwendung der Array-max-min-Funktion auf eine Merkwürdigkeit gestoßen (siehe angehängtes Beispiel-VI).
Einfach mal dort den markierten Draht entfernen bzw. eine I32-Conversion einfügen und alles ist in Ordnung - aber wieso?
Dieses Verhalten ist ja nicht weiter schlimm, aber halt merkwürdig/bug.
Aufgefallen ist mir das unter LV 2012, aber scheint bei LV 2016 genauso zu sein.
Höhere LV-Versionen zum austesten habe ich auf die Schnelle leider nicht zur Hand.
Gruß, Thomas
ISt in 2018 auch so. Sieht tatsächlich nach einem Bug aus. Meine Vermutung war zunächst, dass du das Schieberegister mit einem DBL eröffnet hast und dann zwei unterschiedliche Datentypen drangehangen hast. Doch das ist ja nicht der Fall. Melde es an NI, vllt beheben die das 2025
Das ist kein Bug, das ist ein Feature.
Und so funktioniert das:
* Auf der While-Schleife ein Schieberegister erzeugen. Das Schieberegister ist schwarz, da es noch keinen Typ hat.
* Jetzt in irgendeinem Case einen Werte-Ausgang(!) des Min/Max, das aber noch kein Eingangs-Array hat, aus dem Case heraus mit dem Schieberegister rechts auf der While-Schleife verbinden.
* In diesem Moment bekommt das Schieberegister den Typ DBL, das ist das Feature.
* Verbindet man jetzt in allen anderen Cases innerhalb der Case-Anweisung die Tunnel zu/vom Schieberegister, so wird der Typ DBL "noch fester" festgelegt, weil jetzt ein DBL-Ausgang (der vom linken Schieberegister) auf das rechte Schieberegister geht,
* Verbindet man jetzt den Array-Eingang von Min/Max mit einem I32-Array, ändert sich zwar der Wertetyp von Min/Max - nicht aber der Typ des Schieberegister. Weil der ja "geprägt" wurde.
Es ist also kein Bug, sonder eher ein Feature.
Geht man so vor, kommt I32 raus:
* Schieberegister erstellen
* Ausgang Min/Max auf Schieberegister
* I32-Array auf Min/Max-Array-Eingang => Jetzt wird das Schieberegister mit I32 geprägt ...
Bei mir hat der Vorschlag von IchSelbst nicht funktioniert. Der Bug scheint in der Funktion Array max/Min angelegt zu sein. Wenn ich den Ausgang, obwohl der bereits das Format I32 hat, nach I32 konvertiere, dann ist alles in Ordnung. Ebenso, wenn ich diese Funktion durch irgendeine andere Funktion mit einem I32-Ausgang, oder durch eine I32-Konstante selbst, ersetze, dann ist alles in Ordnung.
(06.06.2019 22:52 )IchSelbst schrieb: [ -> ]* Schieberegister erstellen
* Ausgang Min/Max auf Schieberegister
* I32-Array auf Min/Max-Array-Eingang => Jetzt wird das Schieberegister mit I32 geprägt ...
Das hat bei mir funktioniert. Nur bei dem oberen Beispiel kommt bei mir immer DBL. Selbst wenn ich alles trenne, das SR mit I32 initialisiere und dann alles verdrahte kommt da wieder DBL bei rum...
Habe gerade die "Lösung" gefunden. Man muss das SR fürs Array initialisieren, dann wird das SR für Max/Min auch zum I32
Das ist alles seltsam, aber der Code ist ja stark aufgedonnert, fast alles ist überflüssig. Wenn man den Code vereinfacht, und sei es nur, daß man den nicht benötigen Draht im letzten Case zum Ausgang des Shift-Regisers wegläßt, wird alles normal. Deshalb halte ich es für ein schlechtes Beispiel, um NI damit einen Bug zu unterstellen - aber interessant wäre es doch, wieso es dazu kommt.
Zitat:Deshalb halte ich es für ein schlechtes Beispiel, um NI damit einen Bug zu unterstellen - aber interessant wäre es doch, wieso es dazu kommt.
Das ist kein Bug, das ist ein Feature - und zwar ein System-Feature. Das geht nämlich nicht nur mit Array-Min/Max so, sondern mit allen Elementen, die ohne Anschlüsse automatisch DBL-Ausgang haben. Das kommt von der Intelligenz des Systems, also von dessen Intuition.
Jetzt stellt sich natürlich die Frage, wenn das ein Feature ist, müsste es dann nicht in der Systembeschreibung (= Hilfe) erklärt sein? Siehe Hilfe:
"Mit Schieberegistern kann jeder beliebige Datentyp übertragen werden, da Schieberegister automatisch den Datentyp des ersten mit ihnen verbundenen Objekts annehmen." Und der erste Datentyp war der DBL-Ausgang des Tunnels ...
(08.06.2019 10:33 )IchSelbst schrieb: [ -> ]Zitat:Deshalb halte ich es für ein schlechtes Beispiel, um NI damit einen Bug zu unterstellen - aber interessant wäre es doch, wieso es dazu kommt.
Das ist kein Bug, das ist ein Feature - und zwar ein System-Feature. Das geht nämlich nicht nur mit Array-Min/Max so, sondern mit allen Elementen, die ohne Anschlüsse automatisch DBL-Ausgang haben. Das kommt von der Intelligenz des Systems, also von dessen Intuition.
Jetzt stellt sich natürlich die Frage, wenn das ein Feature ist, müsste es dann nicht in der Systembeschreibung (= Hilfe) erklärt sein? Siehe Hilfe:
"Mit Schieberegistern kann jeder beliebige Datentyp übertragen werden, da Schieberegister automatisch den Datentyp des ersten mit ihnen verbundenen Objekts annehmen." Und der erste Datentyp war der DBL-Ausgang des Tunnels ...
Ausser dass das nicht wirklich der erste damit verbundene Datentyp ist sondern derjenige der ohne (signifikanten) Datenverlust alle möglichen Werte enthalten kann und das ist im Zweifelsfall ein Double (Theoretisch wäre Extended noch "besser", ausser dass das ausser auf 32 bit x86 Systemen heutzutage equivalent ist mit einem Double).
(07.06.2019 15:19 )Lucki schrieb: [ -> ]Das ist alles seltsam, aber der Code ist ja stark aufgedonnert, fast alles ist überflüssig. Wenn man den Code vereinfacht, und sei es nur, daß man den nicht benötigen Draht im letzten Case zum Ausgang des Shift-Regisers wegläßt, wird alles normal. Deshalb halte ich es für ein schlechtes Beispiel, um NI damit einen Bug zu unterstellen - aber interessant wäre es doch, wieso es dazu kommt.
Nun ja, du glaubst doch jetzt nicht, dass das mein ursprüngliches Programm war. Ich habe es nur auf das wesentlichste eingedampft um das Problem aufzuzeigen, auf das ich gestoßen bin. Der letzte Draht wird bei meinem Orignal-Programm natürlich nicht unverändert dem Shift-Register zugeführt; vielmehr wird damit gerechnet und erst das Ergebnis kommt dann ins Shift-Register - Draht löschen kommt also nicht in Frage.
Angehängt mal das ursprüngliche VI (leicht modifiziert um es lauffähig zu halten), plus das Haupt-VI von dem es aufgerufen wird (letzteres nur auf die Interaktion mit dem Sub-VI reduziert).
Im Sub-VI im "resize"-case rot eingekringelt die eigentliche unnötige I32 Typ-Umwandlung ohne die es irgendwie zur DBL-Konversion kommt.
(Falls wer Anstoß an der 85er Schleife mit dem 1er inkrement/dekrement nimmt - das war nur so ne fancy "smooth scrolling" Idee von mir
)
Was das "den Datentyp des
ersten mit ihnen verbundenen Objekts annehmen" angeht: Das haut nicht hin.
Wenn man in meinem VI alle entsprechenden Schieberegister löscht, neu anlegt und dabei erst als wirklich allerletztes die Array-Min/Max Funktion verdrahtet, passiert trotzdem die merkwürdige DBL-Umwandlung.
Btw: Falls wer eine Idee hat wie man die ganze UI-Skaliererei (weswegen den ganzen Aufwand mache) eleganter lösen kann, immer her damit. Das LabView autoscaling ist echt ein PITA.
Gruß, Thomas
Hallo Thomas,
das hat wohl eher nichts mit dem ArrayMinMax zu tun: Du kannst das ToI32 auch nach dem zweiten ArrayMinMax einfügen, bevor der Draht den Case verlässt.
Das ganze dürfte damit zusammenhängen, dass dies der einzige Case ist, in dem der Datentyp des Shiftregisters definiert wird - und wahrscheinlich gibt es noch einen Zusammenhang mit dem Compiler/Optimizer von LabVIEW.
Als Bug würde ich es nicht sehen, eher als "Feature". Ist nicht schön, läuft aber weiterhin (ein DBL kann alle I32 speichern)…