erlaubter Wertebereich wird nicht eingehalten

Hallo,

ich hab auf dem Frontpanel ein numerisches Bedienelement. Den Wertebereich hab ich von 0 bis Inf eingestellt. Innerhalb des VIs klappt das auch. Benutze ich das Bedienelement aber als Eingang und binde das VI als SubVI ein, kann ich im Blockdiagramm an den Anschluss eine Konstante mit negativem Wert anlegen. Kann man das untersagen?

Dank und Gruß

Philipp

Anzeige

Nein, dieses Feature wurde schon vor längerer Zeit aufgegeben.
In LabVIEW 6.x und 7.x (?) ging das noch, inzwischen werden Bereichseinschränkungen bei der Übergabe (oder auch Rückgabe) eines SubVIs nicht mehr beachtet.

Gruß, Jens

Das geht nur mit der Funktion "Wertebereich prüfen und erzwingen". Die Einschränkung des Wertebereichs über die Anzeigeeigenschaften ist nur für die händische Eingabe gedacht, bei Wertzuweisung über Programm wird die Einschänkung ignoriert.

(15.12.2011 16:43 )jg schrieb:  Nein, dieses Feature wurde schon vor längerer Zeit aufgegeben.
In LabVIEW 6.x und 7.x (?) ging das noch, inzwischen werden Bereichseinschränkungen bei der Übergabe (oder auch Rückgabe) eines SubVIs nicht mehr beachtet.

Gruß, Jens

Ich weiss 99.9% sicher dass LabVIEW 7.x das auch nicht mehr tat. Ob das aber jetzt in 6.0 oder 6.1 oder 7.0 rausgenommen wurde weiss ich nicht mehr. Ist auch eine rein akademische Frage, und deshalb werde ich auch nicht meine Zeit damit verschwenden das rauszusuchen

Die Änderung finde ich logisch und sinnvoll.

(19.12.2011 11:48 )rolfk schrieb:  ..
Die Änderung finde ich logisch und sinnvoll.

Warum?

Ich bin auch schon darüber gestolpert und hätte es gerne gehabt, dass das FP-Element sowohl bei der Eingabe einer Zahl als auch beim Beschreiben der zugehörigen lokalen Variable den Wert ggf. rundet. Natürlich konnte ich es "Wertebereich prüfen und erzwingen" umsetzen - aber so all-in-one wäre auch ganz praktisch.

(19.12.2011 21:42 )unicorn schrieb:  

(19.12.2011 11:48 )rolfk schrieb:  ..
Die Änderung finde ich logisch und sinnvoll.

Warum?

ob logisch - k.A, aber auf jeden Fall sinvoll. Die Korrektur erfolgt ohne Fehlermeldung oder Warnung und es ist nicht zu erkennen, daß so eine Korrektur stattgefunden hat - außer natürlich bei der händischen Eingabe selbst.
Man würde sich totsuchen, wenn wegen so einer Werteinschränkung ein ungewollt falsches Ergebnis herauskommt.
Oder anders gesagt: Hätte man das gemacht, dann hätte man auch dafür sorgen müssen, das jedes Control außer seinem Wert-Ausgang noch einen zusätzlichen boolschen Ausgang "Wert wurde geändert" hat. Denn so eine Information wäre wesentlich. Diese Verumständlichung von Controls hat NI sinnvollerweise unterlassen - ich bin damit zufrieden.

(19.12.2011 21:42 )unicorn schrieb:  

(19.12.2011 11:48 )rolfk schrieb:  ..
Die Änderung finde ich logisch und sinnvoll.

Warum?

Ich bin auch schon darüber gestolpert und hätte es gerne gehabt, dass das FP-Element sowohl bei der Eingabe einer Zahl als auch beim Beschreiben der zugehörigen lokalen Variable den Wert ggf. rundet. Natürlich konnte ich es "Wertebereich prüfen und erzwingen" umsetzen - aber so all-in-one wäre auch ganz praktisch.

Hauptsächlich weil es versteckt ist und nicht einfach sichtbar dokumentiert. Das kann sehr unschöne Ergebnisse geben, die nur bei genauer Kenntnis dieses Features überhaupt auffindbar sind. Die explicite Programmiering mit Wertebereich prüfen ist da viel besser.

