Windows 2000+sp3 Tables Problem

[Shako]

Hi

I have a big problem, i am running windows 2000+sp3 on P3 600Mhz. i created a program which gets information from a Profibus card and then displays it in a Table Ctrl.(Attached snap shot)

The problem is that when i display this values using SetTableCellAttribute() the cpu usage shoots up to 98%, if i comment this function (All background function still work just not displaying to the screen) the cpu usage is 20%.

Why is this and is there a solution with out me having to upgrade the spec of my pc ?

My thinking was that the is a problem with Windows 2000 and table or cvi programs.

Thanks 

[RobertoBozzolo]

Hi Shako,

the table is a rather complex control which can consume several resources and may slow down program execution while it is updated. Even though I haven't found such a critical situation, normally hiding the table while updating it helps solving both problems. The correct procedure is then:

1. SetCtrlAttribute (panel, control, ATTR_VISIBLE, 0);

2. SetTableCellVal or SetTableCellAttribute

3. SetCtrlAttribute (panel, control, ATTR_VISIBLE, 1);

There will be no visual effect as long as you are not updating the screen during the process, using ProcessDrawEvents or ProcessSystemEvents or terminating the callback. The table must not be the active control: if your table is in indicator mode you'll have no problem, otherwise you may need to check whether it is and switch to another control in case it is.

Additionally, as of my experience using SetTableCellRangeVals is faster that the corresponding cell addressing one by one: since almost all your data are numeric ones, you may benefit in using the array function.

[MJF]

Is this CPU usage really impacting anything? 

If it is slowing down other applications... use the SetSleepPolicy function with VAL_SLEEP_MORE or VAL_SLEEP_SOME. This may help with the processor impact.

If it's not slowing down something else, I would suggest not worrying about it. Just because an application grabs all CPU resources for some amount of time doesn't necessarily mean there is something wrong. A lot of programs do that.

[Shako]

It doesnt slow other applications down but it does slow the user interface of the program drasticly.

[Shako]

Quote :

>> 1. SetCtrlAttribute (panel, control, ATTR_VISIBLE, 0);

>> 2. SetTableCellVal or SetTableCellAttribute

>> 3. SetCtrlAttribute (panel, control, ATTR_VISIBLE, 1);

I have tried this and it has no effect. I even tried using SetTableCellRangeVals();

[RobertoBozzolo]

Well, we are now coming into performance issues that depends heavily on the machine characteristics.  A P3 600 Mhz surely isn't a very performant machine, so you will need to tailor your application in order to spend processor time at the best. In this scenario, the application structure can have a huge effect on its performance and on the readiness to respond to user action.

Is your application single-threaded or multithreaded? In the second case you may have some effect reducing the user interface time with the sleep policy as per MJF suggestion and contemporarily increasing the operating thread sleep policy to VAL_SLEEP_NONE.

Which is the acquisition rate you want to achieve? Do you need to display all the acquired measures or may you limit to displaying one set of measures every 'n'?

I see in your user interface you are monitoring several devices, whose display tables are loaded on different tab pages: are you updating all of them on each run or are you updating only the visible tab one? Limiting to update the visible device only can dramatically reduce application requests.

It's not clear which table you are updating and wether it is in indicator od edit mode: do you remember to guarantee it is not the active control while trying to hide it?If not, hiding it will be ignored.

[Wolfgang]

So far, I have not used tables in CVI and hence can not really assist. But it might help to keep the table as short as possible and replace entries rather than inserting new ones continuously.

[Shako]

>>Is your application single-threaded or multithreaded?

I am use a single thread.

>>Which is the acquisition rate you want to achieve?

 I need to display all the values i recieve.

I do update all of them.But the screen shot i attached i was only updating and aquiring from one device(the one with the green label).

If i change the tab to one without continualy updating values the processing drops to 20%.

The table in the screen shot is in indicator mode and is the only one i am updating.

>>do you remember to guarantee it is not the active control while trying to hide it?

I will double check that one.

[RobertoBozzolo]

In a single threaded application you may have problem in handling the user interface depending on how the process is structured.

How are you handling the acquisition process? Are you continuously polling the devices in a loop with ProcessSystemEvents () inside? Are you using a timer? If so, which is the timer interval?

How long lasts the communication with the device (from request to answer)?

Supposing you are using a timer, using asyncronous timers can be a simple way to switch to a multithreaded process with only a few caveats. There are some documents on multithreading we can point you to if you decide to go this way.