labview application as a windows service

[carrasquel]

Greetings, I have a problem with a LabVIEW Application, I created an application that logs OPC Tags with the datasocket read function, I had this working well as a windows service from an executable, but to improve the performance in the data acquisition, I decided to make an asynchronous call of the OPC Tags, the executable of this applicacion works well, but when I try to run it as a service it doesn't work properly, the log file (tdms) doesn't report any value, even I can't debug services without a GUI, I believe that the problem is indeed in the changes I made, has someone used asynchronous calls in executables and in services?... best regards!

[Hooovahh]

If it runs fine as an EXE, but doesn't as a service, I'd suggest using basic File I/O as a debug log to then open later and see what the software is doing.  I have code that can log each state in a state machine but even without this you can just drop down some log VIs and see what parts of the code are executed.  Hopefully you have some basic error handling and those could be logged too.

[James.M]

Gosh, I hadn't even thought of running a LV application as a service. I have an executable I made that just hides itself when it first opens and shows popups when it encounters anything. Are popups possible with a service? Is there a performance bonus for a service vs exe?

[carrasquel]

That doesn't sound bad at all, how can I hide the main labview application?

[James.M]

So you have to do two things:

1. Hide the front panel when launched, so the first thing your VI does is hide itself. You can make the front panel run 100% transparent too, if you want.
2. Hide the root window, so that the application doesn't show up like normal (no taskbar icon, not in application list in task manager, etc)

You can create a post-build VI that runs after you compile your executable that goes and makes the change to the config for the root window hide. This is what I made my post-build look like:

[Hooovahh]

---

@James.M wrote:

Is there a performance bonus for a service vs exe?

---

The main reason someone might do this, is so that their EXE is ran without having to login to the PC.  If you have a locked down server, that has no monitor plugged in, and only can be accessed by remote desktop, which forces you to have credentials (not just login when powered on) then your PC will be sitting at the login screen when you power it on waiting for a user or remote desktop session.  If you want a LabVIEW exe to run just on power on in this situation, running it as a service is a way to do that.

There probably is a performance bonus just because you aren't going to be running the other 30+ applications that run on startup when a user logs in.

[Sam_Sharp]

I have written a LabVIEW application which runs as a service (used for monitoring a large number of test rigs within our company), here's some of the things I learnt:

1) When it runs as a service, you have no access to any sort of user interface - the application runs in a 'console' session which you have no access to. To get around this problem, I wrote another application which runs in the tray icon (search for .NET TrayIcon and there's a LabVIEW wrapper and I used the HideRootWindow=True INI key) and I use that to communicate with the service over TCP/IP. Be careful if you have any blocking dialogues that might appear (e.g. automatic error handling) - your program will hang and you won't be able to dismiss the dialogue.

2) It usually runs as the SYSTEM account - this means it can run as administrator and also can be set to run before a user has even logged on

3) I used a program called 'srvstart' which essentially allows you to run a wrap a regular executable as a service - it even handles restarting the service if it stops responding and can also be used to shutdown the service gracefully when the PC shuts down

4) Using the remote debugging and desktop execution trace toolkit can help you to debug your application while it's running as a service