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

Similar Messages

  • 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

  • Strange problem of calling library function node in labview 2010 and 2011

    one year ago,I develop a program to usb device data and it works well,in labview 8.6 or 2009(win xp).Recently, When I test
    the program in labview 2010 and labview 2011(win xp).,the program always crash immediately.I check the program and find main
    problem is in call library function node. In my program,I use labview 2009 library for the USBExpress driver for
    Silicon Labs USB MCU's from:https://decibel.ni.com/content/docs/DOC-9522,for example, 2 functions SI_OPEN and SI_READ
    can not work well.
    the header definition of SI_OPEN and SI_READ is:
    SI_STATUS WINAPI SI_Open(
    DWORD dwDevice,
    HANDLE* cyHandle
    SI_STATUS WINAPI SI_Read(
    HANDLE cyHandle,
    LPVOID lpBuffer,
    DWORD dwBytesToRead,
    LPDWORD lpdwBytesReturned,
    OVERLAPPED* o = NULL
    the SI_STATUS is equivalent to int type.
    orignally, for HANDLE * in SI_Open, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass pointer to value.
    for HANDLE in SI_Read, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass value.The program works well in labview 8.6&2009,however,crash in labview 2010 &2011.
    later,I debug the program, for HANDLE *, I choose parameter type in call library function node as adapt to type, data format is point to Handles.for HANDLE, I choose parameter type in call library function node as adapt to type, data format is Handles by Value.Crash not happend in labview 2010&2011,however,it cannot read any data from from USB device correctly as before.I can not find the reason.
    Dear friends,I need your help to answer the problem. Thank you.

    Based on the help page it looks like it should execute asynchronously.
    The thing in the description that leads me to believe they execute asynchronously is that you can configure the library to run as a multi-threaded operation.
    Please take a look here to see the difference between synchronous and asynchronous execution.
    Since the code even has the ability to be multi-threaded, you can consider it as running in parallel to your other code.
    Any data returned is passed to the thread that called that function.
    Cory K

  • 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

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

  • 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 on PDA

    I'm using a formula node on Labview PDA and i have problem regarding multiplying double variable. If I multiply integer number (as double) everithing is OK.
    example 45*2 the results is 90.0
    If I multiply 2 fractional number the solution is wrong:
    example 45*2.5 the results is 112.0705032 and there is some strange features inserting the values inside the number control.
    I Attach the source code and the PDA executable (to convert Lat, Long coord. to UTM) in order to undestand the problem. I you remember that the same code work perfectly if the execution target is Labview for Windows.
    Best Regards
    Sergio Zanoli
    Attachments:
    Geo2UTM_standalone.vi ‏47 KB

    I checked the feature using a simple application on the PDA emulator and I could not replicate the error.
    I have attached the VI i worked with ..check if this helps.
    Attachments:
    Untitled.exe ‏332 KB

  • LabVIEW 2010 in-placeness crash bug

    [cross-posted to LAVA]
    I found an odd LabVIEW 2010 bug that will cause a hard crash. The bug appears to be related to how LabVIEW operates on data in-place and some interaction between clusters, arrays, and the Aum Array Elements node. It's hard to describe verbally, so I'll just draw you a picture 
      LabVIEW 2010 CRASH.vi (16.56K) 

    No crash on my system: LV2010, W7 64-bit, Pentium E5200
    a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

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

  • Labview 2010 64-bit property node setting

    I am trying to set the selection start and selection size for an array in LabVIEW 2010 64-bit on a Windows 7 64-bit machine.
    LabVIEW 2010 64-bit crashes and is shut down by Windows.
    The call works fine in LabVIEW 2010 32-bit on the same machine.
    The computer is a Dell Precision 3500 with 4 GB ECC memory, an Intel Xeon 3530 2.8 GHZ CPU, and a 320GB hard drive.  I have LabVIEW 2010 Service Pack 1 installed.
    Here is an example of code with just one property node call.
    Is this a bug or something weird with my system.
    Attachments:
    Array Property Node Crash Example.png ‏24 KB

    I was able to reproduce the problem, also using LV2010 64-bit on Windows 7 64-bit. I tried various representations of the array data type as well as trying to not include the data type for the control reference as well as trying it via a property node in the calling VI. LabVIEW crashed each time. I'd say it's definitely a bug.

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

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

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

  • Bug? LabVIEW 2009 Enum in Datalog Refnum Loses Data in LabVIEW 2010+

    Hi 
    Can I please get support from an AE?
    Attached is a LabVIEW 2009 VI with a Control of an Enum in a Datalog Refnum.
    Whereby the Enum's FP Object is represented as an image.
    In LabVIEW 2009 this works fine however, in any higher version (I have definitely tested with LabVIEW 2011, but have been told LabVIEW 2010 is the same) the image is blank.
    Is this a bug - is data being lost?
    Interestingly enough, if I remove the LabVIEW 2009 Enum from the Datalog Refnum then load in LabVIEW 2011 this image displays correctly.
    Is there anything I can do (setting? etc...) in LabVIEW 2009 that will correct this problem so it displays correctly in later versions?
    This issue originated in this LAVA thread.
    Cheers
    -JG
    Certified LabVIEW Architect * LabVIEW Champion
    Attachments:
    Datalog Refnum Enum_LV2009.vi ‏10 KB

    This was reported to R&D (# 311354) for further investigation. 
    As a possible workaround, if you move the enum control out of the datalog refnum before saving in LV 2009, when you open your VI in LV 2011 the image will still show up for the enum control. You can then move the enum control back into the datalog refnum and it should work fine. 
    Thanks for the feedback,
    Daniel H. 
    Customer Education Product Support Engineer
    National Instruments
    Certified LabVIEW Developer

Maybe you are looking for