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

Similar Messages

Serious Bugs in LabVIEW 2011

Dear Sir or Madam,
I have been working with LabVIEW for 10 years.
recently I have istalled the last version (LabVIEW 2011) and encountered some fundamental Bugs as bellow:
1-when I want to close LabVIEW 2011 Platform,it taks about 3 sec time to be closed ! while this was not in earlier version such as LabVIEW 9 sp1.
2-In a typical Front Panel,when I press Ctrl+M to chenge to Run mode,it went but after pressing Ctrl+M again,it will not exit from run mode(THIS BUG HAPPEN SOME TIMES NOT ALWAYS) or when I do right-click to view Function pallet or Control pallet,nothing happen!(THIS BUG HAPPEN SOME TIMES NOT ALWAYS).
I will be happy if you tell me what is the reasons and can I trust on LabVIEW 2011 for big projects or It is better for me to used LabVIEW 2009 as the past.
thank you for your kind attention.
Regards,
Ata Rahai,
Specialist Engineer.

Hi
I believe that 2011 is a very stable version (I was beta testing) and in my system the CtrlM works both ways, always.
Taking a few seconds to close is normal since version 8.0, depending on how many services are running. LV does clean up the system.
greetings from the Netherlands

Array index problem in formula node

dear friend
I'm trying to use formula node to solve a problem because I make this program using c at the begining.
It runs perfectly in turbo c, but somehow it doesn't work in the formula node.
I try to debug my source code, and I find that the formula node seems can't read the true value in
the array.
Here is the code in the formula node.
int32 i,j,k;
for ( i = 0 ; i < sopa; i++ )
j = 1;
ep[i][0] = pa[i];
ep[i][1] = np[ep[i][0]][0];
while ( ep[i][j-1] != exit )
  for ( k = 0 ; k < sonp ; k++ )
    if ( np[ep[i][j-1]][k] != -1 && (pc[ep[i][j-1]][ep[i][j]] + pc[ep[i][j]][exit] >= pc[ep[i][j-1]][np[ep[i][j-1]][k]] + pc[np[ep[i][j-1]][k]][exit] ) && (pc[ep[i][j-1]][np[ep[i][j-1]][k]] == org[ep[i][j-1]][np[ep[i][j-1]][k]] ))
      ep[i][j] = np[ep[i][j-1]][k];
  j++;
This is the part that I think the problem might be.
if ( np[ep[i][j-1]][k] != -1 && (pc[ep[i][j-1]][ep[i][j]] + pc[ep[i][j]][exit] >= pc[ep[i][j-1]][np[ep[i][j-1]][k]] + pc[np[ep[i][j-1]][k]][exit] ) && (pc[ep[i][j-1]][np[ep[i][j-1]][k]] == org[ep[i][j-1]][np[ep[i][j-1]][k]] ))
ep[i][j] = np[ep[i][j-1]][k];
I state that "np[ep[i][j-1]][k] != -1" but I do get the value -1 in the array "ep".
Could someone tell me why I get -1 in the array?
I hope I can finally do it all by labview not using formula node,but array like "pc[ep[i][j-1]][np[ep[i][j-1]][k]] "
seems very hard to wire in labview. Could someone give me some good advices of doing this?
Thanks for your help

altenbach 已寫:
normanshi wrote:
ep[i][0] = pa[i];                                          (A)
ep[i][1] = np[ep[i][0]][0];                            (B)
...    if ( np[ep[i][j-1]][k] != -1 && ... )          (C)
      ep[i][j] = np[ep[i][j-1]][k];                       (D)
