Turning a LabVIEW built DLL into an ActiveX server

Does anyone have a list of the steps you must go thru
to convert a LabVIEW generated DLL into an ActiveX server. Do the functions become methods?

Hi James,
we have a library we deploy in three ways: as a LabVIEW library, as a DLL and as Active-X server.
In the build file for the DLL we have made each "function to call" a top level VI.
In the Active-X server each "function to call" is a dynamic VI. We created a new top level VI which will run when the server is started and stops after his window is hidden. In LV 6.x you need the winutil library to hide the window. If you close the window (through FP.Open set to FALSE) the server will stop. The window size is set to 1x1 in the VI Properties to minimize flickering on the screen during start of the Active-X server. You must check the "Enable Active-X Server" box on the "Application Settings" page in the app builder. In your client application yo
u open a reference to the server and then you can open a reference to the VI. You set/read the controls and run the VI. There is sample code for Visual Basic on the NI web site. I have also sample code for Visual C++ single and multi threaded clients.
If you are interested in the examples contact me at [email protected] and I will ask my customer to allow me to send it to you.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Similar Messages

LabVIEW built DLL's in a multi-threaded C++ app, Help Needed!

I'm working on a software application that is being developed
primarily in C++. There is a component of this larger application,
however, that is being developed in LabVIEW (for several reasons that
I won't dive into here). This LabVIEW code is therefore executed
within a C++ wrapper class that calls a LabVIEW built DLL.
All this was fine and dandy, untill we decided to multi-thread our C++
application. As a result, the LabVIEW DLL now gets called from
multiple threads simultaneously. From all of my testing, it appears
that resource locking is occuring such that only one thread has access
to the .dll at a time. If I make the .vi used to define the dll
function prototype as non-reentrant then this is what we see. As an
example, say we have 3 threads all calling the same .dll method call.
Thread 1, 2, and 3 all call the .dll within a few milliseconds of each
other. Thread 1 completes the .dll call after X milliseconds. Thread 2
completes the .dll call after 2X milliseconds, and thread 3 completes
after 3x milliseconds.
Now, changing the vi to reentrant, and running the same test, we see
Thread 1, 2, and 3 all complete the .dll call in 3x milliseconds.
While the fact that they now take the same amount of time to complete
would lead you to believe they are happening in parallel, the fact
that it takes 3x milliseconds as opposed to X milliseconds means they
are not.
Has anyone ever dealt with these issues before? Is it possible that
messing with the "execution system" for the vi will have an affect?
What if different .dll methods but still attached to the same .dll are
called from different threads? Same behavior? Is it a lost cause? Is
there no way to make code within a single LabVIEW built .dll run in
two different threads at the same? From what I understand this is
easily doable with a normal (non-LV built) .dll.
Please, if anyone has any advice in this area, let me know!!!
Much appreciated,
Jesse Hurdus

Duplicate post.

How do I turn a Labview measurement file into waveform data

How do I turn a Labview measurement file into waveform data, I have done this recreating the waveform out of an array with build waveform vi, is there another way?

OK I am sorted, sorry for such a stupid question!!!!!

Can a LabVIEW-built Dll have front end ?!

Hi All,
Can a Dll built using a VI be popped-up as usual as a SubVI, when called from a Main VI ?
I m trying to do this in LV 7.1 & getting the attached error message.
All the connector pane IOs are correctly configured in the Dll, inside the Main VI code, when it is invoked in its corresponding button value change.
Please clarify & guide me.
- Partha
LabVIEW - Wires that catch bugs!
Attachments:
Fatal Error due to LV-built Dll.JPG ‏17 KB

I agree with Wiebe, I am running DLLs on my production test system. Windows appear. The only two issues that I have had is:
does not always come to the front, even with the attribute set. But this may be an issue with a modal window in the caller. The easiest thing for me to do was place the window where I know it will always be seen.
can not change the icon in the upper left corner.
As to your error, I typically see that when I have called the DLL wrong. Passed a value instead of a pointer or something else dippy.
Paul <--Always Learning!!!
sense and simplicity.
Browse my sample VIs?

Turning a Beige MT G3 into a File Server

I've got a Beige G3 MiniTower 266 running 10.3.9 and has been upgraded with a G4 500MB processor, 40GB HD an DVD drive (not burning), a Firewire/USB 2.0 PCI card, a Wireless G PCI card and an ATI Radeon 32 PCI card. Despite all of this stuff that I upgraded a few years ago, I am trying to figure out what to do with it. I primarily use my PowerBook, and I was thinking that this G3 would be a good place to store my music files, videos, use as a VPN server, other geek stuff. Hardware-wise, I'm wondering how best to do it. The options I can think of are:
- Install a PCI ATA card for a faster bus and slave drive capability (I have a rev. A) Would I still be beholden to a 8GB partion for OSX?)
- Use a chain of Firewire drives
- Other options?
Your thoughts?

