Headless Application?

[hendra@ngms]

I want to make a headless CVI application.  What do I replace RunUserInterface() with?

All the action will happen in spawned threads.  There will be a couple TSQ handlers in the main thread, and the Quit callback.

I thought of doing something like this to replace RunUserInterface():

while (runFlag)

{

if (quitFlag) CallCtrlCallback (QuitCallback)

ProcessSystemEvents();

Delay (????);

}

quitFlag would be asserted from one of the other threads.

But, I'm not sure how much processor time is consumed by something like that.  How many machine cycles does a Delay call consume -- minimal or maximum?  Naturally I want minimal time expended in this main thread, so that maximum processor resource is available to the other threads.

Ideas?  Experience?

[jr_2005]

Delay() is a busy wait function, which will therefore leave very little processing time for other threads. Look at using the SDK Sleep() function instead, which consumes virtually no CPU time.

JR

[hendra@ngms]

Sleep() sounds like the right thing to use.  How do I include that, ie, which .h file to include?  Without getting a bunch of redefinition errors.

[RobertoBozzolo]

simply #include <windows.h>

[mvr]

Make sure that windows.h is the first header file called, it will cause problems if you include it after other cvi header files.

[mvr]

This example also provides an older but very simple method to implement event processing in CVI without RunUserInterface()

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3DBA956A4E034080020E74861&p_node=DZ52172&p_source=external 

[menchar]

I've built headless applications with CVI and they work fine, though we run them on NT 4.0 not the NT 5.x sysems (2k, xp).  I'd think they would work on the newer OS's.  We did critical launch support for PanAmSat 9 in July 2000 using a headless CVI app running on an NT system on the Boeing SeaLaunch platform (controlling the DC power going through the umbilical to the satellite).   The system worked fine, you can see a photo of the launch here:

http://www.boeing.com/special/sea-launch/past_pas9.html

The launch was valued at $165 million - I wonder how many CVI apps control a system of that value 😉  I know my heart went pitter patter a few times 😉

You can use XP embedded I'm sure to create a headless system - that's what it's for - but I bet you can make regular XP Pro and 2K pro do it too.

I called run user interface (so timer and com callbacks would work), but the application would run without any user input (in fact the system didn't normally have a monitor, keyboard, or a mouse - just com links / ethernet.)  Program activity occured due to com callbacks when info came in from the com links, and I used a heartbeat timer on the main panel to periodically run any code I needed for housekeeping.  The video card didn't "know" that no monitor was hooked up.

So you could design your app the same way - if you do hook up a keyboard / monitor it will run interactively - or you could design it to simply never run a panel (don't call RunUserInterface) and directly execute code.  There's no rule that says you have to have a GUI in a CVI application.  Getting asynchronous callbacks to work might take some thinking.  There's no rule that says the if you do use a panel that it has to be visible either I don't think - but if the monitor's not there you don't care if it's visible or not.  I never tried running the app without a video card - don't know how or if that would work.  I bet XP embedded runs without video at all.  We had on-board video so it wasn't an issue for us.

I had to diddle some registry entries to get an autoboot with the user name / password /domain I wanted.  I also used a routine that spoofed the system into thinking it had a mouse / keyboard when none existed (I think it was called mousekey.exe).  I think I diddled the BIOS to push past any "keyboard / pointing device not detected" errors as well.  And you need to ensure that nothing you do with the app can cause a popup - 'cause there's no monitor to see it with.

XP's bulit-in remote terminal would allow you to run the system headless from another PC over a lan / com port I would think.

See Managing The Windows 2000 Registry ISBN 1-56592-943-8 page 366.

Delay() is not a busy wait according to NI.    Sleep() works fine, but won't react to any callbacks.

Menchar

[hendra@ngms]

To JR_2005:  Thanks for the info about Delay vs Sleep.  Seems there are two opinions here about whether Delay is a busy wait or not busy wait.  Is there an NI person here who has the definitive answer?

To RobertoB and mvr:  Thanks for the info about #include windows.h .  If Delay is truly not a busy wait, then I'll avoid windows.h.  I have not yet looked at the example, but will.

To Menchar:  Thanks for the info about running a headless system with a panel anyway.  Your story of PanAmSat and SeaLaunch is very interesting.  I spent most of my career in aerospace at Loral, so I'm familiar with that stuff.  I can understand about the heeby-jeebies when an expensive misison depends on your little box.  Been there, done that, got the T-shirt....

[mvr]

Using Sleep() or SleepEx() is painless, if you have any trouble let us know.

Delay() blocks events in the thread you are in.  It does not block other threads on an XP system.  It does seem to consume  much of the time slice the thread is allocated in.  Which you use will depend on how efficient you really need to be to get the performance you need.

>>Sleep() works fine, but won't react to any callbacks.
You can use the SDK function MsgWaitForMultipleObjectsEx() which allows your thread to sleep but to be awakened by some types of events. 

The methods described above of implementing a headless system with XP etc work just fine.  Just for completeness here is another option, LabWindows/CVI Realtime.  Embedded and headless systems are very much the target for this OS.

https://www.ni.com/en/shop/electronic-test-instrumentation/programming-environments-for-electronic-t...

Message Edited by mvr on 09-19-2006 01:14 PM

[menchar]

NI has told me directly that Delay() is not a busy wait, though you can't tell how they implemented it.  I think another NI guy claimed it calls ProcessSystemEvents() too - but if it does, that's undocumented as well.  You could code a long delay and look at the app with task manager to see if it was busy waiting or not.  I think it isn't - that would be extraordinarily poor form.  I've asked about delay() several times in the past.  It's great fun getting different answers 😉

I use a sleep call with the delay broken up into chunks that actually sleep(), and I process system events in between sleep() calls.  This avoids a busy wait and keeps the gui responsive.  Win32 SDK has a form of the sleep command that processes windows messages to provide the same sort of functionality.  But the native windows messages are trapped by CVI normally and NI uses its own event model which of course is different.

NI wants the source to run on WIn32 as well as Unix/Linux, and the Delay() call provides portability.  But if you're going to only run on Win32 platforms, I say go ahead and Sleep() instead.

I never got a T shirt but I did get a cute triangular metallic PAS 9 program pin - better than a tee or a coffee cup I say.  What I really wanted to do was to go out to the equator with them on the launch platform or the command ship but they wouldn't take me along 😞

Menchar