Get your questions answered by LabVIEW developers.

[EdDickens]

---

Also to be able to trigger events on other than UI events such as value changes created by code and not by the user.

---

This can already be accomplished using 'Dynamic Events'. They were introduced in LabVIEW 7.0 and expanded a bit in 7.1.

There are several shipping examples you can look at dealing with dynamic events.

Ed

[Pondered]

I wanted to control a function generator through LabView (HP33120A).  I wanted to add a function to control the output impedance and to control whether it is serial interface or GPIB.  How can I do that using one of the getting started examples?

[altenbach]

---

@Pondered wrote:

I wanted to control a function generator through LabView (HP33120A).  I wanted to add a function to control the output impedance and to control whether it is serial interface or GPIB.  How can I do that using one of the getting started examples?

---

To get a reply, you should start a new thread elsewhere. 🙂

See also e.g. this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=133798#M133798

[srini]

Hi,
  I found a problem with the LV 7.0 application builder. I made a vi in one system and subsequently shifted to another system. After sometime I tried to make a .exe from the second system and I got the error as :" Error 6 occured in Librarian Path Location.vi. Error copying files". Actually the appln. builder is trying to copy a file from my first sytem to create the application in the second system though I am not using it right now in my vi. It is displaying the source path as that of my first PC and the destination path to be the path where it is building the .exe file in the second PC. Obviously it cant find the file to build the application. I dont know how to get out of this problem. This may be a possible bug in LV.

It's really nice to see the C code working in LV but I would appreciate if C++ codes also work in LV. Alos. I would like to know whether LV can excute a dll which is calling another dll.

In one of my application, I want to write files to a remote PC using our LAN and sometimes to execute some application by giving command line arguements to the remote PC through LAN. It would be gr8 if this facility is included in the newer versions of LV.

Thanx & Regards,
Srini.

[tst]

1. This isn't the thread for these questions. Start a new thread.
2. I don't see any reason why LV shouldn't be able to call a DLL calling a DLL.
3. I didn't understand your first situation, so when you start the new thread, be sure to add some more details.
4. You can copy files to remote PCs if they are configured as network drives. You can't simply execute an application on a remote computer because the remote OS has to give you an option to do that. You can write a simple program which will run all the time on the remote computer and when you contact it will call whatever executable you want to call.

[kozlov]

What kind of data are calculated faster - new dynamic data or old array? I have in mind array manipulation.

[unclebump]

Speaking of events, how about events based on tag values changes in the DSC, without having to put indicators on the front panel or the value signalling property.

[Bob_Y.]

I can answer that one: Arrays are faster.

The dynamic data type is an array of clusters of waveforms.  Most of its manipulation is done through regular LabVIEW diagrams and that means looping through and unbundling stuff.  If you want, you can look through most of the Express stuff by dropping one, configuring it, then pop-up on it and convert it to a subVI.  Inside you will see that many Express VIs break the dynamic data down to its constituant parts then manipulate them.  This makes array manipulation faster as it does not have to be broken down for manipulation.

I think that the power of dynamic data is the stuff that come with the array: timing info, naming, easier bundling, etc.  These things are also things that slow it down, but that is a trade off.

Hope that this helps,

Bob

[Jarrod_S.]

Thank you for your suggestion. Currently there is no such poster available, but I have made a product suggestion on your behalf that a product manager will review for inclusion in future product releases. The best option for now is to search for gobject in the LabVIEW VI, Function & How-To Help for a list of all the properties and methods, as well as a description for each.

[chanlo23]

Hi Ed,

Thank you for your response!   I really appreciate your willingness to share your expertise.  

I can see that in my frustration over my specific problem, I may not have provided sufficient information and articulated what I was suggesting for new versions.  I am not using this particular LV5 or LV7 application on a regular desktop/workstation.  It is a custom, dedicated hardware board, that plugs into a proprietary databus to operate in a custom test and analysis machine.  Its setup with 10 megs of free data memory and a small hard drive. A stripped down version of win98 is the OS.  

I do use that installer section completely when I build an installer (it sure helps to remove a lot of bloat, but/and the problem is the RTE still includes a TON of functions that are not used in each application and these you can not UN-select.   As a result, the RTE is really not a true runtime engine for the single app you are building.  If you just go to a blank diagram and click on functions, you see that 90% or more of those functions are not used in a typical application, but are still getting put in the RTE.  If you have a hardware/memory limitation, as I do with this particular application, all that wasted code becomes problematic.    Upgrading my LV5 application to LV7 results in an application that is 23mb (after turning off as many options as I can in the installer section).  This can not run in the custom system at all, because I do not have that much memory available.   It's frustrating to know that the application would run fine, as the LV5 one does, if the RTE didn't insist on adding all the functions that are not needed.

So, part 1 of my request for future development would be an RTE installer that lets you check only the functions that are needed for your application.  A true runtime compiler (something to compile a runtime engine based on what your VI APP needs) would allow you to tic off functions your app does not need, would look at your app, and ONLY add such functions that your app needs and drop everything else -- basically such has to be done under compiler evaluation control.  You could tick off a box that says "Have Compiler Analyze APP  and use ONLY what is required".  Something like that would be awesome, would be lean, mean, and powerful.

As to the block diagrams, I should restate that.  You know how LV is graphically oriented for its design if you are not using custom cin's or dll's -- basically all I am asking for is what is in the exact steps performed for the three LV7 array editing functions of replace, add, delete row.  The documentation does not tell us what steps, in what order, are being performed in these functions and that is what is needed.  I don't need or want the proprietary code, just a complete description of what/how that particular function 'block' is working.  This is why part2 of my request for future development is complete documentation that fully describes the processes that are required.

Again, thank you for responding to me.  
Charlott