RSview SE ,no commands will run from startup,macros or cmd prompt

Hi all.

Having some problems with a RSview SE server we have which has 5 clients on it. Whilst im waiting for support to get back to me i thought i might post on here...

When Rsview server starts we are running a macro which starts the datalogging, the derived tags and the alarm server.
Well this has stopped working as well as the stop/start components for that area.

Nothing in the startup box for the hmi server has any effect.

I also cannot run any commands from the cmd prompt,I can enter commands but it does nothing in the diagnostics window down the bottom.

No changes have been made to this recently and the system has been running smoothly for the last month with no alterations.

Its just died

any ideas anyone??? Ive tried running scripts from the clients as well, still no results....

should also mention the clients are "hanging" at the datalog reader client quite often, im assuming this is because the datalogs are not being started

It sounds like for some reason, FactoryTalk has stopped "seeing" that server. Have there been any recent changes to the PC running the server? For example, has the PC been swapped? Is your control network segregated from the corporate ethernet? If not, it's possible an automatic update pushed by the IT department may have gummed up the works.

Sometimes, a tiny mistake such as a typo in the server name could cause this to happen?

Also, what version of RSView SE are you running?

I've run into a similar problem in RSView32. Not sure if it applies in SE. Support had me go into the project folder and delete the 'cache' folder. They also had me delete the *.DNS and *.DLG files from each of my datalog folders in the DLGLOG folder. Then restart the project. It takes quite awhile for RSView to re-create these folders but it did correct the problem.

They suggested one of these was corrupt. We could also go into the activity log and see where the startup macro had hung-up.

Hope this helps.

Just a warning:
On SE, the 'cache' folder is actually Internet Explorer's 'Temporary Files' folder. If you do decide to clear this folder out, make sure that the SE client is completely shut down, and if you are clearing it on the server, make sure the entire SE server and all Rockwell applications are shut down. You might even have to disable services on the server, and reboot before clearing out the Temp internet files cache (using control panel).

cntrlfrk said:

I've run into a similar problem in RSView32. Not sure if it applies in SE. Support had me go into the project folder and delete the 'cache' folder. They also had me delete the *.DNS and *.DLG files from each of my datalog folders in the DLGLOG folder. Then restart the project. It takes quite awhile for RSView to re-create these folders but it did correct the problem.

They suggested one of these was corrupt. We could also go into the activity log and see where the startup macro had hung-up.

Hope this helps.

Click to expand...

hi guys thanks for your replies

I tend to agree with rgurin about it not seeing the factory talk...
very minor changed to a few screens, but none in the day or some before it died (in the middle of the night)

yes its on its own ethernet with a managed switch.

will check out the cache clearing thing.....

its vers 4, CPR 6

Please double-check version number

its vers 4, CPR 6

Click to expand...

Andrew:

Thank you for checking on the version number for us. As you know, the changes between releases can make a difference as to how the system operates.

However, I'm slightly confused by this response:

Version 3.2 is the release classified as CPR6
Version 4.0 is the release classified as CPR7

Please clarify.

Thank you very much,
Rick

Have you installed the latest patches listed at:
http://domino.automation.rockwell.c...C455453EFBD1CAE4C125703E005E02E0?OpenDocument

http://domino.automation.rockwell.c...E0A841F680B27C8EC125703E005E482B?OpenDocument

http://domino.automation.rockwell.c...461C2B10D783C198C125703E005E38B2?OpenDocument

I was having stability issues with a one server, 10 client system here (4.0). Installing the above patches seems to have cured it.

okey dokey, brain in gear, its vers 3.2 cpr6. dont ask me why on earth i wrote v4?????????