klessm1

No, all the other functions are private and undocumented unless you happen to be a member of the LabVIEW developer team. LabVIEW 3.0 shipped with a much larger extcode.h file where you could see the prototypes of all those functions exported at that time. BUT: still no documentation about the functions and more importantly the parameters and I think LabVIEw exported maybe 500 functions or so back then, some of them are gone completely, others have changed considerably in prototype and/or behaviour.

Unless you have a year or so of leisure time to dig into this I would recommend to forget about these functions.

Rolf Kalbermatter

Thanks for replying.

I did find one that is quite usefull by digging into some of the code for the executable builder. One of the vi's in there that calls a LabVIEW function turns LLB caching on and off. I found the function call and guessed the input to be a number (zero for off and one for on), and it worked. The function was called "RTSetArchiveCache" and is usefull when programatically saving multiple files to an LLB. Saves lots of time especially when the LLB gets large.

I have pretty much given up on the rest of the stuff. If you don't know or can't guess the inputs and outputs, then it is pretty much a waste of time.

Is an executable running?

Kind of depends on what OS you are running. If you are running windows you can check all of the windows that are open (they don't have to be visible). Each of the windows will have a name, so you can search for the executable you are looking for. You will need to call GetDesktopWindow function in user32.dll to get the handle of the desktop, then call GetWindow in user32.dll and get the child window of the desktop. Get the name of the window using the GetWindowTextA call to user32.dll. Get the next window by calling GetWindow again, but this time pass it the get next window constant. Loop on that until you run out of "next" windows. You can also parse out visible windows by calling the IsWindowVisible function in user32.dll. All of the function calls can be looked up on the microsoft devlopers website.

I noticed that you can do a call library function by specifying LabVIEW as the dll (uses LabVIEW.exe in the labview development environment). 8.2 has the nice little wizard for creating vi wrappers that call the dll, but it only gives access to 179 functions out of 1015 when the extcode.h file is specified as the header file. Does anyone know if a different header file exists, or if these functions are explained anywhere? Most of the functions are already LabVIEW primitives, but some are not. The configure call library function still lists all of the functions, but you don't know the interface.

I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.

The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.

As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?

Use OpenG's Builder application www.openg.org. It allows you to rename each module of your application. That is what I use for building my application and LLB plugin's for my large system software architectures. I name each module uniquely so I can release each one stand alone without effecting the other modules. I usually leave out the vi.lib and distribute the whole thing with my software. I leave it in the LabVIEW directory and just point to the libdir to the LabVIEW directory in my executable's INI file.

You can do this without renaming though. If all of the names are the same (and the code matches), the vi that is called in your plugin will be the one loaded first (probably in the executable). If you want to seperate the memory space you can also create a new application reference and open the plugin vi's into that (see vi scripting forum for more information).

I do not know of a way to assign a version number for an llb though. I don't believe there is one. They finally added that for LabVIEW EXE's. I usually write installations using SMS installer that will put the version in the registry for me and displays it in a custom "add remove program" application.

If I am not sounding very focused that is because of all the :beer: I drank tonight.

Hope this helps.

Hi,

Anyone know how to make a custom XML-file (write).

Need to change the name of parameters and so on.

LabView's write-xml only make a predefined format.

Is it an idea to use write to spreadsheet file and write one string at a time?

Thanks to any thoughts !

LabVIEW internet toolkit includes an XML tools so you can write whatever you want. You can also use Microsofts XML parser if you don't want to purchase the internet toolkit. See attached how to use it in a very basic fashion. This one just parses, doesn't write. Good luck. Download File:post-2966-1145750064.vi

The "typecast" has 3 "pin", 1 for input, 1 for output, and the last one for the type that the data trasform into, that's what i've learn from LV Help. But what kind of controls should i connect with the "type" pin? I've seen in the "serial61.vi" that the programmer does not connect any thing to the "type" pin (he use it to convert a number to string) . Another question, so what can i do if i need to do it reversely : convert a string read from serial port to a number. Thans for helping me and excuse my bad English.

The reason they do not have to pass in a type when converting to a string is because a string is the default type to convert to. If you need to convert to anything else, you have to pass in the type. To convert form string to a number you pass in the string on the input and a number into the type (any number...all it needs is the type of the data, it doesn't use the value).

I use the APIViewer to get all of prototypes I use for windows functions. I agree that it is not too much fun trying to find the function you need on msdn. I had at one time found a page on msdn that listed all of the functions plus you could search them by functional group which helped. Unfortunatly I cannot find that page, nor do I have the bookmark. I might have deleted it becuase they got rid of it and restructured. I also used allapi.net when I first started searching for windows functions. It is ok, but they stopped supporting the site in 2002.

I'm not sure about NI's position on converting UML to GOOP classes (if I did know anything then I'd have to kill you ), but the Endevo GOOP suite certainly has this capability (and more!) - it has a native UML editor where you can right-click on a class diagram component and select "create code" - this then uses the Endevo GOOP toolkit to create the code for you. The design and physical classes remain linked, and your able not only update a physical class with changes from the UML editor, but also create UML diagrams based on your physical GOOP classes. Since you're in the USA (at least that's what your flag says), you can find a little more information at the V I Engineering website - if you need more information, call and ask to speak to Wyatt Meek. (declaration of interest: I work for V I Engineering, Inc).

If you're really interested in an OpenG implementation, get on over to the OpenG site - there is an OpenG GOOP toolkit (it doesn't support UML <-> GOOP AFAIK), but there have been rumblings of a new version of openGOOP - maybe you should get involved!

I have actually spoken to Wyatt a couple of times on VISTA tool improvements. I also met with VIE (Minn office) this last week with Filipe Altoe to try and get my manager to see the light in using UML to define requireements and design and how that leads to easier code development for large scale projects. Filipe informed me that you guys are using a UML tool by Artisan to create your designs. I faintly remember hearing about Endevo's UML editor a long time ago (probably in an LTR issue).

Here is a question for MikaelH:

Does the Endevo tool force UML 2.0 specifications like some of the other commercial tools? Is there any literature on it (I haven't searched Endevo's website or anything)? Is there any evaluation phase?

Are there any tools out there or are there any plans by OpenG to create an open source tool to convert UML models to GOOP classes? Is NI maybe working on this? They could probably sell a tool like this...I would use it. Maybe if NI came out with a version of GOOP in a future rev of LabVIEW they could sell the UML to GOOP toolkit that works with their version of GOOP.

It would be much better if it was open source however as the tool could be optimized and features could be added quickly.

You had me hook line and sinker!

I think what made this site so great was that it wasn't run by NI. The freedom allowed in this site was awesome! Even though there will be less freedom, we may get better visibility on our questions by NI which is a positive.

It is probably a very good business decision by Michael. When you develop something as great as this website you should be compensated for your hard work. Bravo for putting together an excellent forum. :thumbup:

Thanks for the reply.

I tried to package with diagrams with similar results. Usually I do not remove diagrams. This case was to reduce size of application (37.2 to 24.4 MB) that is run mostly on laptops and only on company computers. I know that by today

Ya, it seems like NI did a half a** job on this one. If they only showed the custom items placed in the Tools menu in the Options screen menu editor then this would be a good solution. Now, as it stands, you can only see the NI items.

Now that I have thought about it a little, there may be a way for me to implement a solution without making the shortcuts to the menu items. In the tools I am working with, the user has the option to log into a database of their choice so the checkin and checkout tools know right away what database they are working in. This tool is running all the time keeping the database connection in memory so I could possibly trap keystrokes within that application, find the top vi window and open the checkout, checkin, or add tool. This solution might work for me, but I don't think it is feasible for other tools. The ultimate solution is to get the update from NI for shortcuts for custom tools menu items...and options for tool bar buttons.

Is there a way to make a keyboard shortcut to tool applications that are in the Tools menu in the LabVIEW development environment. This would make checking in and out of an SCC with custom tools much faster if you didn't have to mouse down to the correct application in the Tools menu. What would be even better is to have a keyboard shortcut and the ability to create buttons for the toolbar like you can in Microsoft applications. Maybe that needs to go into the wish list unless anyone know how to do it.

Thanks

Hello

I have an annoying problem....my program works fine inside Labview 7.1, but when I make an .exe file the progam dosent work any more. I'm using VISA configure Serial Port.vi, VISA Write.vi, and VISA Close.

And I'm sending some commands to the serial port...but it only works inside labview....I've tried both the single file and the shared dll options, i've also tried to add the vi's, and I've tried to create an installer....

but it's all the same...

Can anyone please help me with this problem.... :-)

i'm attaching the program...Download File:post-4021-1138624662.vi

Best Regards

Martin Ojeda

You are using an alias for VISA. These must be setup in the alias file and you must have the VISA runtime engine installed if you want it to run from an EXE. I ran into this same problem about a month ago. The alias file should be at "C:\VXIpnp\WinNT\NIvisa\Visaconf.ini" if you have the VISA runtime engine installed. In this file you must identify the aliases. See http://digital.ni.com/public.nsf/allkb/D26...6256F1F00661A49 for more information.

Basically yes, but I'm not sure what the problem is.

For one thing, you're using I32 for the words, which is wrong. You should use U16 or I16, but I am not sure this would necessarily cause a problem.

The other thing is that I'm not sure whether you can use a LV string to represent a null terminated string inside a struct.

Also, I think you might need to use Handles by Value.

The last thing, and this could be the source of your problem is that your inputs are wrong. You're inputting 1 as the number of the device (if you only have one, that should be 0) and you're wiring 0 as the number of bytes. The number of bytes is probably the trickiest thing to calculate as it seems you will need to know the length of the string.

I suggest you try digging up some more in the page I linked to or, if you're lucky, wait until Rolf will explain what went wrong and whether you will need a wrapper DLL.

Attached is a doc that explains how to arrange LabVIEW data types to pass them as a struct.

Download File:post-2966-1137640539.doc

Here is the latest Goop Ideas branching off of the dqClass.

DQ3 uses a Que with 2 elements

data is locked when only one item is in the Que

to lock data one of the items is dequeued.

to write new data the Que is flushed and two data items are enqueued.

I noticed a couple of drawbacks with the DQ3 syle of GOOP. One was that there is no way to find all of your active objects. You have to remember them somewhere else and get them. The current templates could be updated with a LV2 style global to remember all of the names and corresponding queues. They could then be created, retrieved, and removed from this repository.

The other thing I noticed was that the -1 timeout would timeout right away during the DQ3Class_getDataToModify.vi. I think this was just overlooked?

Good ideas! :thumbup: Nice to see new ways to perform GOOP.

With the appropriate setup the private network can be virtual. For some hospital mangement software development and debug we used a couple of flavors of VPNs, some through SSL, that went into secure hospital networks a long ways away and did remote installs, updates, live debugs and mods. That took some cooperation from the IT depts at the hospitals, but all-in-all I'd say it went pretty smooth. The VPN tunnels were okay, the only hassle came from a couple of hospitals that routed all external access to their intranet though a 24x7 dialup and PcAnywhere. I don't recommend that.

I'll have to ask our IT guys about that one.

Thanks.

Your problem seems to be more of configuration management one. If your LabVIEW stations are "instruments" then you want to treat them as such. I've used many traditional instruments where firmware and even OS updates (Agilent scopes) were regularly released, but I didn't because of dependancies and configuration management.

Don't treat the instrument station as simply another PC on the network. Don't take crap from the IS department. They will likely say "It's a PC, it's on the network, and the company policy is yada, yada, yada... We own it, and it MUST have Netscape, TimeKeeper+ 2000 and the AutoChron Super Backup service running..."

Don't install MS-Office, Norton AV, Firefox, or AOL IM. Don't use the instrument station for non-instrument functions like timeclocking or a print server. Disable Windows sharing, Windows Update, telnet, ftp and all the other unneeded services. Store your data directly on a server and access the results from there. If your IS department can't help you do this, point it out to the IT manager!

To reduce the possibility of viruses, your instrument stations could be placed on a private LAN. The account(s) used by operators would not have admin priviledges. They could be further physically secured by removing floppy drives, disabling USB (disables removable media) and disconnecting the optical drive from the computer's bus.

You might say "Hey, now it's hard for me to update or work on the instrument station. How do I load, debug, etc..." You will have problems with Linux, LVRT etc. The difference is that you won't have to support new OSs, manage LV licenses for different platforms or learn how to relink a kernel!

It is true that part of the issue we are trying to solve is a configuration management issue. If all we had to do is setup a production test system the task would not be as bad. We look at providing solutions for production manufacturing first, maintenance group second, and development group third.

When test systems are down due to hardware issues, the maintenance group needs the flexibility to easily fix the machines. These systems are all over the world, so to fix these systems we proxy into them and help the engineers there debug the issues. Without a network link, this would be impossible. It is not possible at this time to break this link. The facilities do not have the expertise.

What you have been talking about is XP embedded, which is one of the OS options we are looking at in addition to RTOS and Linux. Basically a cut down version of XP with all of the stuff we don

Giving everyone a linux station will cost, at most, about $200.00 per developer. Either you install Linux in a dual-boot configuration, or you simply buy a removable HD kit plus one spare caddy each. About $25.00

http://www.newegg.com/ProductSort/SubCateg...?SubCategory=43

Look at the Kingwin KF-20-IPF HD rack and the KF-20-IT extra caddy. Actually $15.00, but add shipping.

Then you buy an extra HD for each, about $175.00 (I like bigger HDs, you can go smaller). Set you boot drives to be in the caddy. Yes, you can dual boot linux and Windows, but I find the caddy solution is a good/better option for many apps. YMMV.

Don't get me wrong, LVRT is a great product, but Linux is an option.

The main cost I am looking at is that the developers will have to have a license for LabVIEW for Windows (legacy systems) and LabVIEW for Linux. This is not a small cost. :thumbdown: The hardware like you said is no big deal.

Also, I am also thinking about reusability. Can you recompile code between LV for Linux and LV for Windows? Even if you can, it still is not true reusability because you will have to have two different sets of code. It would be a pain to try to have to sync up both sets of code all of the time. What I like about RT is that all the code doesn't have to be duplicated in our SCC system.

Also, what about LV FPGA? I didn't see any FPGA modules in the supported hardware list (maybe I missed them). We are currently using LV FPGA on a current project and may go to it on this project to replace USB, RS232, and the parallel port that is used in our custom test head. If it does support FPGA then that would be great.

Thanks for the information.

You originally mentioned Linux as an alternative to RT, but then did not ask any questions. Have you definitely decided to go RT. Or is Linux an option? I helped us Linux with RT extensions on a telescope project and it worked very well.

We haven't decided to go to RT yet, and will probably still look at Linux. I have heard that it is easier to go from windows LV to RT than to Linux. Haven't checked it out for myself yet though.

The only main issue I see with going to Linux is that every developer will have to have a Linux station instead of being able to develop on a windows PC (which they currently have) and on LabVIEW for Windows (which they already own).

Got an update on this one...

I've found my original vi written in LabView 6.1 and it also looses its ability to load the CIN under version 7.0.

Looks like a change of version is in order.

Cheers,

Chris.

Have you tried to compile it using CTL+SHIFT+Run button and then saving it? Don't know if it will work but it is worth a try.

Hello everyone,

I've got a question about VI hierarchy. Does anybody know how to easily way generate hierarchy wchich can be included into tree control. Now I'm using callees and callers functions but for 200 vi's in library it takes a while. I found GetVIHierarchySiganture and GetVIHierarchyUserGUID functions (by VI scripting) but to be honest I still can't get how it works.

Thanks in adavance

If you know the ini settings you can get to the "Read Linker Info from file" method under the APP class. This is very very fast, however I do not know if it will give you the vi's in the order you want them.

Like PJM said though, the delay is probably more in the tree control update than the hierarchy list function.

So my question is:

When the software is uninstalled, is there a way to remove the service? Can an executable be set to run at un-installation time? Is there some other method?

Thanks

I have never tried to remove a service, but you can set an executable to be ran at un-installation time of an application. That is if you mean un-installing it using add remove programs. The application needs a couple of entries in the registry in the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrenVersion\Uninstall" key. You need a key under this directory with the DisplayName and UninstallString Values like in the attached pic.

The DisplayName is what is displayed in add remove programs, and the UninstallString is what is executed when you choose Remove.

Thank you for taking the time to reply. I didn't think anyone was going to answer! Your inputs are very helpful. :thumbup:

Michael