Glen-
Do you have to disconnect that cable before you tilt
open the "upper story" on your desktop?
Yes, I am using a basic short cable, I think it would need a pretty long one to be able to remain connected when tilted open and still reach PCI slot A1. I still have a bootable drive on the on-board ATA interface for the rare occasion when I might want to boot up with the case open.
I think Sonnet found ways to work around the
limitations, and their card may still say it has
IDE/ATA drives attached.
Nope, the drives show up in the SCSI tree in Apple System Profiler in OS 9 and X. The PCI card name is listed as ACARD, 6260 and type SCSI. So, from your post below it sounds like an ATA100 or ATA133 PCI card wouldn't really achieve much better continuous throughput than the ATA66 PCI card? I know the PCI card really makes a difference compared to the on-board ATA interface.
One problem I consistently had is CD/DVD burn buffer underruns even at 1x speeds when ever I tried to burn data from a disk on the on-board ATA interface to the optical drive on the other on-board ATA interface. Burning from the PCI ATA66 disks is reliable for CD 16x and DVD 4x.
G3 Desktop, SonnetEncoreZIF G4 1GHz, 768MB, WingsAV-6MB, DVR-106D, 60GB Maxtor Mac OS X (10.4.7) PCI: TempoUltraATA66-120GB Maxtor, 120GB Seagate; TangoUSB/FW; ATI9200-17"+20"

Labview ActiveX Server PATH if in development environment

I'm using Labview 2010 to build an ActiveX server. I can access the executable as an activeX sever from both C and LabVIEW clients. No problems there. But now I want to do some debugging in the development environment while accessing the program via an ActiveX client. In such a situation, how do I change how I access the VI's in the project? I tried using the lvproj in place of the EXE, but this was insufficient. Seems a little convoluted with the changes required to do this debugging.

I think that I already have my answer in that I can not generate a LV event through an ActiveX interface regardless of the type of control, but if you want to play with it, here is a Demo which I derived from the previous link given above. Within the attached ZIP file, read the "Readme.txt" file for instructions. Specifically the program assumes that is located in C:\tmp, since LabVIEW doesn't like relative pathes in both the build and reference node paths, (so they are coded with absolute pathes). If you use C:\tmp, the instruction in Readme.txt should work.
What happens is that you click on the button in the ActiveX Client running in the LV development space.
You can see the control value change shade/color in the ActiveX Server EXE application,
but because no event is generated, the Event Handler does nothing.
I know that I can poll the value of the control and then use the Value (Sgnl) property control to generate an event, but this isn't a very clean solution.
All code in the ZIP file is LabVIEW 2010 release1
Attachments:
LV ActiveX Demo.zip ‏172 KB

Labview activex server registration incomplete.

