Support for lsim, fzero

[jemandel]

I am an academic user with a a site license for PDS and a full MATLAB license. I have a control system I'm developing which depends on lsim and fzero. I can see that I can probably port the functioning core of the MATLAB version of the program to Mathscript RT, however, the ultimate goal is to deploy the system as a standalone app. I can live with having to run the prototype on my development system in the short term, but ultimately I need those functions. Is there any hope that standalone version of these functions will appear in Mathscript anytime soon? I'm sure there are sound reasons why something that works in the development system doesn't work in standalone, but perhaps this could be clarified.

Jeff E Mandel MD MS

University of Pennsylvania School of Medicine 

[A_Patel]

Hi Jeff,

Take a look at the following forums, they might help you out:

http://forums.ni.com/ni/board/message?board.id=170&message.id=92706&requireLogin=False

http://forums.ni.com/ni/board/message?board.id=450&message.id=1031&requireLogin=False

FLash

[jemandel]

Thanks, but that doesn't answer my question. More specifically, if I use lsim and fzero_ in my Mathscript routines on my development platform, and then want to implement the system in a standalone PC, or ARM, Blackfin, or some other embedded target, what are the prospects for NI having support for this in the next release (or the one after that)? I can use those functions in the Matlab RTW today, but I can defer implementation of the real-time system for a while, I just don't want to commit to Labview for the development environment for prototyping, only to have to move to MATLAB for implementation because NI doesn't put priority to adding these functions to the list of of functions in standalone and embedded implementations.

Thanks,

Jeff 

[A_Patel]

Hi Jeff,

To answer your question, it really depends. Mathscript will always be available when deploying to a Windows or LabVIEW Realtime machine running standalone, however I do not see it being avialable on ARM or Blackfin in the near future.

Hope this helps.

FLash

[GrantM]

Hello Jeff,

The MathScript lsim function is provided in the LabVIEW Control Design and Simulation Module.  It will work in a built application and on real-time targets as long as you request an output from the function.  Calling the function with no outputs would pop up a graph and this version is not supported.  The fzero function is currently not supported in a built application or on a real-time target, although we are investigating methods to make it (and similar functions) work.  As an alternative to the fzero function, you can use the formula VIs located in the Mathematics >> Scripts & Formulas >> Zeros palette.  As an example, the Newton-Raphson Zero Finder is a poly VI that can work on a formula string or a VI that implements a function.

Unfortunately I can't say when this functionality might be available on embedded targets.  It is on our roadmap and something we are very interested in doing.  Hearing interest from customers like you helps us to prioritize the work accordingly.

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

[jemandel]

I went back and reread the documentation "Control Design MathScript RT Module Functions Not Supported in the LabVIEW Run-Time Engine", and now it makes sense to me. Perhaps "calling the functions without return arguments generates graphical output, which is not supported in standalone applications" would be a better way to describe this.

The Mathematics function minimization routines may work for me, but the attraction of Mathscript RT is greater compatibility between my Matlab codebase and my Labview codebase. There are some routines I'm willing to recode, such as interfaces to monitors and pumps, but my development work on control algorithms will almost certainly going to remain in Matlab. My situation may be unique; I have both Matlab and Labview already, and as long as I'm content to drag my laptop into the OR to test the controller, I'm OK, but the moment I need to compile a standalone version for my eeePC, I have to commit to one platform or the other. Building a box with ARM or Blackfin will require buying new modules for either Matlab or Labview, and finding someone who can handle the implementation (almost certainly there won't be a single individual who will be platform-agnostic). So as I look at the decision as to which platform to choose for my prototype, it becomes important for me to understand a bit more about the roadmap. Perhaps it would help us all if you could answer a few questions:

1) For a Mathscript call that does not draw to the screen, how much work is involved to move it to the standalone version? Is it just pointing at a few different header files and linking to different libraries, or is it some bizarre difference like the development system is in C and the standalone is in Algol?

2) How different is this for embedded targets? Is ARM significantly different than Blackfin?

3) Is all of this simply Mathscript lib_load, and if so, is there an example of a single C file that, with an appropriate #def statement, spits out a development, standalone, ARM, or Blackfin Hello World object?

I understand that you have to prioritize development resources, but some simple statements like "we are committed to supporting all optimization, ode, and integration routines subject to the limitation of no support for screen output in the Spring 2010 release, and will release support for a Mathscript screen control in Fall 2010" or "Significant enhancements to Mathscript RT will not be available in the coming year".

Thanks,

Jeff 

[GrantM]

Hello Jeff,

I apologize for the delay in getting back to you as I was recently traveling.  I have forwarded your comments to our documentation team to investigate rewording the text.

The problem with fzero and other similar functions is with the way the dependent function is specified.  It is passed as a string parameter.  Our current implementation will try to interpret this string at run-time and only then generate the appropriate compiled code.  The LabVIEW compiler is not available in the run-time engine and this is why the function will not work in a built application.  However, it seems that most of the time, the function is passed as a string literal and not a variable.  Thus, we should be able to analyze the script ahead of time and compile it into the application.  We are currently investigating this for the future.

For your questions:
1) There really is no work involved to move a MathScript function to a built application.  MathScript is implemented on top of LabVIEW, so ultimately there is graphical LabVIEW code executing the code in the MathScript node.  This graphical code is compiled by LabVIEW into a built application just as if you had written the graphical code yourself.

2) For embedded targets, the same rational holds as in (1).  However, the embedded targets may not support all of the MathScript commands, so we need to investigate and restrict the types of scripts that may deploy to an embedded target.

3) The lib_load function you mention is used to call existing code in a DLL from within MathScript.  In the "examples/MathScript/MathScript Shared Libraries" folder, there are some examples that call into existing DLLs.

Exactly what gets put into future versions can change throughout the development cycle.  As such, we can't guarantee that certain functionality will be available for any given release.  What I can do is reiterate what was shown for the NI Week 2009 MathScript RT Module roadmap.  We currently have the improvement I mentioned above about fzero and similar functions on the roadmap for the Fall 2011 release.

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

[jemandel]

Is there a way to force Mathscript to emit the compiled Labview for my fzero script? The corollary is can fzero call a reference to a VI?

Thanks,

Jeff 

[GrantM]

Hello Jeff,

The LabVIEW code is not accessible, unfortunately.  However, instead of calling a VI reference from the fzero function, you could create a VI for the function that fzero calls.  Simply import the text of your .m file in a MathScript node, create the appropriate inputs and outputs, and remove the actual function line from the code.  You could then call this VI by reference from the LabVIEW Newton-Raphson Zero Finder VI I mentioned above.  This way, you won't have to rewrite that function in LabVIEW.

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments