How about other platforms?

[tarheel_hax0r]

Is it possible to run LabVIEW as a service on a WinNT kernel [NT 4.0, 2000, or 2003]?

I.e. is it possible to run LabVIEW without a user logging on?

Or must there always be a user logged on before LabVIEW can be run?

Also, if standard-issue National Instruments LabVIEW cannot run as a service, then are there any third party products [maybe from Endevo, or Vogel Automatisierungstechnik] that have the ability to create something like a "LabVIEW-lite" that can run as a service [without a user logon]?

Thanks!

[tarheel_hax0r]

Let me add a follow-up question: Is it possible to run either LabVIEW, or some sort of hypothetical "LabVIEW-lite" on any of the other platforms [Linux, OSX, Solaris] solely as a "service" [or, more properly, a "daemon"] without a user logon to a windowing system?

[Lycangeek]

Windows
=======
LabVIEW code can run within a service, but LV does not support being built as a service.

What is the difference? An NT Service requires a special exported API and integration with the NT Service Manager. We do not build that kind of EXE, just the regular EXE. However, you can build your LV application into a DLL and then load that up from your own service host EXE.

However, there are a couple of gotcha's that happen when running as a service. First remember that you cannot have any UI - so if any of your VI's attempt to open their front panel, you are going to be in trouble. Second, there is an issue with pumping Windows messages in LV right now. See my blog article on ASP.NET and LV (which is LV running in a service - the aspnet_wp.exe service). My blog link is in my signature.

Also remember that while a service doesn't need a user to log in, it itself is going to log into Windows to get the security credentials. You'll need to think about what credentials you want the application running under when you configure the NT service. Remember, Local System, which is the default, means that you have super user priv. on the local machine, but no NT Network permissions. It is generally a good idea to create an NT Workgroup or Domain account specifically for the service so that you can control what permissions it has.

Other Platforms
===============
Linux and Solaris daemons are a bit more straightforward and so, I think, both the EXE and DLL should work. However, I haven't done daemon work in over 10 years so I won't promise anything 🙂

I have never worked on a Mac so I have no idea. But X is really a Unix OS so I imagine it would be the same as Linux. However, for all platforms supported by LV, building into a library and then calling the library from the OS's service host *should* work. Just the same rules about the UI.

[tarheel_hax0r]

However, you can build your LV application into a DLL and then load that up from your own service host EXE.

So, first of all, I will need to upgrade to LabVIEW Professional, and use Application Builder?

And I assume Application Builder will include a tutorial on how to compile to a DLL rather than an EXE?

Second, there is an issue with pumping Windows messages in LV right now.

Okay, I found your post at the end of the May archive:

http://detritus.blogs.com/lycangeek/2005/05/index.html

I'm not all that familiar with windows messaging & the single threaded apartment model, but in LabVIEW terms, would this affect two windows that tried to communicate via LabVIEW queues or semaphores? [I assume you get queues and semaphores with Application Builder.]

Hey, while I've got your attention, let me pose this in a slightly different fashion. Suppose I wanted two computers to communicate, and let's suppose I chose NI DataSocket Transfer Protocol [DSTP]. How well would the different flavors of NI DSTP communicate with each other? For instance, how well do these combinations two work?

[Computer A] --- DSTP ---> [Computer B]
 
SCENARIO ONE:
[client computer, user space, classical LabVIEW VI]
     --- DSTP --->
          [server, background service, DLL built with Application Builder]
 
SCENARIO TWO:
[client computer, user space, classical LabVIEW VI]
     --- DSTP --->
          [server, background service, EXE built with Measurement Studio's DSTP library]

If the second scenario works pretty well [bug-wise], then maybe I could write my service in Measurement Studio, and use NI DSTP as the glue that connects the two computers.

If not NI DSTP, do you have a better suggestion for communications - maybe NI OPC [Ole for Process Control]? Although I'm not sure whether OPC has been ported to classical LabVIEW.

[tst]

As a sidenote, here's a tutorial for creating a service.
I'm not sure about using DSTP between MS and LV (it should probably work), but at the very least you should be able to use low level TCP between LV apps. Also, LV supports OPC with the DSC module (extra $$$).
Your best solution is probably DS or your own TCP messaging between two LV apps.

[Lycangeek]

Thanks tst - I really need to sit down and look through all the various tutorials, etc. that are available for LV - lol.

tarheel_hax0r, as to your other questions

1. Yes, you will need the App Builder in order to do this. You can't turn the LV development environment into a service.

2. I know - I can geek out a bit sometimes. However, the whole issue about pumping messages can be rephrased as "windows messages are the blood that LV needs, thus you must be the heart and pump them". Hmmm, that is kinda gross...but accurate. It isn't just two LV front panels that are trying to talk to each other, it is just about anything in LV. We use those messages for all sorts of internal communication. So even if you have no front panel at all (such as in a service), the messages must still be pumped.

BUT - this is only an issue if you build into a DLL. As tst pointed out, there is a tutorial to turn a LV EXE into a service. This gets you away from the problem as the EXE does the work of pumping the messages for you.

3. I haven't really worked with DS much, but I'll see if someone from Measurement Studio can take a look at this thread and post something.

[Elton Wells]

Measurement Studio, CVI, and LabVIEW can all communicate with each over via DSTP, so your second scenario should work. The service would be easy to create with .NET and Measurement Studio. A brief overview is described in "Creating Windows Services." A more detailed overview is described in "Walkthrough: Creating a Windows Service Application in the Component Designer." However, note that both the Measurement Studio C++ and Measurement Studio .NET DataSocket interfaces use the DataSocket ActiveX control beneath the covers. This means that the DataSocket part of your service will need to run on an STA thread and you will still have to deal with pumping Windows messages as Brian described earlier.

Depending on the nature of your application, another option that may be easier would be to create a web service with .NET and Measurement Studio and then communicate with the web service from LabVIEW. The Developer Zone article "Building a Web Service-Based Application in LabVIEW 7.0" describes how to use a web service from LabVIEW.

- Elton