I made an ActiveX server using LabVIEW. The server should communicate with Excel. During installation of the server I register the server: "Server.exe /RegServer". When I try to call the server from Excel/VBA, it responds with "Run-time error '429': ActiveX component can't create object". The server is only recognized by Excel after I have started and stopped the server once.
When investigating the registry, it appears that the difference between registering with /RegServer and just starting and stopping the server are the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ServerName.Application
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ServerName.Application.6
To my opinion the /RegServer commandline option does not do the whole job.
Also /UnRegServer does not remove the above mentioned registry keys.
Is this a bug or just normal behaviour?
Has it been solved in newer LabVIEW versions (I use 6.0.2)?

Hi,
I've tried to call a with LabVIEW 7.1.1 created activeX server. This works without any errors. I've attached my code.
As for the register keys, this seems to be the default behaviour of ActiveX, each server has a key without version number e.g.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ServerName.Application
And one or more with a version number:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ServerName.Application.6
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ServerName.Application.7 Kind regards,
Karsten
Applications Engineer
National InstrumentsMessage Edited by KvZ on 07-27-2005 02:37 PM
Attachments:
ActiveX Server.zip ‏45 KB

LabView TEDS library into DLL or ActiveX Control so that I can use it in C or Visual Basic?

We are developing software in LabWindows/CVI and Microsoft C. I heard that LabView can generate DLLs. Can I turn LabView TEDS library into DLL or ActiveX Control so that I can use it in C or Visual Basic development environment?

Technically what you are proposing is possible with LabVIEW. With LabVIEW's application builder, VIs can be built into dlls. Also, LV has ActiveX hooks and so you could create a system for calling into it from CVI. However, this is not what I would recommend.
The LabVIEW VIs have been written to a preliminary version of the IEEE specification (1451.4) that describes the TEDS data which is primarily why I'm advising you against using them. Once the IEEE spec is approved (the current timeline is currently late March), it will become public and you can write your own code according to the specification (or wait for someone else to write it). To help you get started, the spec includes flex and bison code that describes the syntax and structure of the template files
Internally, we've written some C, C++ and Java code to the preliminary version of the spec and we've found that we can duplicate the functionality of the TEDS Library for LV in roughly 2 weeks in any other language.

How to call LabVIEW ActiveX dlls into VB6

I'm jumping in on a project written primarily in VB6. I'd much rather wirte code in LabVIEW so what I am looking for is some example code for calling LabVIEW activeX dlls into VB6. Does anyone have example code? I need to see how the LabVIEW libraries and classes are called and used in VB6.

Hi Drewdafis,
Refer to this link for example code on calling a LabVIEW DLL from Visual Basic.
Hope this helps!
Best Regards,
Jonathan N.
National Instruments

What type of component do Labview developers prefer? COM/ActiveX, C++ DLL, C DLL?

The last time I used Labview was about 5 years ago and I have not kept
up with the changes.
I assume Labview can use COM components, ActiveX (COM with a GUI), C
DLL's, and possibly C++ DLLs. Of these types, which do Labview users
prefer?
Background
I need to develop a component that can be used by both VB and Labview
users.

Ed,
LaBVIEW can use COM/ActiveX components, C dll's and C++ dll provided that the c++ dll has direct function calls(you can always use a wrapper dll to call functions inside a class)
As far as what labVIEW users prefer, this is kind of a difficult question to answer since it is mostly dependant on the users knowledge of each of those components.here are a few links that may interests you.
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/5401be584fbaeece862567c2006d36c7?OpenDocument
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/7f41004ee990d4da86256a9d0064d522?OpenDocument
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/3a1f4b7cbc68b636862567cc004d5cca?OpenDocument
and more gener
ally
http://zone.ni.com/devzone/devzone.nsf/webcategories/4161F118BF99CCE686256AB7006A68EB?opendocument&node=DZ53001_US
Regards,
Cyril Bouton
Applications Engineer
National Instruments
Cyril Bouton
Active LabVIEW Developper

LabVIEW built-in file I/O VIs have poor performance on network file I/O operation?

