share data between mathscript and LV

[PSpaepen]

Hello

does anyone know a elegant way to share data between a loop running inside a mathscriptnode (process data) and a parallel loop running LV (display UI and DAQ) (2009 RT).

So far I have not found a way other than to write a file to disk and read this file in the other loop.  Obviously this is not very clean and RT-compliant solution but for small data transfers at low speed it should do the trick.

In my case the LV daq loop should run at 1K to record and pre-process data (e.g. debounce) and the mathscript loop should run at 50 Hz.  Calling the mathscript node at a 50Hz time was not feasible.  

Is there a way to e.g. use DMA?

thanks for all input

Pieter

[rpursley8]

Can you split your mathscript node into several (maybe 3) nodes?  You can use a LV loop around the mathscript code that is currently in the mathscript loop.

Message Edited by rpursley8 on 10-15-2009 11:51 AM

[PSpaepen]

Thanks for the fast response but the problem is not in the mathscript node itself but in the fact that the code inside the mathscript node is a 50Hz while loop.  If I would use a LV loop around the mathscript node,instead of the while loop inside MSnode, this would mean that I would have to "open" the mathscript node 50 times a second creating a large CPU load.  Would breaking up the node speed up the program?  I thought there could only be one MSnode be running at a given time (not multi-threaded yet?)

Access to the LV shared variable would be ideal.  does anyone know how to e.g. access LV shared variables (NI-psp protocol) in a parallel matlab routine? 

Pieter

[PSpaepen]

Is there anyone with some experience for the following

Create a small Vi that reads / writes shared variables (without processing).  Compile the vi to a dll.  Call the dll inside a mathscript node to read/write shared variables.  

would this cause a lot of overhead/performance loss?

Pieter

[GrantM]

Hello Pieter,

The MathScript Node is implemented completely on top of LabVIEW.  There is no need to "open" a connection to any third-party software when using the MathScript node in a LabVIEW loop.  We have improved the generated code greatly in the LabVIEW 2009 MathScript RT Module, so you shouldn't observe a significant slowdown by moving the loop outside the node.  Unfortunately, MathScript does not provide any connection to LabVIEW shared variables.  The suggestion by Randall is likely to work the best for you at this time.  However, if not, your suggestion of creating a VI that uses shared variables and building it into a DLL sounds like it will work.  We have not tried this, so I am unable to provide any information about the overhead associated with it.

While the MathScript node is not very multithreaded yet, you can still run multiple MathScript nodes at the same time.  The only restriction is that the underlying VIs used in a MathScript node are not reentrant.  Thus, you will only observe contention issues if you are calling the same function from multiple nodes in parallel.

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

[PSpaepen]

Hello Grant

thanks for the answer.  I have some additional questions.

I have been running a small test (see image) to check for speed. On a PXI 8106 running this test, which has no separate UI, at 1k loop rate needed 3.7% CPU of which 0.6% went to timed structures. Does this mean that the overhead for calling a mathscript on a RT target is very small?  Will this be the same on a windows platform.  From what I have been testing the behaviour on a windows platform differs from the one on a RT target or in the case of a compiled program that uses the run-time engine.  If I run a mathscript program on my windows machine and call a .m file I can still change the contents of that .m file while my program is running.  The next time the mathscript is executed it will execute the new code.  Since I can not set a search path for the .m file on the RT target I suspect that the .m file is compiled when the program is deployed and that it is not necessary to transfer the .m file to the target.  Is this correct?  I did not succeed in calling my own .m file on a RT target yet.

thanks for the help

pieter

[GrantM]

Hello Pieter,

Ok, it sounds like you are asking about 5 different things here.  Let me break them up and respond individually.

1. There is no overhead inherent to using a MathScript node on RT.  Since the MathScript code is implemented on top of LabVIEW code, there will be varying levels of performance with respect to a native LabVIEW implementation, but simply having the node itself does not cause any overhead.
2. On a Windows platform (or other desktop platform), the answer is the same: the node does not introduce any overhead into your algorithm.
3. If you use the application builder to create a compiled program that uses the run-time engine, you are no longer able to change the .m file.  Or, to be a little more technically accurate, the LabVIEW run-time engine does not have a compiler.  Thus, you can change the .m file all you want, but the actual .m file that is used by your built application is the version that was present when you built the application.
4. The behavior you observe with MathScript executing new code will only happen if you are running a VI with the full development version of LabVIEW.  We need the LabVIEW compiler in order to generate new code when you update a .m file and this is only present with the full development version of LabVIEW.
5. The search path is only necessary when you are developing your VI on the host.  You can set a search path by right-clicking on "My Computer" in your project, choosing Properties, and then "MathScript: Search Paths."  Note: your VI will need to be in the "My Computer" target to locate your .m file.  After you have created your MathScript node, you can drag the VI to the target.  You are correct that the .m file is compiled when the program is deployed and you do not need to transfer the .m file to the target.

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