I state that "np[ep[i][j-1]][k] != -1" but I do get the value -1 in the array "ep".
Could someone tell me why I get -1 in the array?
I hope I can finally do it all by labview not using formula node,but array like "pc[ep[i][j-1]][np[ep[i][j-1]][k]] "
seems very hard to wire in labview. Could someone give me some good advices of doing this?
There are many possible scenarios to get a -1 in the ep output. For example if the -1 gets already written in step (A) or (B) at a certain index, and that index does not get overwritten in step (D). You are indexing all over the place! Is there some bounds checking on the array contents? What are typical inputs and array sizes?
I'm sure about that the -1 doesn't get already written in step (A) or (B) because ep[i][0] and ep[i][1] is fine. What really makes me confuse is that sometimes ep array has the value like this.
That means it does overwritten some value in step (D). The -1 should never be written into it because I have already state that np[ep[i][j-1]][k] != -1. Somehow I still get -1,and this is really strange! I'm indexing all over the place becuase I can't figure out a better way to achieve my requirement.
I think I should briefly tell you what I'm trying to do. In this program,I input some values which means the distance from one point to another. Then I use floyd's all pairs shortest-path algorithm to find all the shortest distance. Finally I want to find out the "shortest path". I mean like from point 4 to point 0,the shortest path might be like 4 -> 2 -> 1 -> 0, and what the formula node part do is trying to find out this "shortest path". Maybe you can give me some better advice of doing this, I have been thinking a better way to do it for about two months. I think I'm really not good at this.
I try to do it all by labview ,but again I get a strange problem. This time the ep[i][j-1] doesn't get the correct value. In the first time i=0 j-1=0 ep[i][j-1] = 1,but the second time i = 0 j-1 = 1 ep[i][j-1] = 0. This makes the "ep[i][j-1]!=exit" get the incorrect boolean value. The ep[i][j-1] should be 2,not 0. I try to use highlight to find if I make any mistake, but I can't one.This is the input and I put the labview program in attached file (temp4.vi).
Could you help me find out why this happened?
Thanks for your help altenbach!
由 normanshi 在 08-19-2006 10:06 PM 上編輯的訊息
Attachments:
temp4.vi ‏191 KB
ep.jpg ‏10 KB
input.jpg ‏9 KB

Bug in Formula node under LabVIEW 2010

appendix is my test project.
there is a test.vi in the project. The test.vi contains only a case structure with 5 SAME subdiagrams. Each subdiagram contains a formula mode. The formula code does some calculation with an 2d array of double.
If i run the test.vi under LabVIEW 2010(or SP1), it may cause LabVIEW 2010 corrupt occasionally. If I build application form the test.vi, and run the application ,the application will definitely corrupt.
if I delete one subdiagram of the case structure , the test.vi and the application both run well.
however, the same project works well under LabVIEW 2009.
so is it a bug with LabVIEW 2010?
Attachments:
Test.zip ‏7 KB

'corrupt' means the program exit unexpectedly without any warning or error message. it just disappeared and you can't find it in the 'process' tab of windows task manager after that.
If LabVIEW corrupted, once i reopened it, there may be a error message dialog pop-uped before the LabVIEW interface appeared. The dialog said something wrong with 'undo.cpp'. I zipped the failure long to the appendix. I can't find any other error or warning message from LabVIEW or Windows ( I checked the Windows Event Viewer).
If the built exe corrupted, There isn't any message for LabVIEW or Windows neither.
I tested the project on my own laptop with Windows XP(SP3) Chinese Version and NI PXI-8810 with Windows XP(SP3) English Version which is my target machine.
Appendix also contain a exe build in my laptop. If I run the exe file, once I click the run button , it will corrupt. I wonder if it works the same on your computer.
Thanks for your concern.
Attachments:
lvlog2011-05-13-23-23-35.zip ‏150 KB

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.

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.

Serious bugs in the SR400 gated photon counter LabVIEW drivers

Hi
I am developing an application with SR400 and came
across what I think is a bug in the LabVIEW driver. Essentially, none
of the VI's allow you to set the preset counters. For instance, if you
call Read VI and choose mode A, B for preset T, there is no way to
specify preset T, which means that the count period defaults to some
factory default, not a situation you want. This might also explain some
of the timeouts some people are getting to SRQs that come later.
Further,
if you look at the block diagram of Read VI, the line selector string
is set to "CM 0" for two distinct choices of the count mode. This is a
serious bug. I do not know who wrote this driver, but it does seem, at
least to me, that they did a rather shoddy job of it. How this driver even got certification to be posted at IDN is something I cannot explain.
Comments welcome from those that use LabVIEW with SR400 and have used this driver.

