RSView32 Project Starting Slow

I have RSView32 running on a Win2000 Server machine. When the project is started, it takes 35-40 minutes to completely start. When looking through the activity log, the majority of the time is spent starting data logs (3 minutes each). If I disable the macro that starts the datalogs, startup time is < 30 secs.

Any ideas?

I do not think there is anything you can do about this.

I a have a couple of applications that have lots of tags setup to datalog. They act the same way.

I think it is RSView/RSLinx getting those tags "on the scan". It takes some time for the system to establish a link with the tags in the PLC(s). This was explained to me by an RA engineer once. I can't remember the details?

If you lengthen the interval of datalogging it might help. It is also dependent on the type of plc it is talking to and it's communications load.

RSL

I may be wrong in this instance but in most cases with RSView32 you should get a faster server and add RAM. Lots of RAM.

You might also set the commands in your macro to run asynchronously.

For example if you entered the following in your macro:

Datalogon Model_1
Datalogon Model_2
Display My_Graphic

Then it must completely load Model 1 before it starts to load Model 2 which it must load completely before displaying the graphic.

Instead enter it as follows:
&Datalogon Model_1
&Datalogon Model_2
Display My_Graphic

This would tell RSView to start loading Model 1, then start loading Model 2, then load the graphic. So the graphic could be displayed before either model has completely loaded.

OG

How long has it been since last reboot, and defrag? If you are making alot of datalogs and alarms then it could cause defrag of hard drive.

Operaghost-Haven't thought of starting everything in parallel, that may help, but seems like it would be putting alot of traffic on the network at once. I have about 5500 tags, 26 PLC's, 16 datalogs.

nswu1-I'm not sure when the last defrag was to be honest.

I'll try both this A.M. and let you know what I find.

Thanks for the suggestions so far....

_________________________________________________________________

"Nothing in the world can take the place of persistence... Education will not; the world is full of educated derelicts."...Calvin Coolidge

I'd like to add my vote for a healthy amount of RAM... On an application that seems to be stressing your comp to the limits(30-45min???) just adding an extra 512MB of RAM will help out enormously.

And if it doesn't help, then you will know that the computer is most likely not your bottleneck.....

Defrag didn't help(but was long overdue).

I watched the memory in task manager/processes and SQLServer was running over 500Meg. I have a little over 1 Gig of RAM.

I called Rockwell, again (I know my case number by heart) and we were walking through a couple new experiments. We switched the datalog type from ODBC to 'narrow', started up in 45 secs.

Here's the odd part. We switched back to ODBC and it started in 45 secs. I started it 5 or 6 times and it was about 45 secs each time. Memory in Task Manager showed about 150 Meg.

However, when I came in this morning, it's showing about 450 Meg. again.

I had duplicated this once before when I re-created the project from scratch, and didn't realize that when I imported the datalogs, it didn't import the datalog setup. I thought the problem was fixed, but returned 3 days later.

I know SQLServer is a memory hog, but why does it work fine when I switch away from ODBC and then back without doing anything else?

I agree with the memory issue. It just seems I should be OK with over a gig.

__________________________________________________ _______________

"Nothing in the world can take the place of persistence... Education will not; the world is full of educated derelicts."...Calvin Coolidge

Still seeing problems with memory. SQLServer is currently using over 850Meg which seems to me to be far too much. The few times this project started normally SQLServer was only using about 150Meg.

Does anyone know what would cause this?

__________________________________________________ _______________

"Nothing in the world can take the place of persistence... Education will not; the world is full of educated derelicts."...Calvin Coolidge

cntrlfrk said:

Still seeing problems with memory. SQLServer is currently using over 850Meg which seems to me to be far too much. The few times this project started normally SQLServer was only using about 150Meg.

Does anyone know what would cause this?

Click to expand...

Just guessing, but SQL Server will buffer recent data insert/updates/deletes to help with query performance. Also, its default setup is to grab as much system RAM as possible. This behavior can be changed, but you will need to spend some time reading Books Online. Also, if you have the lateset service pack for SQL server (SP4, I think) you may want to also download the latest Books Online, since they changed some memory and other performance related functions.

Anyway, the short answer is that it is normal for SQL server to start out with a smaller memory footprint and slowly grow over time. This also can be effected by reports/querys. This data also is buffered to improve future queries for similar data. It is aged and then flushed from memory.

Darren

Oh, I also forgot. If you have queries that have WHERE clauses that are trying to match data that is un indexed then the database will perform a table scan and create an in memory index. Depending on the data set size this could cause major memory head aches with SQL server.

Darren

As a final update, we reloaded software, updated windows, updated SQL Server, still no luck. However, we found that for some reason, the data in our historical database (SQL) was not being deleted after the requested maximum time, we had 4 months more data than we should have. From looking in the Activity Log, this seemed to be where it was spending it's time, removing old data files on startup. We saved our data away and then deleted the SQL Database and created a new one. Has been starting up in 1-1/2 to 2 minutes. We'll see after data builds up, we normally store 50 days worth.


Thanks all for the input.