Executable created by CVI 5.0 takes over Windows

[elersebn]

Hi,

We are manufacturers of meter, mix and dispense machines. Our system runs from a dispense software created by CVI on Win 95. The odd thing with the system is the CVI software tends to take over Windows whenever it is executed.

In other words, if the machine is running the dispense software, we are not able to open up another Windows appl. like Calculator. Whenever we start whatever windows application, our system hangs up and goes into a weird frozen state. In this state, all the digital and analog inputs through Diamond system I/O boards gets messed up.

Anyways, we also wrote some diagnostics applications using CVI. They all make windows behave the same. Whenever another windows appl. is brought up those CVI
executables hang up. I find this really weird. Could you please explain why thee executables would hang up like this.

Regards,

Sebnem

[RGSchmidt]

There are a series of other things to look for:
1. What was the CVI sleep policy set to? This can found under the project "Options" and then "Environment" menu. If it is set to "Never Sleep" this will cause that problem.

2. Have you created any threads that don't give up the processor and wait on an event?

3. What is the speed of the data acquisition? Are you continuously buffering or processing the data without giving up the processor?

4. Win95 will not interrupt the CVI app (it does not support pre-emptive multitasking). It is the responsibility of the application to yield the processor. This can be done with the ProcessSystemEvents() call.

These would be the first things to look at.

Good luck.

Randy Schmidt

[Al_S]

I would also look at how much memory the PC has and consider adding more RAM and disk space (for virtual memory).
Randy makes some very good points. Probably the most common problem is related to Randy's point 4. If you have some long, tight loop or a callback that never returns, you need to periodically call ProcessSystemEvents() and maybe ProcessDrawEvents() in that loop or callback.

[elersebn]

Thanks Randy for your comments. But the thing is when another windows appl. is brought up, that windows appl. is running well, it is my software that hangs up, because all the I/Os are somehow messed up when another appl is borught up. You are saying my CVI created software is not yielding the processor, so is it why CVI app will hang up even though the other windows app is running ok?

[RGSchmidt]

I don't have a good answer.

You may want to run the application that monitors processor usage, processes, etc. I do not remember what it is called under Win95. It is the equivalent of the functionality available under the Task Manager for Win2k and XP. It may be an app that you need to download from the Microsoft site since I can't remember whether is was part of the standard Win95 installation.

Randy

[Al_S]

Are you relying on some software timing algorithm to generate your I/O?
How is your I/O messed up? Could it be that it's just not happening when you expect it to, so you get unexpected results? Have you measured a signal that is relatively constant and got a value that's not even close?

[Al_S]

Win95 shipped with a System Monitor and a Resource Meter. They were options to install. Click Start >> Programs >> Accessories >> System Tools and see if they're there. If not, you can install them from your Win95 disk: click Start >> Settings >> Control Panel >> Add/Remove Programs >> Windows Setup. Double click on Accessories, then scroll down and select System Monitor and System Resource Meter, then click OK. These programs won't show you how individual programs are doing, but they'll show you the overall Windows resources.

[elersebn]

Randy,

I am looking at the ProcessSystemEvents() call. If I call this function in my CVI code does it mean that:

Whenever a Windows appl is brought up the CVI application returns the control of the processor to that Windows appl?

My application has a while(true) loop, and it executes that loop all the time. Could this be a problem?

Thanks,
Sebnem

[Al_S]

ProcessSystemEvents returns more control to Windows, not to any particular Windows app.

Here's some of the help on ProcessSystemEvents(). While inside of a callback function ..., user interface and system events are not processed. If a particular function is overly time-consuming, it will essentially "lock-out" user interface and system events. To force these events to be processed, call ProcessSystemEvents() occasionally in the code that is locking out system events.

Why do you need an endless loop in your program? If you're waiting for a button to be pressed or a value to be changed, that's what RunUserInterface() and callbacks do.