Hi. Dwell time of 2ms is good for me. It would be great if you can send me this file to circumvent the 2000points/measurement. Also, If i understand it right, if I set the Gate to CW, then my gate should always be open for the count period, they why do I have to set the gate parameters at all. I want to change the integration time, but for some reason I am not able to change it in your setup 2.VI at all. I made some changes in setup 2.vi. I removed the setting for channel B as I am not going to use it and I integrated the readchannel.vi into this file. I am not sure if I made a mistake in doing this. Now, I am able to write some data to a file, but I not as I want. If it helps, I am uploading my modified VI file and an example data file (Gate A width is 0.992s, Gate A delay and delay step are 0, Gate A mode is CW, Dwell time is 0.002s).
Attachments:
SR400-V.vi.vi ‏125 KB

HELP: Run-time array dimension in LabVIEW formula node

I need to dimension an array at run time within a formula node as follows:
int32 i,N;
N = sizeOfDim(inputArray,0);
float64 outputArray[N];
for (i = 0; i outputArray[i] = myfunction(inputArray[i]);
However, LabVIEW complains "Formula Node: index list expected". On the
other hand, if I say
float64 outputArray[1000];
LabVIEW is perfectly happy. But that's not what I need to do! Is there
an alternative
way of accomplishing my goal?
BTW, I've tried calculating N outside the formula node and then
presenting it as
an input with the same results. I've got a bad feeling that run time
array dimensioning
just isn't allowed.
TIA,
Hugh

Can't you just use the Initialize Array function outside the formula node and pass that instead?

How to use matlab program in formula node in labview?

hi,
i've got one equation of voltage regulation. so i did create program for that in matlab.and want to use it in formula node in labview.but i don't know how to do that.can someone please help me for that?
regards
bhavin

If you have already written Matlab code it is easier to import it straight into a Mathscript node. If you use a Formula node you need to translate m- syntax to c-syntax which may take longer. Note that the Mathscript node
may not support all the functions you used in Matlab so you may need to replace them with native LabVIEW functions. If you want to add inputs/outputs in your program you can just right-click on the border of the node to do that.
These structures can be on the block diagram under Programming>> Structures.
KostasB
NI UK Applications Engineering
Message Edited by KostasB on 05-28-2008 08:39 AM
Attachments:
mathscript-form node1.PNG ‏8 KB

Applying delay in formula node in labview

hi every bod
Solved!
Go to Solution.

If you have not done so yet, please go through the free on-line tutorials about LabVIEW.
Rarely is the formula node the most appropriate way to write code in LV. The native LV constructs may be a bit awkward at first for someone with a text-based programming background. Once you learn to use dataflow and to recognize the functions by their icons, you may find that graphical programming can be both powerful and easy to read.
For delays use the Wait(ms) function found in the Timing palette. If you need a delay in the middle of a calculation (which seems unlikely), you may need to split the calculation into two parts and put the Wait (ms) between the parts. See the image below for one way to do this without any formula nodes.
Lynn

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 .

CPU efficiency: formula node or Labview generic operations?

Hello,
ihave a big program which requires to calculate a lot of analog ramps with 10us step size, for a time of about 20sec. it leads to a calculation time wich reaches fast the few seconds!
i use a formula node in which the ramp function is defined. i could use all normal labview operations if the operation appear to be faster.
i have looked at the usual memory allocations, and could not find a big flaw
... And here's where I keep assorted lengths of wires...

Don't forget that there is also a "ramp pattern" tool in the signal generation palette.
I always like the experimental approach: The best advice would be to wire up a few alternative version and compare speed and memory use in a small benchmarking application.
How many such ramps are in memory at any given time? Does your code generate extra data copies? What is the datatype? An 20M Sample ramp of DBL is 160MB!
LabVIEW Champion . Do more with less code and in less time .

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 .

Labview. Writing an equation inside a formula node

How would I write this equation chl= (4.9467*mv) - 0.3239 inside a formula node? Thanks
Solved!
Go to Solution.

You don't even need a formula node. An expression node would suffice.
LabVIEW Champion . Do more with less code and in less time .

Serious bug in LabView 8.5 Formula Node

Similar Messages

Maybe you are looking for