Formula Node label bug?

A last one for this week (hopefully)...
Drop a formula node on the BD and show its label:
Now resize the Formula Node from the top:
Oops! The formula node got stuck in its original position. I do not know of other objects label behaving like that.
Tested in LV 2011.
Solved!
Go to Solution.

Ravens Fan wrote:
I guess no one has ever felt the need to label a formula node AND resize it after doing so.
... and most people would probably resize from the bottom right anyway...
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

Report of an apparent formula node casting bug

The attached LLB contains a vi (casting vi.vi) that causes LabVIEW to crash on my installation (6.02, Windows 2000). The crash is apparently related to a problem with automatic type-casting after a formula node, and inside a VI. The attached VIs were constructed from scratch to duplicate the crash, so it's not a corrupted file problem. Having isolated the problem this far, I can easily work around it; but I thought I should also report the issue, since I don't find it on your web site after a trying couple of different search strategies.
Attachments:
cast_failure.llb ‏23 KB

It seems the problem has been fixed: It does not crash under LabVIEW 6.1 or LabVIEW 7. (I can reproduce the crash under LabVIEW 6).
LabVIEW Champion . Do more with less code and in less time .

Serious bug in LabView 8.5 Formula Node

Hello,
Thought I would warn my fellow LabView programmers about a serious error in the Formula Node:
The problem may be encountered by anyone running a non-us LabView installation:
I am located in Norway, and over here we use the comma (,) as the separator in floating point numbers: So, the use 3.14 is written like 3,14.
The problem is that the Formula Node accepts both formats, but only the US Notation is interpreted correctly !
Example:
float64 x1, x2;
x1 = 3.14;    // Interpreted Correctly !
x2 = 3,14;     // Interpreted as 3: One might say this leads to problems.......
Message Edited by geirove on 06-13-2008 06:23 AM
Geir Ove

geirove wrote:
JoeLabView wrote:
Hi Geir,
It is not a bug.  ............
The node does not recognize localized decimal separators."
Of course it is a Bug: **Any** code that **any** compiler does not recognize, should be flagged with an error message ! I have written my share of compilers myself, and they all flag down code that is not accepted as an error.
Failing to do so may cause serious, expensive and very hard to trace errors.
Sorry, but I would expect that the NI team in their 20. year of LabView development is capable of better than this.
Sorry to disappoint you! It's not a bug since that statement is absolutely valid albeit useless in that context.
The Formula Node since LabVIEW 7 supports C syntax except some advanced features such as pointers. In C the comma in expressions is the sequence operator meaning it separates expressions that will be executed from left to right and the last one will actually be the result of the entire sequence expression. This is often used for the initilizer expression inside the for statement, to initilize several variables to a start value.
And the NI team really is a lot better than you think. The online help may be a bit short about the reasons why the comma is not supported as decimal point but there have been many people thinking about this before it was made like that. It was either C syntax support without localized decimal point or some homegrown syntax with localized decimal point and they went for the first.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Formula node bitwise OR has a bug?

Hello everyone,
I am trying to do a bitwise OR with 32 bits in an formula node. It seems that the OR operation produces unexpected results if the most significant bit is set. For example if I do:
0x00000000 OR 0xffffffff I would expect 0xffffffff. Instead I get 0x80000000. In binary this looks like:
00000000000000000000000000000000 OR
11111111111111111111111111111111 EQUALS
10000000000000000000000000000000
Please see the attached minimal example for comparison of some example values. The output with using blocks is exactly the one I would expect and is also included in the example.
I am using Labview Version 14.0f1 on Windows 7 Professional.
This might also be in connection with the following currently unresolved bug:
48016
3P7CBB4Q
http://www.ni.com/product-documentation/52150/en/#48016_by_Category
However that that bug is for unsigned int32 and the suggested workaround is to use signed 32 bit integer, which nevertheless fails in the provided example code.
If someone could have a look and tell me if this is a bug or if I am misunderstanding somtheing that would be great. I am already starting to go crazy.
Best regards and thanks in advance
Saali
Attachments:
Minimal_Bug_example.vi ‏10 KB

