Upgrade Mathscript LabVIEW 2009

Hello
I have developped an application in LabVIEW 8.6 that
contains a large MathScript node. it's time to upgrade to LabVIEW 2009
and i am facing problems in that. I have the Mathscript RT Module
installed and activated on my computer.
I should emphasize that
the application works perfectly in 8.6. After the first execution in
2009 version, i got 2 run-time errors: 
 -90031 : "unknown output
variable". The variable is of string type. it's pointed in a red dot
(see picture). I have never seen that red dot before...
another
error in another node: -20104:  input parameter have at least one NaN
element. What's a NaN element? this error occurs in a line that looks
like A=median(B) where B is a row vector.
also in this second
node, i have a lot of output variables pointed in red dots, the string
outputs and some of the double precision as well.
What
are the requirements to upgrade to LabVIEW 2009, as far as MathScript
is concerned? are there issues to be considered? major changes i should
be aware of?
Thank you very much
Sam 
Solved!
Go to Solution.
Attachments:
error Mathscript.JPG ‏10 KB

Thanks Jattas
i am still confused about the coercion dots but since they don't necessarily indicate problems with the code, i'll keep the focus on something else to begin with. i beleive i should look for solutions for the whole upgrade. What i did not mention in the first post (because not sure if related to Mathscript) is the error messages i have on saving the VI before quitting, i also got those messages while loading the VI.
Attached are 3 messages that appeared (Please see pics). The result is obviously a borken arrow:VI failed to complie, Mathscript node failed to compile.
that would be a nice discussion with NI support but it's hard to explain these things on the phone. i am gathering every information that might be relevent for the migration.
thanks again
Attachments:
error1.JPG ‏12 KB
error2.JPG ‏13 KB
error3.JPG ‏12 KB

