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 .

Similar Messages

  • 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 .

  • 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

  • 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.
    >
    >

  • 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.

  • Casting inside a "formula node"

    Greetings,
          Is it possible to cast a U32 to a SGL - an int32 to a float32 - inside a formula node?  How?
    Thanks!
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

    Re: Is there a particular reason you are attached to the formula node?  
    Well... we're just experimenting with the fastest way to unpack ~10,000 U32s into ~40,000 DBLs.  The packed array is U32-aligned mixture of bit-mapped integers, bools, and floats - SGLs and DBLs.  We've tried doing some "vector" (array) shift, mask and scale operations - which are pretty fast, but the float-unpacking seems to require a loop.  After timing a For Loop structure, I wanted to push the for loop into a formula node - where I've hit a wall (without ability to cast) ...
    Since the whole purpose of looking at formula node is to save time, I'm reluctant to roll my own "cast" function.
    Thanks/Cheers!
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

  • 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.

  • Formula Node Floor(x) Produces Different Result

    Hi, A search didn't find anything about the Floor(x) function, so... I'm using LabVIEW 6.0.2, and the Floor(x)function in a Formula Node seems to be producing different results depending on previous calculations. I've got the following 2 lines in a Formula Node:
    MSS = Ref / RefDiv;
    MDN = floor(RF / MSS);
    Ref is always 20.0M, RefDiv always 500.0, and for this calcualtion RF is always 1539.4, all numbers Double with 6 digits of precision. I generate an array of frequencies given a start, step, and frequency count. These frequencies then go to a subVI with a Formula Node that calculates the byte values to send to a couple PLLs.
    If Start = 70.1, Step = .025, and Count = 20, at frequency 70.2 the Floor function gives 38.485.
    If Start = 70.0, Step = .025, and Count = 20, at frequency 70.2 the Floor function gives 38.484.
    I've omitted some calc steps here, but I've verified the starting values in the subVI are the same in both cases. Why the result changes I'm hoping someone can tell me...
    Thanks,
    Steve

    I want to thank those involved again for their help. With ideas and hints from others I found a solution without scaling.
    In recap, what had bothered me was it *appeared* like the same subVI was giving correct results one time and incorrect results only randomly. While I understand binary fractional imprecision, I wasn't doing any looped calculations 100+ times or anything.
    I did some more checking though. The problem was indeed introduced by cumulative fractional addition. In this case 10 additions were enought to cause the error. Apparently, floor(71.199_94) produces 72.0. However, using a shift register and constant fraction to add an offset to produce an array introduces enough error in under 10 iterations to be a problem. By the time the loop got to what was supposed to be 72.0, it was actually 71.199_84 or something, enough to throw the floor function. Now I understand why the error occurred, and why it wasn't a problem before.
    I fixed this problem by changing the real frequency number to a I32 before introduction to the formula node. This corrected the error introduced by the fractional addition by forcing 71.199_84 to 72, instead of letting it propagate through the rest of the calculations. And it was a whole lot easier than changing all the VIs to allow scaling! Also, I prefer to know where and why the problem happened, instead of just scaling all my calcualtions. Maybe I can recoginse potential problems in the future.
    My boss wants to go back and look at his program to see if HPVee somehow bypassed the problem or if he did the calculations differently.
    Thanks again for the insight and help,
    Steve

  • 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

  • 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

  • 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 .

Maybe you are looking for