<div align="left">Hi,
ich habe folgendes Problem:
Ich möchte eine Variable (u) je nach Größe einer zweiten Variable (uxy) setzen:
sl und su sind variablen die die Größen des Bereiches enthalten.
In C würde das so aussehen:
if (uxy<sl)
{
u=0;
}
else if (uxy>su)
{
u=255;
}
else
{
u= ( (uxy-sl)/(su-sl) ) *255;
}
Wie kann ich das in einem Formelknoten in der bescheuerten LabVIEW-Syntax eingeben.
Ich habe bisher folgendes:
int8 u = (uxy>su) ? 255: (uxy<sl) ? 0
(uxy-sl)/(su-sl))*255;
Leider verhält er(LabVIEW) sich nur für den ersten Fall richtig, ansonsten spuckt er immer den Wert von su aus.
Schonmal vielen DANK....</div>
Hallo nabla,
den Formelknoten kannst Du doch in C programmieren.
Gruß,
Marko
' schrieb:Hallo nabla,
den Formelknoten kannst Du doch in C programmieren.
Gruß,
Marko
Tatsächlich... Mann und ich fummel mich hier durch diese bescheuerte NI-Syntax...
Vielen Dank, warum schreiben die das bei NI nicht einfach hin...
mfg
nabla
Also in LV selbst würde es so aussehen und ist mindestens genau so schnell wie ein Formelknoten oder ein eingebundenes C-Programm:
[
attachment=4199]
Finde so geht's sogar noch einfacher.
Und mit Aussagen wie "bescheuerter LV Syntax" machst du dir hier keine Freunde
Zitat:Ich habe bisher folgendes:
int8 u = (uxy>su) ? 255: (uxy<sl) ? 0(uxy-sl)/(su-sl))*255;
Die Zeile ist mir rätselhaft.
Und wieso soll die "LabVIEW-Syntax" bescheuert sein? In den Formelknoten ist exakt dasselbe einzugeben, was nach Deinen Worten "in C so aussehen würde".
Probleme sehe ich allerdings, wenn Du als Ergebnis der Division ein INT8-Zahlenformat vorschreibst. Das führt zu falschen Resultaten, und zwar ohne Fehlermeldung, wenn das Ergebnis nicht in diesen Zahlenraum reinpasst. Ein originales C-Programm würde da auch nicht helfen.
' schrieb:Finde so geht's sogar noch einfacher.
Aber natürlich, an diese Möglichkeit hatte ich gar nicht gedacht!
Aber nicht nur das, auch die Formel-Syntax läßt sich noch etwas vereinfachen, es geht auch ohne else:
[
attachment=4204]
Der edle Wettstreit um den besten Code geht in die nächst Runde. Das hier schmeiße ich in den Ring:
[
attachment=4205]
(Das U8-Format schränkt den Berich von selbst auf 0..255 ein)
Angemerkt sei noch, daß es mit I8-Format für u (bereich -128..127) von Nabla natürlich nicht funktionieren kann.
Dein Code hier wird an Kürze wohl nicht mehr zu toppen sein.
Wobei ich anmerken möchte, dass hier die Eleganz auf Kosten der Allgemeinheit (soll heißen auch andere Werte als 0/255 bei Grenzüberschreitung)des Problems entsteht.
Hab nach längerer Zeit mal wieder hier reingeschaut... Danke für die vielen tollen Beiträge und mit meinem "bescheuerten LabVIEW-Syntax" wollte ich nicht andeuten das LabVIEW bescheuert ist, nur das ich nicht wusste dass man einfach C eintippen kann und daher mich über mich selbst geärgert habe auf Grund meiner Fummelei mit der NI-Systax.
Danke nochmals an alle...
P.S. Wenn man sonst viel in C programmiert, hat man immer einige Probleme sich an die graphische Programmierung in G zu gewöhnen. Daher mein Formelknoten. Es ist natürlich keine Frage, dass es bestimmt einfacher geht !
' schrieb:Ich habe bisher folgendes:
int8 u = (uxy>su) ? 255: (uxy<sl) ? 0(uxy-sl)/(su-sl))*255;
Leider verhält er(LabVIEW) sich nur für den ersten Fall richtig, ansonsten spuckt er immer den Wert von su aus.
Hmm vielleicht wäre hier Operator Reihenfolge noch eine Ursache. Was gibt denn:
int8 u = (uxy>su) ? 255:
((uxy<sl) ? 0
(uxy-sl)/(su-sl))*255
);
Gemäss ANSI C Operator Reihenfolge hat der Bedingungsoperator eine sehr tiefe Priorität, die nur durch Zuweisungen oder dem Komma-Operator noch unterboten wird.
Rolf Kalbermatter