LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Dear All:
 
I have Arrays of Data that I have acquired from different sources (TCP/IP, Reflective Memory Cards, Analogue Cards, OPC Servers ect..) I'd like to make this data available to other LabVIEW application programs by writing it to the PC RAM Memory.
 
Could you advise me please, what functions in LabVIEW can I use to write and Read from the PC RAM Memory?
 
Thank you for your help.
 
Regards
 
Felix Beltran
 
CONVERTEAM Ltd.
Control & Instrumentation Dpt.
0 Kudos
Message 1 of 23
(6,031 Views)
Can you write it to a .txt file and read from there?
0 Kudos
Message 2 of 23
(6,019 Views)
It depends on what you mean by 'other LabVIEW applications'. Are these all different exe's that you have built or are you just running everything in the development environment? If it's the latter, you can just write to a LV2 style global or a normal style global. If it's different exe's then you can use datasocket write/reads, tcp/ip write/reads, or VI Server in the other apps to read indicators in the collection VI.
Message 3 of 23
(6,016 Views)

Dennis:

Thank you wor your replay. The other LabVIEW Application programs are stand alone executables. I can not use Data Sockets because it dramatically slow down the data acquisition process.

Basically the system consists of a Data Acquisition Program (witten in LabVIEW 7.0) which collect data from different sources. To make this data available to other programs (client programs) and still have an acceptable scan cycle I was thinking to buffer the data into the PC RAM Memory and then other application programs can take it from there.

The data Acquisition loop should be able to acquire 40Kb in less than 10ms. If I use data publishing on Data Socket the program scan cycle is affected dramatically. (I'm using Intel Xeon 2.8GHz, 2GB RAM). Logging all the data into a file from where other application programs can take the part of data they need also slow down the DAQ process.

The last thing I though was to use Global Data Variables, but unfortunately LabVIEW makes copies of the data for each Global variable which on a large number of channels (3000x 32-bit SGL) at a high logging rate will negatively influenc the memory consumption of the main application program.

I know LabVIEW has the "Visa Move in 32" and Visa Move out 32" subVis tha can read and write, from and to the Local PC Memory.

My question now would be:

On the "Visa Move in 32" subVi How do I get wired my 2D Data Array (in LabVIEW) to this Function. it requires a "Visa instrument resource name" which I don't have beacuse I have the data already in LabVIEW.

Basically is moving the data from the LabVIEW enviroment memory space (unknow to the user) to a user defined RAM memory location

Any suggestions on this issue will be highly appreciated.

 

 

0 Kudos
Message 4 of 23
(5,985 Views)
The VISA move in/out functions are not for writing to pc memory. They are for writing to address locations to pci/pxi cards. Global variables can not be shared between executables. I wouldn't think that using datasocket would affect your acquisition that greatly if you had a separate loop doing the datasocket writes and the acquisition loop writing to a queue. Memory allocation with LabVIEW and windows is something so dynamic, I wouldn't think that would be a very reliable method. I think the only way to do something like this would be call a dll written in C.
0 Kudos
Message 5 of 23
(5,980 Views)
If you have the DSC module, you could write the data to memory tags. You could also use a functional global architecture. I'm a bit confused, isn't a shift register a spot in memory??
0 Kudos
Message 6 of 23
(5,971 Views)
But these are different executables with completely different memory spaces allocated by Windows that are invisible to one another. So if one program has a pointer to the memory address 12345678 (I'm breaking into pseudo-C language here) and the other program has a pointer to the memory address 12345678, these are not the same places in memory. It would be like going to the right street address in the wrong city. Best option is buffered TCP like Dennis said. This is what ActiveX and many other similar protocols are based on, I believe. If Windows does it this way with their protocol in Windows, I'd do the same.
 
The DSC is a great point, however, along the same lines of using a network protocol.

Message Edited by Jarrod S. on 07-25-2006 02:11 PM

Jarrod S.
National Instruments
0 Kudos
Message 7 of 23
(5,964 Views)

Hi Felix,

      How-about writing the data to a file stored on a ram-drive, then let each application open the same file.  I suspect there would be some conflict if more than one app tries to open the file for writing. 

Hey, if there's a reflective-memory card, do you think you could allocate some memory on the RM card, and access it from multiple apps?

Cheers

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 9 of 23
(5,939 Views)
How about upgrading to LabVIEW 8 and then using the new shared variable?
0 Kudos
Message 10 of 23
(5,930 Views)