Hi,
I use LabVIEW built-in VIs to save a big 2-D array data into a ascii file (with the "write character to file" vi). When I write it on the local hard drive, it takes about 5 seconds to complete the task. But when I write the file on the network, it takes more than 5 minutes. A typical output file is 5MB big.
If I write the file on the hard drive, and use the built-in File MOVE vi, it takes about 30 seconds to complete the MOVE operation. But if I use Windows File Explorer to move the same file, it takes less than 1 second.
Both the PC and server are connected on a full-duplex 100BaseT network. I tried different file I/O operations (including MOVE, create new file and LIST)
with LabVIEW VIs and compared the speed with windows file explorer. It turned out LabVIEW VIs performance is always A LOT slower than Windows File Explorer. I tried the same test on many different PCs, with windows 98, NT, 2000, and the results are the same.
Is there anyway to improve the file IO performance or is there any other workaround on this issue, such as calling Windows File Explorer to perform the same task via ActiveX maybe?
Your imputs will be very much appreciated. Thanks!
Dan

Hi,
Do the ASCII files have a .txt extention? I've noticed the same behaviour
once, with .txt files. Renaming them (to e.g. .txq) fixed the problem.
I'm clueless why this happend. If you extentions are not .txt, I don't have
a clue...
What if you copy the file, and then delete the original?
Regards,
Wiebe.
"dikrn" wrote in message
news:506500000008000000EA7C0000-1042324653000@exchange.ni.com...
> Hi,
>
> I use LabVIEW built-in VIs to save a big 2-D array data into a ascii
> file (with the "write character to file" vi). When I write it on the
> local hard drive, it takes about 5 seconds to complete the task. But
> when I write the file on the network, it takes more than 5 minutes. A
> typical output file is 5MB big.
>
> If I write the file
on the hard drive, and use the built-in File MOVE
> vi, it takes about 30 seconds to complete the MOVE operation. But if I
> use Windows File Explorer to move the same file, it takes less than 1
> second.
>
> Both the PC and server are connected on a full-duplex 100BaseT
> network. I tried different file I/O operations (including MOVE,
> create new file and LIST) with LabVIEW VIs and compared the speed with
> windows file explorer. It turned out LabVIEW VIs performance is
> always A LOT slower than Windows File Explorer. I tried the same test
> on many different PCs, with windows 98, NT, 2000, and the results are
> the same.
>
> Is there anyway to improve the file IO performance or is there any
> other workaround on this issue, such as calling Windows File Explorer
> to perform the same task via ActiveX maybe?
>
> Your imputs will be very much appreciated. Thanks!
>
> Dan

How to make a LabVIEW application into a screensaver?

How can I turn my Labview application into a screensaver. I read an old email from Jean-Pierre Drolet from 2001, where he writes that you only need to make a application of your .VI and then change the extension from .exe to .scr, rightclick and 'install'.
When I did that I got some error msg. in the 'display properties' 'screensaver' ... %1 requires %2 ... (cant see all). Does anyone know the answer how to make it correct?
(if you want a more difficult task.....)
To make it a complete screensaver the program should should act differently according to commandline switches:
/s : enter screen saver mode
/c : enter config mode
/p : enter preview mode
How to make it?
I would be happy if someone could ans
wer my first question(that easy part).By the way im running Laview 6.1 on a win 2000 comp.

Just made a simple VI with no menu or title bar, set the window size to always fill the screen and built it as application.scr. Installed it...everything OK. However if the RTE is located in the same directory as the application launching it returned an error saying the application could not find the neccesary resources...that might be what you see as well...(?).
On a machine with LV installed the RTE is already available so that is not a problem...Making it respond to commandline switches can be done either using the new commandline functionality of LV7 or using the commandline dll you can find here on the zone...it allows the application to capture and act on the commandlines when the application is launched.
Now you may want to add code in your application t
hat reacts to mouse actions so that the application terminates when the user moves the mouse /clicks a key etc...like other screensavers do. Use an event structure to capture such events...
Here's a general description on how to create screensavers that also applies in this case (nothing new there..but just to show that the procedure you already have is as MS says...):
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b146907
MTO