No, actually this bug is different from what is documented.The documented bug happens with uInt32 and the documentation specifically suggests to use Int32 as a workaround for the known bug:
"2. Use signed 32-bit integers instead of unsigned 32-bit integers in the formula node."
However this is exactly what fails in my case when I use OR. I thought this might be some valuable information for the people trying to fix that bug. (Which seems to be hard to find, as it has been around so long and screws up very basic operations.)
It might also be that NI does not really care for that bug because most people don't use the formula node for basic bit arithmetic. Anyway, I just wanted to put the information out somewhere for the next person who has that problem to find. I guess the lesson I learned from this conversation is don't trust the formual node to much for doing low-level bit stuff...
Best regards
Saali

BUG: Arithmatic shift right in expression and formula node

Don't believe this isn't a known bug, but I couldn't find it... Tested in
LV7.1 and LV8.5.
In an expression node, if you use the << operator, the function produces
wrong results if the input isn't an I32. For instance, x<<1 in an expression
node, with an U8 as input:
1 result 2
128 result 255 WRONG, should be 0!
130 result 255 WRONG, should be 4!
The normal shift function is correct (I used it to compare the results,
after I noticed that C results where different). Also, the function works
correct when used for U32's (e.g F0000002 results in 4) or I32's. When an I8
is used, results are limitted to 128. U16's and I16;s fail as well.
As a work around: convert the input to U32, and afterwards to U8.
In a formula node, create an aditional input that is an u32: "T32=T8; var=
T32<<1;" might work in a lot of cases...
Regards,
Wiebe.

LabVIEW 8.6.1 and bug still here:
Compared with CVI C compiler and Intel C++ Compiler - both return zero. But formula node returned 255.
I've lost more than hour for looking trobles in my code, but it was behaviour of shift!
Andrey.

Bug using array in formula node, LV6.0

Pass a 3-element integer array, containing values 5, 6, 7 into a formula node as input variable x. Pass variable y out. The formula node contains:
int32 y;
y = (x[2]-x[1]);
My result is 6. If the parentheses are removed, the answer is 1. Apparently adding the parentheses causes the expression to be evaluated as y = x[2-1];.
Has this been found/fixed? I have mailed NI separately.

In 6.0.2 it returns 1 in both cases.
"Adam Russell" wrote in message
news:ajcc8d$1a266r$[email protected]..
>
> "Bill Atkins" wrote in message
> news:[email protected]..
> > Pass a 3-element integer array, containing values 5, 6, 7 into a
> > formula node as input variable x. Pass variable y out. The formula
> > node contains:
> > int32 y;
> > y = (x[2]-x[1]);
> > My result is 6. If the parentheses are removed, the answer is 1.
> > Apparently adding the parentheses causes the expression to be
> > evaluated as y = x[2-1];.
> > Has this been found/fixed? I have mailed NI separately.
>
> It works correctly in 6.1. I'm at home so I can't t
ry it in 6.02.
>
>

Can I use a formula node to start the execution of a case structure?

Hi,
I am working on editing a VI to make it much easier to understand (for colleagues and non LV users). For one reason or another, the VI's creators did not fully make use of the power of case structures and other structure types. In the application we need it for, the instrument cycles and repeats measurements on several objects. We are interested in measuring the motor currents for several motors in the system. As it stands now, for each sample object's run, there is a separate sub-vi diagram which displays its waveform trace and several indicators such as max current, time at max, etc. That code was contained within a T/F case structure and copied and pasted 20 plus times.... Obviously the vi became extrememly cluttered and needed a huge screen to see. The trigger for the current case structures is an EQUALS comparison between one input (which is the sample object counter; and this part I will likely leave unchanged since it makes a lot of sense already) and a constant which was defined 1 through 20+ for case.
I have since made one case structure and 20+ instances of that case and have labeled them (at the top selection box near the detent arrows) "1", "2", 3, etc. I am wondering if I can use a formula node to act as the "trigger" which sets each case structure running? I believe that a simple IF statement should work. Please see a snippet of my attempt at making this in C below.
For the node, I defined X as the input and Y as the output. The input to the node, X, is connected to the sample object counter. The output, Y, is connected to the case selector of the case structure. My attempt at the code is below:
int32 y
For(x == 1)
y = "1";
For(x == 2)
y = "2";
etc, etc.
Is that above code snippet correct? Do i need something like "ENDIF" or "end if" at the end? Does "y" have to be defined as "int32" or can it be something else?
Thanks for the help!

