cpu usage at 100%

[bac81362]

I am running LabView 7.1 with DSC loaded. My project controls two reaction vessels through compact fieldpoint I/O modules. There are PID loops, data logging, trending and general value displays. The I/O is a mixture of analog and discrete. With trending enabled, my CPU usage jumps to 100%. This happens immediately, not slowly building over time. When this happens, the other portions of the program suffer, i.e. slower updates to PIDs and subsequently out-of-control loops, along with extremely slow updates to the screens. Disabling the trending results in the cpu usage dropping to around 3% and normal PID control and screen updates. The computer is plenty fast with enough RAM. Trending is vital to the technicians ability to manage the reaction. Has anyone seen this issue? I am using the read traces vi to populate the trends.

[altenbach]

I am not familiar with the "read traces.vi". Is that from a toolkit?

Things you should look out for is loops without waits, resizing of arrays inside loops (built array, insert into array, delete from array), and shufflung large amounts of data back and forth via value property nodes and locals.

Wo wrote the trending portion? What does it actually do?

Ideally, you would keep your data array in a shift regsiter of fixed size and do the trending "in place" as much as possible.

It is hard to troubleshood in more details without seeing the code. Can you attach at least parts of it?

[Ben]

I'll let Christian handle the LabVIEW related performance issues.

DSC comes with Trending and historical logging.

The history files should be archieved occationally to prevent the DSC tool from trying to take all of the reading "from the begining of time" into concideration when it operates.

The frequency of the archieve operations depends on many factors including the deadband setting for the tag in the Tag Configuration.

If I remember correctly (long time) the archieving can be done from MAX.

Ben

[bac81362]

Ben:

Would you say that archieving of data is necessary, even if I am specifing the time interval on the read traces vi and capping the max points per trend line?

[Ben]

Yes!

I have seen the historical trend viewer crash all of LV when just trying to open the trend.

But I should ask the "dumb question" first.

Since this is a DSC app and DSC apps generally run for long periods*, did you try rebooting the machine?

Ben

* One of my customers reported their machine was stating to run slow. I asked them when was the last time it was re-booted. They said "18 months ago."

[GuenterMueller]

Wow.
18 month passed by without the customer having any desire for an update?
Seems to be reliable and satisfying stuff
Have a great day, Guenter

[bac81362]

All:

Many thanks for the help to date. I have re-booted the computer and actually left it shutdown for 30 minutes. Archieving the data helped, as did introducing some wait for next millisecond logic in the for loops associated with trending. Still, I am not where I need to be in order to minimize the program slowness, related to trending; and properly run the PID loops. My CPU usage now runs between 20-60% and blips up to 100% occasionally, compared with a solid 100% before implementing your suggestions. My screen display and PID values update about every 3 seconds, compared with 10 seconds before implementing your suggestions. Attached is the program. The DSC trending is in frame 7. Please feel free to offer any advice. This is a legacy program, which I inherited about a year ago. My LabView skills are intermediate.

[altenbach]

Sorry, I cannot test because of missing subVIs, but I would NOT place waits inside these FOR loops! They run for a limited number if iterations and do nothing special except some property nodes. Since your code is heavily sequentialized (sic ;)) all you do with these waits is prevent the program from doing anything useful.

What might help would be do defer panel updates during the sequence of FOR loops containing property nodes. (see e.g. http://forums.ni.com/ni/board/message?board.id=170&message.id=164135#M164135)

You have a lot of duplicate code that could be consolidated. Overall, the code is very hard to navigate because of the deep stacks of sequence structures.

Message Edited by altenbach on 10-24-2007 07:08 AM

[parthabe]

I think this thread is going to be a great KB regarding LV code development.

Thanks in advance for all the teachers.

[bac81362]

I implemented the defer panel updates logic. It was a complete disaster. The system became locked down. I was unable to navigate between my front panel tabs. I guess because the trending is eating up the majority of the program time and cpu, with panel updates deferred it was unable to recognize my simple requests to navigate. As for the program being deeply nested, that is true, but I really don't know of a much different way to write sequential logic; and I suppose the original programmer didn't either.  Short of a total re-write, can you think of anything else to try? I do value the input you have given to this point. When I originally made the posting, I was hoping that I was up against a known bug with a work around.