Similar Messages

  • MathScript & Labview 2009

    Hi,
    i#ve worked in the past with Labview, where i had a Full Development
    Solution together with Mathscript.
    With LV2009 it seems, that MathScript is only available in the
    Professional Development System (OK, here is MathScript with Realtime
    Features available).
    Have i done something wrong @ installation or is it a fact, that i
    have to upgrade to Professional Version now ?
    Thanks for any help
    Andreas

    Hi Andreas,
    I wanted to clarify a few points that are related to your post.
    With LabVIEW 2009, MathScript RT is a separate module, which means that it will need to be activated separately during installation, just as you would any other LabVIEW add-on modules. The LabVIEW 2009 MathScript RT Module is included with both LabVIEW Student Edition and the Academic Site License. For these options, the MathScript RT Module will install and can be activated alongside other LabVIEW components using the same serial number.
    LabVIEW MathScript RT 2009 can be installed into the Full, Professional, and Student Editions of LabVIEW 2009. Deployment of a VI that includes a MathScript RT script node to a Realtime Target requires installation of the LabVIEW 2009 RT Module as well. 
    --Sam
    Sam Shearman

  • Labview 2009 32 bit not running on xp 64 bit

    Hi all,
    I tried to upgrade to LabVIEW 2009 from LabVIEW 8.6 on 64-bit windows XP machine. Following about a 2 hour removal of 8.6 and subsequent installation of LV 2009 it turns out that the device drivers are not compatible with a 64-bit machine. On launching LabVIEW 2009 (32-bit) an error box appears stating that it is corrupt or missing files and to correct this using control panel etc. I have tried this and still the same error occurs and LV refuses to start.
    All the license files are correct and the compnents are activated.
    Anyone know how to fix this? Or should I go back to 8.6 and cancel my upgrade subscription?
    Secondly, I am using a firewire camera and was informed that Ni-IMAQ legacy are no longer supported and to go to ni.com/ifo and enter legacy1394 to see how to download drivers etc for this. I end up on a page that says "not authorized".
    Any help gratefully appreciated. 
    Solved!
    Go to Solution.

    Leeser wrote:
    I agree that XP64 and LV 2009 are not compatible as I installed LV 2009 on another 32-bit machine with no problems. I was just surprised as there were no problems or issues that I came across for 8. on XP64. Ah well, a uninstallation and reinstallation lies in wait for me on Monday morning!!  
    As an aside why call it LV 2009 instead of LV 8.7 or even LV9.0...sounds reminiscent of an operating system!!
    Regards,
    Leeser
    LabVIEW 2009 is according to the internal version scheme actually equivalent to LabVIEW 9.0. Why they changed the naming? I guess marketing told them to do so. Why then? Well marketing has some funny ideas sometimes. I guess since THE software provider in this world has started to do this since about Windows 2000 someone must have thought it to be the best idea since sliced bread and decided to do it for LabVIEW too.
    Another guess is that in about 2010 there would have been something like 9.1, and 10.0 would then come out in 2011 and that sounded somehow to someone like a bad scheme so they decided to change it now. But maybe it will be forgotten and everybody returns to the old versioning at the begin of next year when 9.0.1 will come out, which would then otherwise be LV 2009.1??? Or maybe LV2009 SP1?
    It has already happened with LabVIEW 6i (iMacs, iPhones, iAnything), LabVIEW 7 Express and LabVIEW 8.20 (following 8.0.1 and marking the 20th anniversary of LabVIEW, and being internally LabVIEW 8.2). All some marketing fun or hysteria.
    Rolf Kalbermatter
    Message Edited by rolfk on 08-17-2009 11:08 AM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Error: "not enough memory to complete this operation" when building EXE + LLB in LabVIEW 2009

    Just upgraded to LabVIEW 2009 last week and can't build anymore.
    I am building and EXE with support files in LLB.
    PC Specs:
    -P4 3GHz
      -4GB RAM
    -Windows XP PRO SP2 
    - Windows is already enabled to use up to 3GB of virtual memory for applications. 
    - Performed a mass compile on all vi's.
    Not sure what else to try and will appreciate any suggestions.
    Thanks,
    Tavi. 

    This issue as well as a few others have been fixed in the LabVIEW 2009 f2 patch that was released today.  For more information, check out the following Knowledgebase for the list of resolved issues as well as download instructions.
    David_L | Certified LabVIEW Architect
    LabVIEW Tools Network | LabVIEW Tools Network Developer Center

  • Mathscript node: an internal mathscript error has occurred: 64-bit LabVIEW 2009

    Hi Folks -
    I have an installation now of
    LabVIEW 2009 9.03f, Vision, and Advanced Signal Processing Toolkit, all
    64-bit versions on a new computer so that I can convert some code from
    32- to 64-bit.
    I figure I will address errors
    one-by-one and here's the first one.  I have a VI with a mathscript
    node and the VI, which loaded and ran fine in the 32-bit environment,
    is now broken and giving the error "mathscript node: an internal
    mathscript error has occurred."  My main concern - is mathscript not
    supported in 64-bit LabVIEW right now?
    I am attaching the VI.  Any ideas are appreciated.  I need to get this working.
    Also, NI, is there a special 64-bit forum that we should post to in the future, or create to post to?
    Sincerely,
    Don 
    Solved!
    Go to Solution.
    Attachments:
    sort.vi ‏753 KB

    From 2009 help
    LabVIEW MathScript is a text-based language you can use to write functions and scripts. You can process scripts using LabVIEW MathScript in the LabVIEW MathScript Window or a MathScript Node. When you create a LabVIEW MathScript, you must use supported data types.
    The MathScript syntax is an intuitive and logical
    syntax predominantly based on standard mathematical and computer
    programming terms, terms in widespread and common use, and/or
    descriptive abbreviations, truncations and concatenations of standard
    terms. The LabVIEW MathScript Window and MathScript
    Nodes are able to process files you create using the current MathScript
    syntax and, for backwards compatibility, files you created using legacy
    MathScript syntaxes. The LabVIEW MathScript Window
    and MathScript Nodes also can process certain of your files that use
    other text-based syntaxes, such as files you created using the MATLAB® software. Because the MathScript RT Module engine is used to process scripts in the LabVIEW MathScript Window
    and MathScript Nodes, and because the MathScript RT Module engine does
    not support all syntaxes, not all existing text-based scripts are
    supported.
    (LabVIEW 64-bit) LabVIEW MathScript is not supported in LabVIEW (64-bit).

  • MathScript RT Module - LabVIEW 2009 Mac

    Hello everyone,
    I recently bought LabVIEW 2009 Student Edition and I am using it on Mac OS X (Leopard). The checklist that came with the software says it comes with MathScript RT Module (for Mac), but that I should contact NI in order to get this module (free). I looked online at ni.com and I only found the Windows version. Can someone PLEASE post it or send me the link where to get it? I would REALLY appreciate it. Thanks!!!
    LabVIEW 2009 MathScript RT Module for Mac OS X.

    Hi Argon,
    You will have to contact NI directly to determine how you will get the module. Thanks.
    Flash
    National Instruments
    Applications Engineer

  • UDP Error when upgrading from Labview 8.6 to Labview 2009

    I recently updgraded from Labview 8.6 to Labview 2009. I am writing an application to stream data to disk from UDP. My VIs run just fine in Labview 8.6, but when I try to run them in Labview 2009 my UDP read times out despite being able to monitor UDP traffic and see that the data is being sent and nothing in the file is changed from 8.6 to 2009. Is there a known issue related to this?

    How are you moniting the UDP traffic? Have you verified that the port you are trying to use is actually available? When you installed 2009 there may have been an additional service installed that may have used the port you're trying to use. If you're running on Windows you can use the command "netstat -n -o -a" to see all the ports that are currently in use, as well as the process ID that has that port open.

  • Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

    I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
    I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing.  Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
    The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO.  I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
    So far, so good. After much fighting with Windows 7 network location settings,  I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
    Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
    I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
    I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
    Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
    Any advice will be greatly appreciated.
    Kevin
    Kevin Roche
    Advisory Engineer/Scientist
    Spintronics and Magnetoelectronics group
    IBM Research Almaden

    I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
    Export the variables from the master library as a csv file and copy that to the remote machine.
    Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
    Find the network path column (it was "U" in my file).
    replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
    where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
    and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
    NOTE the single quotes around the process name; they are required.
    The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
    Once the formula worked on line 2, I could copy it into all the other lines.
    Save the CSV file.
    Import the CSV into the remote library to create the variables.
    Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
    Open the properties for the first imported variable.
    There is probably an error message at the bottom saying the alias is invalid.
    In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
    Change the setting to "PSP URL" with the same path and the error message should disappear.
    Close the properties box, save the library, and then export the variables to a new CSV file.
    Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
    You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
    Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
    The first one is NetworkingleWriter; it should already be FALSE for all lines.
    The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
    You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
    There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
    Save the edited CSV file.
    Go back to the remote library, and import variables from the just-edited remote library CSV file.
    Once you have imported them and the Multiple Variable Editor opens, click on done.
    You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
    Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
    It actually took longer to write out the process here than to perform these steps once I figured it out.
    Kevin Roche
    Advisory Engineer/Scientist
    Spintronics and Magnetoelectronics group
    IBM Research Almaden

  • Can i build an application with Labview 2009 for Windows 7?

    Hello
    i use Labview 2009 SP1 and the application builder 2009 SP1. If i install the application on win7 this message is display:
    Labview Run Time Engine depends on pruduct with upgrade code (...) version 9.0.301, language {} which is not in distribution.
    Solved!
    Go to Solution.

    Is this an issue with Windows 7 having both installation folders for 32 bit (C:\Program Files (x86)) and 64 bit (C:\Program Files)?
    I had an application built on an XP machine and installed on a Windows 7 machine which was looking for files in C:\Program Files when they were actually installed in C:\Program Files (x86) - because it was 32-bit application.  After installation I had to move the files from 1 location to the other to make it work.

  • Labview 2009 would not close properly

    Hi everyone!
    I have been having problems with our recent upgrade from LabView 7.1 to 9. I have removed 7.1 completely and have installed everything that came with the installation DVD's in LabView 9. When I went to my old VI's and continued to work on them, after I have saved the VI and exited LabView, Labview would still linger in the background and do nothing. This prevents me from opening LabView again. I then would have to go to Task Manager to terminate the process. As soon as I do this and re-open LabView, I would get the pop-up window asking to investigate the recent crash.
    I am currently in contact with [email protected] as well, but they have not solved the issue so far. This is why I am seeking help with the rest of the community. I am hoping that somebody out there knows anything about this issue. I am attaching the most recent lvfailurelog I have encountered. 
    I have currently installed the most recent patch to LabView 9 and the only thing it's done is to illiminate the logging of the failure because it's no longer asking me to investigate after terminating the application from Task Manager.
    Marcos
    March 25, 2009
    Update: The problem has retuned and I have attached the most recent logfile.  Please help.
    Attachments:
    lvlog2010-03-25-13-35-08.txt ‏190 KB

    I don't know about old VIs specifically, but quite often, when I exit LV 2009 (and I think 8.6 did this as well) it takes a long time until the process dies and during that time the memory consumption of the process rises considerably. Eventually it does quit, but it just takes a while before it does (roughly two or three minutes).
    Try to take over the world!

  • Installing 64 bit version of toolkit and modules for Labview 2009 64 bit?

    Hello  I recently contacted NIabout installing Mathscript and Signal processing toolkits for my Labview 200964 bit that I am running on Windows 7.  I was sent the following link as aresponse: http://zone.ni.com/devzone/cda/tut/p/id/10383.  From this link it is my understanding that I cannot run any programs thatcontain an astrestik, since they only work for 32 bit version of Labview? In particular I really need to use Mathscript.  Is there any workarounds? Do I have to also install the Labview 2009 32 bit version?  Doesanyone know when Labview will allow me to run everything in the 64 bit versionof Labview?  Thanks.
    Kevin 

    Hello Kevin,
    There is no workaround available, and there are no released dates as to if/when Windows 7 x64 support for the toolkits in question will be introduced. 
    The LabVIEW Mathscript RT Module is not supported in LabVIEW 64-bit as mentioned at the bottom of the following page: http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/labview_mathscript/ .
    Vivek Nath
    National Instruments
    Applications Engineer
    Machine Vision

  • Configuration string keys in LabVIEW 2009 changes

    I am trying to write a configuration file to be used by other (non-labview) software.
    However the LabVIEW 2009 'write sting key' function adds quotes around string keys, even if the 'raw string' mode is used, this makes this tool USELESS, and I could only finde a little note in the online help
    When VIs write to a configuration file, they place
    quotation marks around any string or path data. LabVIEW also supports
    single quotes around values in .ini
    files.
    I could not find it in the Upgrade notes.
    Could we get an option to remove the quotes?
    Ton
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

    Dear Ton,
    thank you so much for your post. This problem was brought to the attention from our R&D department, hopefully they will add this soon to the writekey.vi . There is a work arroud for now; you can add the attached VI to the library;
    Download the attached VI and place in the following path: <Program Files>\National Instruments\LabVIEW\vi.lib\Utility\config.llb
    In the same folder, double-click NI_LVConfig.lvlib
    Right-click the Write folder and add the above-mentioned VI.
    Hopefully this will bring you further,
    Best regards,
    Martijn S
    Applications Engineer
    NI Netherlands
    Attachments:
    WriteKey(String)workaround[1].vi ‏14 KB

  • Why does labview 2009 32-bit closes up with no error message?

    Hello.
    I am developing an application using a PCI-6534 board, Windows XP SP3, and LabVIEW 2009 32-bits. In this application I am generating a 300 Hz signal using the P2.0 digital line. I am trying to make digital acquisition using the P0 port (8 bits), using N-sampling. The program that generates the 300 Hz clock, works with no problem. However, when I start running the program that performs the data acquisition, LabVIEW suddenly closes up with no error message. The LabVIEW windows just disappear from the screen.
    As for me it looks like a LabVIEW bug.
    In case anyone decided to help me, I could attach the programs so that you could check them.
    What can I do to solve this problem?
    Thank you.

    I had the same problem with one of our applications. I supplied gigabytes of process monitor and desktop execution toolkit logs, but nothing was resolved. I upgraded from WS2003 and LV2009sp1 to W7 64b and LV2010, per NI's recommendation but the problem persists.  I had the corresponding service ticket open for 3 months where NI said the application ran fine for them on W7 with 2010. (long story) 
    I understand your frustration, and I recommend getting your local application engineer involved as an advocate with application support.. If you pay for service, pound on them to provide it. My $0.02.

  • Support in LabVIEW 2009 for IMAQ legacy drivers on 64-bit windows

    Hi,
    I have been trying to use a VI that was created in LabVIEW 7.0 that makes use of IMAQ 1394 VI's in LabVIEW 2009.   When I first tried to run the VI an error told me that the VI's in question were missing, to overcome this problem I thought I should attempt to replace them with legacy VI'.  After downloading the legacy installer, I then realised that these VI's would not function on a 64-bit version of windows even though I have a 32-bit version of LabVIEW.
    I was wondering if there is an alternative way of replacing these VI's or a way of implementing the lagacy VI's?  Would it be suitable to replace the IMAQ 1394 VI's with IMAQdx VI's?
    Thanks for your time,
    Alistair Martin

    Hi Alistair,
    The following KB states that it should be possible to do what you require: http://digital.ni.com/public.nsf/allkb/3358528DF8648DC2862571F500586140?OpenDocument
    The KB also links to some development articles for upgrading and using IMAQdx to acquire from 1394 cameras.
    I hope this helps, 
    Kind Regards, 
    Applications Engineer

  • Parche labview 2009(patch for LabView 2009)

    Estimados:
    He instalado LabView 2009 con los módulos RealTIme y MathScript RT.  A pesar de haber instalado los parches (Patch) recomendados tengo muchos problemas de inestabilidad del software.
    He instalado el parche "LVRT2009f2" y el  "NIDAQ900f2" para RealTim.     Estoy trabajando con un Desktop Target y un Host.               
     El problema : 
    Se cuelga y se cierra Labview (a veces,esporádicamente) al  intentar grabar el proyecto  o al descargarle el programa al Target.
    Desde ya ,gracias por su ayuda.
    Saludos 

    Translation
    I installed 2009 with LabView modules and MathScript RealTime RT. Despite having installed the patch (Patch) recommended I have many problems of instability of the software.
    I installed the patch LVRT2009f2 "and" NIDAQ900f2 "to realtime. I'm working with a Target and Host Desktop.
     The problem:
        * It hangs and closes Labview (sometimes sporadically) while attempting to burn the project or downloaded it for at Target.

Maybe you are looking for