Is your formula node doing anything else besides what is shown?
Why don't you just wire the value that is going into it at X directly into the selector of the case structure?
Attachments:
Example_VI_BD.png ‏2 KB

Problems with bit shift left in Formula Node

Hi,
Sorry but my English is not good.
I'm trying to execute a bit shift left in the Formula Node, but the shift left is not working as I expected.
uInt32 parametro[5];
float32 valorAmostra;
int16 indiceAmostra;
uInt8 indiceResposta;
int16 controle;
int32 valor;
int8 i;
for(i=0; i<5; i++)
parametro[i]=param[i];
valor = parametro[5]<<16 | parametro[4]<<8 | parametro[3];
controle = parametro[1]<<8 | parametro[0];
indiceAmostra = (controle & 0x3FF);
indiceResposta = (controle >> 10);
valorAmostra = valor & 0x7FFFFF;
valorAmostra = valorAmostra*(2.4/8388607);
if((valor & 0x800000) == 0x800000)
valorAmostra = valorAmostra*(-1);
the input param array is of the type uInt8, as I saw in other topics that does not shift with uInt8,
I copy the values of param array to parametro which is of type uInt32, but still did not work.
Testing the input param with the following values:
param[] = {10,14,10,0,16}
the valorAmostra returned is 0,00117188 when he should be 0,300003.
Can someone help me please?
Solved!
Go to Solution.

Portuguese:
Olá,
Existe um bug no LabVIEW para esta operação. Este bug deverá ser corrigido em versões futuras. Uma solução para esta situação é utilizar um int32 ao invés de um ulnt32.
Qualquer dúvida por favor entre em contato.
Obrigado.
English:
I investigated the problem you are having, and it turns out that it is a bug that has already been reported and documented. The work around for it is to use int32 rather than uInt32.
Thanks.
Luciano Borges
R&D Engineer
Pirelli Brazil

LV 6i: Serious Formula Node problem!

I have found a "serious" problem converting VI from LV 5.1.1 to 6i:
I have same "big" equations for density calculation with upper 65 coefficients
and 3 o more inputs variables.
Everything goes well and fast in 5.1.1, when I open this VI in LV 6i there
is automatically conversion
of exponential symbol (from "^" to "**") with non apparent problem,
but the result of equation is WRONG, very, very incorrect (from 0 in 5.1.1
to same negative milliard...).
I tried with more different equations and the results are similar...
For the last: when I re-convert my VI in version 5 and run it in LV 5.1.1
everything re-work PERFECTLY! Strange.
Have I found a "terrible" BUG?
Someone have found the same problem?
Do you have some ide
a?
I will wait some news from you.:-)
Thanks for reading this LONG news.
Bye, bye.
Alfio.

"Alfio" wrote:
>>I have found a "serious" problem converting VI from LV 5.1.1 to 6iI have
same "big" equations for density calculation with upper 65 coefficients>and
3 o more inputs variables.>Everything goes well and fast in 5.1.1, when I
open this VI in LV 6i there>is automatically conversion>of exponential symbol
(from "^" to "**") with non apparent problem,>but the result of equation
is WRONG, very, very incorrect (from 0 in 5.1.1>to same negative milliard...).>I
tried with more different equations and the results are similar...>For the
last: when I re-convert my VI in version 5 and run it in LV 5.1.1>everything
re-work PERFECTLY! Strange.>Have I found a "terrible" BUG?>Someone have found
the same problem?>Do you have some idea?
>I will wait some news from you.:-)>Thanks
for reading this LONG news. >Bye, bye.>Alfio.
Hi Alfio
Some times ago I had a simmilar problem but with labview 4.x. My equation
in the
formula node was (and still is) very large too but the problem was related
with the
x^2 terms. When these terms were changed with x*x the vi worked fine. Very
strange.....Also, this problem did not appear with small equations. Try a
smaller equation and see what happens. And more: with LV 5.1 (I am using
this version)
there is no problem.
Good luck.
Ricardo.

