Get your questions answered by LabVIEW developers.

[alkazaa]

---

@larimert wrote:

It would be nice if Labview exposed some ?Handles? to windows so that DDE clients and/or servers could "POKE" into them.  I have an application that I'm writing which talks to a server that requires me to "DDE Execute" with a "source|topic!Item" as part of the string and it then "DDE Pokes" the data into that location.  The problem is that since LV doesn't have anything exposed that I can "Poke" into, I actually have to have the data "Poked" into an Excel workbook and then read it from there.  This, of course, necessitates going thru the song-n-dance routine of opening and setting up the Excel workbook with a named range and etc.  I have not come across any work around other than that,but it would be nice if there was one such that LV could handle everything on its own.

Thank you,

Tom Larimer

---

Does a C, or VB or whatever compiler have DDE support? No. They allow to write applications which support DDE. So does Labview: see under ..labview\examples\comm\ddeexam.llb and find some small apps that do DDE. The DDE support is there since LV 3.0 or 4.0, I believe, but since DDE is sort of out-dated (more or less replaced by ActiveX) the DDE VIs are no longer found in the functions pallette, though they are still there.

I wrote some apps to DDE with ORIGIN long ago and it worked quite well. As far as I remember, LV supports a full client and server functionality in your self written applications, but you have to write the code. LV is just the compiler.

-Franz

[venkatgill]

Hello,

I am pretty new to LabView and DAQ. I want to measure a AC voltage and Current seperately generated from a single phase power supply range 0-120V AC using the DAQ card NI-PCI-MIO-16E4 and LabView 7.1. I also have the connector block CB-68LP and the connector wire. I dont have the pin diagram of CB-68LP and and any example VI from LabView doing the same work..  I also have Current Transducer CTL-101/100 and Signal Conditioner  CTA201P.

ANy help is much appreciated. Any VI or weblink supporting this is needed.

Thanks

[tst]

Why did you post your questions to 2 different threads, where it's unrelated to the topic of the thread, instead of starting a new one?

You can try searching the example finder or this site for example and tutorials related to this.

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

[Ikoria]

Hello, i'm french so scuse my writting....

I use "Open config data.vi" for read, writte or create config file for my best programme. In devellopment mode, my pg run correctly but if i do an exe, when i run it, it say error code 7 ("file don't exist"). i don't understand what it do beacause i hav make a smally pg with the "open config data.vi" and the exe run correctly....

What can i do....

LV 7.0express (full)

W2000 Pro

Thanks for your light

Iko

[tst]

You can start by opening a new thread if you have a question and not posting it to this one, where the question doesn't belong.

Other than that, when built into an EXE, the EXE serves as an LLB (a VI library). So, if your VI path was c:\foo.vi, for the EXE it will be c:\foo.exe\foo.vi. This means that if you rely on the VI path to get the file path, you need to do another strip path when running the EXE. To do this, create a property node from the Application Control palette. Select the Application>>Kind property and wire it into a case structure. For the default, wire the path through. For the run-time system, add a strip path inside the case.

[Raistlin]

I have a few questions about the working of LabVIEW, especially regarding memory usage.

- Why do local (and global) variables create copies of your data ? I would think just using one memory space for each indicator is enough, since every change has to be done for all copies of the variable. I don't really see the need for copies.

- If an unitialized shift register is being used in a while loop with an included case structure with different states, and an 'initalize array' is being carried out in one of the states, a copy of this array is made when it is wired to the shift register. For very large arrays this doubling of the memory requirements can pose problems, and does not seem necessary to me.

- LabVIEW seems to have some problems with the initialization of very large arrays, even if enough memory is available and using 'malloc' in C does not give the same problem. We allready raised the issue before, but in this context it might be interesting to now how LabVIEW manages memory internally.

I'm sure I can come up with some other questions, but for now I suppose it is enough 🙂 .

[tst]

Locals\globals - the way I understand it, when you read the local into a wire, the data in the wire can no longer be associated with the data in the control. Therefore, you need a copy of the data.

Large arrays - apparently, when allocating memory for anything, LV needs a contiguous memory block. Finding 500 free and contiguous MB can be tricky if your memory is fragmented, even if you have 2 GB of RAM.

I'm not sure about the Initialize Array thing.

Try reading app note 168 about memory management (can be found in the LV bookshelf under the help menu).

[EdDickens]

The thought that you are running on custom hardware actually occured to to me as I was repling, but since I didn't know.....

Sounds like you might actually benifit from LabVIEW Embedded if you could get away from having to run in your stripped Win98. That could be a very good tool for you. Display can be handled through serial or enet monitors, and you lose all the Windows overhead and end up with a real time hardware target.

Other than that, I can see why you're frustrated. I agree that it would be nice to at least have the choice of either installing the entire RTE once (for a machine that will be running several applicaitons) or just what's needed for that app to save storage space and memory for applications like your's.

Ed

[Raistlin]

The problem is that, as I understand it, there is a certain need to make LabVIEW more of a generic purpose programming language. These memory issues are not present in text-based programming languages as C (no copies of local variables, no copies of arrays unless when explicitly performed, bigger memory blocks available for allocation, ...). I understand using graphical programming makes memory management more complicated and more safety has to be built in, but it seems to me copies could often be avoided.

I read the application note your referred to, and I know how and when LabVIEW makes copies of data, I only think it would be nice if this would be less 🙂 . Often copies can be avoided by intelligent programming, sometimes they can not. In my eyes it would be a major improvement if improvements where made here.

Message Edited by Raistlin on 08-01-2005 10:46 AM

[tst]

---

@Raistlin wrote:
The problem is that, as I understand it, there is a certain need to make LabVIEW more of a generic purpose programming language.

---

"Need" is problematic. Many users want this (including me), but as far as I know, NI makes most of its money from hardware and so [guess] places more emphasis on making it easier to quickly build programs and work with hardware than on making LV more general purpose (and it's their right) [/guess]. When the patents wear off (which should be soon), maybe someone will make another G compiler which will be more "general" (or maybe LV 8?), but I doubt that (unless it will be an open source one).

The automatic memory management is both one of LV's strongest points and one of its weakest. As long as you don't have any large data structures (multiple tens of MBs or a single hundreds of MB) you should usually be fine, but when you run into those large ones you have a problem. I assume you also saw Damien Gray's presentation on the subject, but if you didn't, search his posts for it.

The memory management has improved over time, but some things probably can't be avoided (for example, the local variables thing). If you have any concrete suggestions for memory management improvement, you can try making a product suggestion, but without knowing the source code for LV, I doubt you will come up with any ideas that the NI people haven't thought about.