(19.12.2011 23:05 )Lucki schrieb:  ob logisch - k.A, aber auf jeden Fall sinvoll. Die Korrektur erfolgt ohne Fehlermeldung oder Warnung und es ist nicht zu erkennen, daß so eine Korrektur stattgefunden hat - außer natürlich bei der händischen Eingabe selbst.
Man würde sich totsuchen, wenn wegen so einer Werteinschränkung ein ungewollt falsches Ergebnis herauskommt.
..

Daran hatte ich nicht gedacht.
Allerdings ist das Ergebnis ohne die Einschränkung der Eingangswerte auch nicht valide - der Eingangsbereich soll ja gerade eingeschränkt werden um das Ergebnis im gültigen Bereich zu halten.

(19.12.2011 23:05 )Lucki schrieb:  ..
Oder anders gesagt: Hätte man das gemacht, dann hätte man auch dafür sorgen müssen, das jedes Control außer seinem Wert-Ausgang noch einen zusätzlichen boolschen Ausgang "Wert wurde geändert" hat. Denn so eine Information wäre wesentlich. Diese Verumständlichung von Controls hat NI sinnvollerweise unterlassen - ..

Das wäre in der Tat nicht gut.
Und die Rückmeldung erhalten zu können, ob der Werte geändert wurden ist notwendig.

(20.12.2011 02:27 )rolfk schrieb:  ..
Hauptsächlich weil es versteckt ist und nicht einfach sichtbar dokumentiert. Das kann sehr unschöne Ergebnisse geben, die nur bei genauer Kenntnis dieses Features überhaupt auffindbar sind.
..

Das trifft für das Front-Panel aber auch zu. Der ein oder andere Benutzer wird sich sicherlich wundern, wenn er bestimmte Werte nicht eingeben kann.

(20.12.2011 02:27 )rolfk schrieb:  ..
Die explicite Programmiering mit Wertebereich prüfen ist da viel besser.

Ja, klar.

Danke für die Erläuterungen.

(20.12.2011 14:50 )unicorn schrieb:  Das trifft für das Front-Panel aber auch zu. Der ein oder andere Benutzer wird sich sicherlich wundern, wenn er bestimmte Werte nicht eingeben kann.

Das ist aber nicht dasselbe. Es ist durchaus üblich um im User Interface einer Applikation Einschränkungen beim Bereich von Parametern zu erzwingen. Dass das Kontroll das direkt kann ist dabei schön und wäre programmtechnisch doch etwas aufwendiger, da man jeweils einen Eventstrukturframe dafür programmieren müsste. Aber wenn Du das VI nicht selber programmiert hast und es dann als SubVI benützt, und der Wertebereich der eingestellt wurde vielleicht nicht so sinnvoll ist, wunderst Du Dich erst mal sehr gross, dass ausserhalb des VIs Zahl X ist und innerhalb plötzlich Y.

Die Wertebereichbegrenzung ist ein Feature des UI Kontrolls. Dass dieses UI Kontroll auch als Interface für den Parameter beim SubVI dient ist eine ziemlich sinnvolle Idee, aber das heisst nicht dass es dabei die Attribute des UI Kontrolls übernehmen soll. Oder was sollte bei der Benützung eines SubVIs passieren wenn ein Kontroll das mit einem Parameter verbunden ist, disabled ist oder gar unsichtbar gemacht wurde? Logisch und konsequent ist es darum, um alle Attribute beim Darstellen des Kontrolls zu berücksichtigen, aber nicht zu betrachten wenn das Kontroll als Parameter verwendet wird

Und Lucki hat auch noch einen Grund angegeben. Einfach so versteckt den Wert Ändern ist ziemlich hinterlistig, aber wie sollte LabVIEW das bekannt machen, dass eine Wertebereicheinschränkung stattgefunden hat. Logisch wäre um hier eine Dialogbox anzuzeigen . Glücklicherweise sind die LabVIEW Entwickler aber intelligenter, dann dass sie sowas tun.

Und wie gesagt, LabVIEW hat vor langer Zeit den Wertebereich auch bei Parametern eingeschränkt, aber die Anfragen für technischen Support in diesem Zusammenhang waren ziemlich enorm, weil viele Leute eben nicht erwarteten, dass ein subVI solche versteckten Sachen tut. Darum wurde darüber nachgedacht und beschlossen, dass solche Funktionalität tatsächlich nicht gerade sehr intuitiv ist und wurde es entfernt, und dafür die Wertebereich erzwingen Funktion hinzugefügt.