IF statement in Formula Node

I have the following statement in a Formula Node in LabVEW 7.1:
if (x=1) y = 3; else y = 1;
When running the VI, whatever the value of X is, I obtain Y = 3 !!!!
Why ???
Tom

Try x == 1 (instead of x = 1).
Using LV8.0
Don't be afraid to rate a good answer...

If-then statement in formula node

**Note - The attached file shows the current block diagram.
I have a formula node inside a for loop. Inside the formula node I am trying to program the if-then statement:
If T1<2.0E-5 OR T1>5.5E-4 THEN GOTO 3
U7=U7+V
I have 4 items I need help with:
(1) Is 'II' the correct operator for 'OR'?
(2) Is 'goto' an acceptable operator within LabVIEW?
(3) 'U7' is building a 1D array. How do I need to define it? Is it simply 'int U7'? Also, I will add an output value named 'U7' on the formula node wall with an indicator wired to it from outside the for loop.
(4) Is my use of the equal sign appropriate or do I need to use '=='?
Thanks for the help.
Philip
Attachments:
if-then_in_FN.jpg ‏18 KB

Thanks for the help. I went ahead and rewrote the program so I could omit the 'goto's. Another problem that I am having is that I want 2 statements for 1 assignment:
if (T1>=.002004 && T1<=.002584)
B1=U
A1=V;
I want to assign both B1 and A1 values when the above condition is true. I tried a comma between the U and A1 but it doesn't work as well. Should I define A1 and B1 separately? Or would this create problems?
if (T1>=.002004 && T1<=.002584)
B1=U;
if (T1>=.002004 && T1<=.002584)
A1=V;
Thanks,
Philip

How do I get an array output on a Formula Node?

My problem is simply that I cannot figure out how to get an output on a Formula Node to be an array. Documentation states that "you must declare local arrays and output arrays in the Formula Node" but doesn't say anything more than than. Attempts to put something like "float32 out[100];" for an array output called "out" fail.
If anybody knows how you can do this or even knows if it is possible I would appriciate your help.
Thanks,
Naveen

I found a typo in the formula node I was doing that was making the output not be an array. I don't think I was getting the error before but I was going to put together an example VI to attach here and I found it. So, thanks for your help even tho it was a stupid little mistake on my part.

"Eval Parsed Formula Node VI" does not return outputs in predefined order

I make a data analysis program, where the data consists of some million events and each event has e.g. 4 channels and 1-5 hits on each channel.
I would like the user to select different expressions of these channels to give coordinates to plot in a 2D histogram (increment a bin in Intensity Graph), e.g. for some experiment you want to show x=ch1-ch2; y=ch1+ch2+ch3+ch4; while in another experiment you want x=ch1-123; y=123-ch2;
There are other VIs that use static LabView-code for the normal things, but now after a few years of adding to this program I find that it would be quite good with a general plotter and let the user specify simple expressions like this. Also with the "normal" static plots, there is a need to filter out bad data and then it would be much simpler both to program and use if you could write text expressions with boolean logic to combine multiple filters. Making a LabView code and GUI that allows AND/OR/parenthesis combinations of expressions will be quite an effort and not very reusable.
So, with the above motivation, I hope you see that it would make sense to have a useable string formula evaluator in LabView. I find some info about MathScript's user-defineable functions, but haven't managed to get MathScript working in LV2010 yet (maybe some licensing or installation issues, I think I had it in 8.6). But I think it would be possible to do most of what I want for the display-part (not the filtering) with the simpler Eval/Parse Formula Node VIs and suitable use of the limited variable name space. So I started testing, and found a quite annoying issue with how the evaulator works.
To the parser, you are expected to send an array of output variable names. But then it ignores this array, and returns one output per assignment/semicolon in the formula, in the order of the formula text. Since the static parts of my program need to know what the output values mean (which of them is x and which is y), I would have to rely on the user not using any intermediate variable and defining x before y. The attached screenshot demonstrates the problem, and also that it has been solved by NI statff in the "Eval Formula Node VI" which does the appropriate array-searching to extract only the pre-defined outputs, in their expected order. But using that VI is about 100 times as slow, I need to pre-compile the formula and then only use the evaulator in the loop that runs over a million events.
I don't know if I'll take the time to make my own tweks to the parsing stage (e.g. preparation of array-mapping to not have to repeat the search or maybe hacking the output list generated by the parser) or if I'll have to make it in a static Formula Node in the block-diagram (which supports more functions), so that the user has to run with development environment and stop the program to change the plotting function. But I wanted to share this trouble with you, in hope of improvments in future LabView versions or ideas from other people on how I could accomplish my aim. I have MATLAB-formula node possibility too, but is far as I have seen the only place the user could update the formula would then be in a separate .m file, which is re-read only when typing "clear functions" in the Matlab console window. (Having this window is also an annoyance, and perhaps the performance of calling Matlab in every iteration is not great.)
Besides this issue, it also seems very strange there is virtually no support for conditional expressions or operators in Formula Node evaulated formulas (called Mathematics VIs in the documentation). Maybe using (1+sign(a-b))/2 you can build something that is 0 when a<b and 1 when a>b, but it is not user friendly! Would it really be diffcult to add a function like iif(condition, return_value_if_true, return_value_if_false) to replace the unsupported "condition ? if_true : if_false" operator? Would it really be difficult to add support for the < <= >= > == || && operators? Although compiled to an assemply language, this can't exactly be difficult for a CPU.
Attachments:
LV script test.png ‏62 KB
LV script test.vi ‏18 KB