Problems using Labview as ActiveX Server

Hello,
       I have been having difficulty using Labview as an AcvtiveX server. I have reviewed all the postings on this subject and most are either pre Labview 8.2 and thus do not account for the changes made between 8.2 and 8.5 which broke the Activex server functions. I have looked at the recommendations for changing the to code to export (exported vi's in a DLL or Source distribution) and have tried these with no success. The closest example I have found was posted here http://forums.ni.com/ni/board/message?board.id=170&thread.id=283417 the example code they posted does ont work for me and still generates and error 3005.
      What i need is simple. I want to turn my applicaiton into a Vi server.. Expose a vi that acceses elements in the Vi server.. (controls, queues, Globals etc) that are in the Vi server context. I would then like to build a vi .. or dll that calls the 'exposed' vi in the vi server to pass data to or from the vi server. The V test.zip example file in the above indicated post is a pretty good example of this .. it just does not seem to work when i build it in 8.5. Are there any GOOD and 'current' examples of using labview as the ActiveX server (Compiled) and calling exposed vis from an external application Labivew, Visual Basic.. etc?? I am only interested in cases where Labview is the Sever. or both client and server.
       I have used a tool "ActiveXplorer" to examine the registered "exe" when the viserver is run. It always shows that there is no Type Library associated and the object is not creatable. There is a .tlb created by the project build however, where as the previous version 8.2.1 of Labview did not build that correctly. I have also tried this on 8.6 with similar error 3005 generated. sooooo what am i missing?
      Thanks
       Louis Ashford

Mike,
       Thank you for your response to my question. The problem is that the example you site does not use the Labview vi as the Server. Excel is actually the vi server and the automation open is using and excel automation object. I am sure that Excel creates proper automation objects .. Labview however does not seem to. So while this example shows how labview can function as a client it is not an example of a compiled Labview Sever being accessed by a 'laview vi'. Possibly I am not looking at the vi that you are thinking of.
       The examples i am aware of:
                   "ActiveX Event Callback for Excel.vi... (Excel is server not Labview vi)
                    "ActiveX Event Callback for IE.vi (same Labview vi is client)
                    "Write Table to XL.vi" ( again excel is the server)
                    "3D Graph Properties - Torus.vi" (accesses an activex Control 'not' and Activex EXE)
                    "3D Lorenz Attractor Draw at Compeltion using 3D Curve.vi (Uses an activex control not activex Exe server)
                    "3D Parametric Surface - Ribbon.vi (Uses an activex control not activex Exe server)
                    "3D Surface Example - Fluctuating Sine Wave.vi (Uses an activex control not activex Exe server)
                    "Excel Macro Example.vi (Uses excel as automation server..not Labview)
                    "FamilyTree.vi (uses MSComctlLib.ITreeView object not Labview as server)
                    "SlideShow.vi" (uses PowerPoint._Application not Laview as server)
      Most of the posts I have seen are for versions prior to Labview version 8.2 (where the ActiveX server was broken) I have seen only a few posts that actually address the issue i am talking about. however thus far no real solution has been offered. I get the same results when compiling and testing this with 8.6.. as well. So have you tried this Mike? Possibly i am missing something very simple..
      The example i did find and gave the link to is a pretty simple one. This does not work on my machine at all. You can select the automation server that is registered with windows after running the server one time and this then breaks the client vi.. I have found by reselecting the GetViReference property node in the Client vi that it will the 'fix' the client vi as far as labview is concerened and it no longer shows and error. Now when you run the Client vi it will infact find the vi server and will launch it ok. However. The open automation object then hangs.. for quite some time then returns the error
"Error -2146959355 occurred at Server execution failed
in Client_reader.vi" Obviously the automation Exe (server) was seen because it was opened yet it did not return a valid reference so the subsequent property nodes in the client.vi will fail. Something is wrong with Labviews opening of or creating of automation objects..
          Thanks,,
                Louis Ashford

Distributing an Application that calls Visual Studio built DLLs

I have a LabVIEW application that calls a Visual Studio 2005 built DLL, that then calls functions from another Visual Studio built DLL. When trying to distribute this application it will execute perfectly well on all machines with Visual Studio installed, but on any machine that doesn't have Visual Studio installed, despite installing the Visual Studio Redistributable Package on the machine, I get the error message on attempting to run the application:- "Missing External Function 4575Interface.dllname of function):C in (sub VI that uses function).vi" for the 10+ VIs that use functions called from that dll.
Any suggestions?

Hi,
You will need to manually add all of the DLLs you
are calling into your LabVIEW project. Check in the folder
"Dependencies" in your Project Explorer what external DLLs the VIs are
using, then drag and drop those DLLs into your project. LabVIEW will
not automatically include these external DLLs when you specify a build
specification unless you explicitly tell it to do so. When you
distribute the application using an executable, always explicitly
select those DLLs as "Always Included". Finally, register these DLLs on
the target machine by using Windows command: regsvr32.exe. I would recommend you to write a Windows batch file *.bat to ease the deployment process.
Another
point to note is, the DLLs you will find in the folder "Dependencies"
are the DLLs LabVIEW automatically recognized through what you are
calling in your program. However if any of these DLLs is linking some
other DLLs, LabVIEW will not be able to detect them on the build, so
you will need to add the DLLs into your project manually for
distribution.
Hope this helps,
Best regards,
Mark M.
Applications Engineer
National Instruments UK & Ireland

How to implement an ActiveX server in LabVIEW

My task is to implement an ActiveX server in LabVIEW 8.0 that will be called from a data management software (DXE).
The LV server will take care of data acquisition and control.
I have been looking for tutorials and example code at the NI developer zone and elsewhere without any progress. Information is either to general or code is to old (LV 5.1) to give any help.
Please, show me to a good example of an ActiveX server in LV 8 properly commented or with attached explanations.
Alternatively, suggest any tutorial, short course or books with practical instructions.
Specific information is most welcome.
I suppose that it is possible to write a ActiveX client in LabVIEW to verify the functions of the ActiveX server ?

rolfk wrote:
skalis wrote:
Thank You. Good to know that I am on the right track.
However,
Your sentence "If You look at the several shipping examples..." make me
little concerned. I am not able to find any example of a LV ActiveX
server in my LV 8.0 installation. I would be very grateful of You can
send me any.
Basically you can not create your own
Active X server with your own object hierarchy and methods in LabVIEW.
LabVIEW however can export a predefined Active X server interface that
is just another access method to its internal VI server interface.
With this interface you can determine what VIs are available to
control, load specific VIs from disk if you know their path and,
execute those VIs and passing parameters to it and receiving outputs.
So if your software allows you to script the Active X access to an
Active X server in some ways such as VBA or similar you should be fine.
If your software expects a specific Active X interface you have to
implement in the server application, you are out of luck with LabVIEW,
without using an external component such as an extra Active X server
DLL that translates between the expected interface and the exported
LabIVEW interface. But this last method is quite likely not worth the
hassle.
Rolf Kalbermatter
While I did follow the link mentioned above and found the Interop.LabVIEW.dll that is included in the C# project for the purpose of calling VIs from C#, I am frustrated that these methods are 'buried' in a .dll that you have to go and find on the NI web site, and are not ActiveX methods that are available in an ActiveX Object that is installed when you install LV 8.20 PDS.
Rolf, I don't know that you will get this email, but are you refering to the methods inside of the Interop.LabVIEW.dll in what you are saying above, and if so, how did you become aware of this .dll?
Is anyone aware of any documentation for these ActiveX methods?
Thanks,
Wes
Wes Ramm, Cyth UK
CLD, CPLI

Turning a LabVIEW built DLL into an ActiveX server

Similar Messages

Maybe you are looking for