Could someone explain RSView SE server / client relationship

Could someone explain the server / client relationship in a way that an ordinary sparky could understand.

We have 5 versa views on the production line, running rsview se, but the actual rsview se project is running on the server ( have i understood this correctly ), so when the engineers need to make any changes, they only have to edit the project that runs on the server, and the clients are updated automatically as well??

Not sure if i've explained myself properly, or if i've asked the right questions!!

thanks
Sparky

You've described it correctly.

The "application" itself (i.e., screens, tags, macros, etc) all reside and run on the server computer. The communication with the PLC runs on a server as well -- This IO server may or may not be the same as the application server. If the system is fairly large, it is highly recommended to separate those functions to separate servers.

These servers, then, server up the information to the client computers, which perform the functions that the operators see.

You've described exactly the beauty of the server/client type of architecture. When you need to make a system change, you make it in one place (the server), then it is automatically fed out to all of the clients. If you make a screen change to a screen that is currently being displayed, you'll only need to refresh the screen on the clients to make the new changes active.

Does that help??

HI Ozee, yes that explains it better, but you've now got me confused about the communications.


So you can have the comms application such as factory talk on a different server, and this will update the i/o tags that the rsview se application has in it's database, is this correct??

What are the benefits of this?

cheers
Sparky

RSViewSE is really setup with those two server functions.

The main benefit is primarily seen in a large application (1000s of tags or several clients). It distributes the "horsepower" required to run the system.

In a small system, it is perfectly acceptable to have both server functions performed by the same computer.


In the past when I've done it this way, I've set it up so each server is the redundant server for the other function. (I.e., the application server computer is the back-up server for the FactoryTalk/IO server and vice-versa.) That way if one of the computers fails, the other will pick up its function.