(1) You can put any kind of code inside an event structure with the limitation that it should be able to complete quickly and without user interaction. For example a while loop for a newton-raphson method is fine, but an interactive while loop where the stop condition depends on user iteraction is not recommended. By default, event structures lock the front panel until the event completes, so you would not even be able to stop it.
(2) Yes, you can do all that. LabVIEW has no limitation as a programming language. Use shift registers to hold data and state information, the manipulate the contents as needed.
(3) I would recommend to use plain LabVIEW primitives instead of formula nodes. Show us your code so we can better see what it's all about. Obviously you have a mismatch betweeen scalars and arrays. It is impossible from the given information where the problem is.
(4) Yes, look inside the nonlinear curve fit VI (you can open it an inspect the code!). One of the subVIs does exactly that. Just supply your model VI.
LabVIEW Champion . Do more with less code and in less time .

Formula node

Hi everyone.
I have a problem with the formula node.
I want to calculate the following function:
Ux=xdot+Omegat*(y-y0)+thetax
where xdot, Omegat, y, thetax are all 1D arrays ( honestly these are waveforms but I convert these in arrays) while y0 is a constant. Also the output Ux has to be a 1D array.
When I implement the formula in the appropriate box I receive a message about
"array indexing indices".
For more information I link my .VI.
Some idea how to solve this task?
Second question:
Using the formula node is faster than realize all these operations in a
different way?
I ask it because I will need to include this .VI into 5
different "for loops"?
Thanks
matomato
Attachments:
formula node.vi ‏87 KB

Hi matomato,
fastest is usually to use LabView primitives! See attachment...
Edited: made another small change to your vi: changed y0 to DBL to avoid unneccessary datatype conversions!
Message Edited by GerdW on 02-27-2008 05:11 PM
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Attachments:
formula node1.vi ‏87 KB

Formula node uInt32 overflow

I'm having a weird behaviour in formula node. The overflow of unsigned integer operations simply doesn't match the results of standard LabVIEW blocks as shown in the attached picture.
How can I deal with this problem? I need the behaviour of the block diagram. I could not do a right logical shift in unsigned integers in block diagram, so I'm using formula node (I could not figure out how to do it because I can't negate a unsigned value).
I'm using LV2012SP1. Were there any changes in this behaviour in newer versions?
Thank you.

I found a problem in hexadecimal and octal numeric representations of the formula node. The picture illustrates the issue. Three variables are assigned with the same value but outputs different results.
The hex and octal representations only work for half range of the 32 bits unsigned integer. When the value assigned gets beyond this limit the variable receives zero. This doesn't happen with a decimal value neither with 8 bits variables. Seems the problem doesn't only happen with overflow operations.

Formula Node label bug?

Similar Messages

Maybe you are looking for