"How do I write data to PC RAM Memory from LabVIEW 7.0"

[tbd]

Hi Felix,

just read this: "I can not use Data Sockets because it dramatically slow down the data acquisition process"

... forget the ram-drive!

... shared RM would be (extremely) fast - though I expect you've already considered it...

[chrisger]

hi there

you can increase datatransfer with datasocket when sending less items with more data. the vis attached send and receive a SGL[10000] array as a single string over dstp with less than 10 ms. the rate with tcp is quite the same.

(LV 7.1, WinXP SP2, Intel Mobile P4, 2.20 GHz, 1 GB RAM)

maybe you can optimize the number and the size of arrays.

[AdamB]

Here's another idea felix,

How about you create a functional global variable.

Define all of it's inputs and outputs (we're talking set/get/reset etc)

The compile this into a dll.  Save that to your harddrive and use the exe's to access the dll to set/get the array values.

This way the values are stored in one memory space (associated with the dll)

Give that a go?

AdamB

[Ben]

I don't know if you are still istening but you wrote:

"I'd like to make this data available to other LabVIEW application programs by writing it to the PC RAM Memory."

A number of the previous posts have given you the answer already but I will repeat it.

Use a Functional Global.

A properly coded functional global will maintain your data in a single buffer (the shift register).

With the appropriate functions the global can make all of your data available to any of the other LV applications.

THe global can be invoked dynamically from the "other" LV apps in similar fashion to gain access to the data that is "shared" by way of the functional global.

One more thought.

Queues are even faster than the LV2 if;

You know that data will always start at one place and end at another (que one place deque in another) but will require more coding to share between LV apps.

Ben

[Felix Beltran]

Dennis:

Thank you and the other guys for your suggestions. Tha new "Share Variables" in LabVIEW just drag my attention.

Do you know if this share variables work accross different LabVIEW Stand alone application programs (executables) ?

If Share Variables are used just internally on the same LabVIEW program, What would be the difference between them and Shift Registers.

Thanks a alot for your support.

Kind regards

Felix

[Felix Beltran]

Unclebump:

Thanks a lot for the link. I'll try it.

Regards

Felix

[Felix Beltran]

Tbd:

Thank you for your replay. I'll study the Ram-Disk suggestion you gave me.

Unfortnunately the customer does not allow me to write to the Reflective Memory because this data as you know will be sent as well to the other Reflective memory nodes on the Ref. Memory Network. My application should only read data from the Ref. Memory according to the project specifications.

Kind Regards

Felix

[Felix Beltran]

TO ALL LABVIEW GURUS:

A Big Thank you to all of you for your grate ideas. I' have been using LabVIEW just for few year but I din't know were so many LabVIEW enthusiastic out there

Thanks a lot for your support

Felix

[AdamB]

Hey Felix.

I'm gonna hold my head up now and tell you that I was actually wrong about the functional global variable dll.

It works fine when you are in the development, however when the exe's are compiled they don't seem to work. (I assume that they open the two dll's in seperate memory spaces.)

Sorry about that.

I'm still working on it though.

AdamB

[Kevin_Price]

Adam,

Intriguing and attractive idea though.  Please post back if you find a workaround -- could there be a default DLL-build option (re-entrancy, thread-safeness, etc?) to uncheck?  I could imagine wanting to do this myself one day...

-Kevin P.

Message Edited by Kevin Price on 07-27-2006 11:22 AM