pvss_scripts.lst

[aorange]

Is there any advantage in running a control script by registering it in pvss_scripts.lst over running it in its own CTRL manager? what I am wondering here is if the control scripts executed in pvss_scripts.lst are loaded in separate threads sharing a common DP container or is it just to reduce the number of managers in the console.

Many thanks

Jonathan

[mkoller]

All scripts mentioned in pvss_scripts.lst are started inside the CTRL Manager in separate CTRL threads (which are not operating system threads, as usual). This is very similar to the way a panel starts many CTRL scripts e.g. all init scripts of different shapes inside the panel.
The advantage is the reduction of managers running in parallel, which means: less CTRL Managers results in faster startup time of the project (only 1 manager needs to be initialized) and this also means less memory consumption, as each CTRL manager has its own copy of the DP-Identification (the table doing the mapping between DP names and DP numbers, but also holding DP description texts and aliases), which - depending on your setup - can also mean all DP-Identifications from all connected distributed systems.

The disadvantage might be, that multiple scripts can not take advantage of a multi-CPU machine, as a CTRL Manager is, as every WinCC OA Manager, a single threaded application.

[aorange]

Thanks Martin, that confirms the results of our findings. Grouping smaller CTRL scripts together to reduce the number of managers seems like a sensible approach to improve start-up times and reduce memory consumption.

[mweber]

Martin explained already everything in detail, but nevertheless I want to add one thing, because the topic refers to the pvss_scripts.lst:

I want to mention that if you plan to let your different ctrl-scripts be worked inside one CTRL-manager (which is a nice thing to do) pleas do that by entering a new CTRL-manager and not add your scripts to the pvss_scripts.lst.
The explanation why you should use a separate manager is very simple - the pvss_scripts.lst contains vital control scripts like the calculate_state.ctl that determines the systems error state and will trigger the redundancy switch in a partly-failure condition.
If a script would lead to a fatal error (manager commits suicide) - or even worse - would drive the manager into a blocking state, none of the scripts is worked anymore and that might lead to bigger problems especially in safety relevant systems.

Therefore always remember dont touch the CTRL-manager with number one - for your own scripts use own managers (hence own_scripts.lst)!

[aorange]

This is a very fair point, I wasn't planning on running any scripts in the pvss_scripts.lst CTRL manager but some thought will need to be given to the unwanted behaviour of one of the scripts in a group locking up the manager. I assume here that a script/function started in a separate CTRL thread would not only lock up the thread but also the manager as they all run inside the same OS thread?

Is the execution of the CTRL threads inside a single manager time-sliced or are they executed sequentially?

[mweber]

Yes you are perfectly right - if a control manager that works many scripts gets locked up by one "bad" script, also all the other scripts will stop working immediatly.
Also the debugging could get a little more difficult, because in the logfile you will see that CTRL-manager number 3 has crashed, but maybe you will have no idea why (which script has coused the problem - or worse - if a manager is blocking you will not receive any messages in the log from this manager any more).

Afaik the execution of the different threads from a manager is done in a way that there is a maximum time after that the next thread is worked, except you would have a function like delay(), than immediatly the other threads are worked and this one with the delay is continued after the specified time is up.
This applies to multiple scripts running in the same CTRL-manager or also work functions from dpConnects as well as threads started by using startThread().

But martin could give you more detailed information if needed (or correct me if I am wrong).

There is one more advantage that you will have when dealing with big distributed systems.
You could decide (with a config entry) if a manager should receive all DPIDs also from all other systems to with a dist connection is established (thats the default),
or that a certain manager should only interact with the dps from its local system (or since 3.9 Version only from some distributed systems).
By doing so you could further decrease the amount of memory used by your CTRL-managers.
(just do one manager that works only scripts that interact with local DPs and another with all scripts that also needs the DPs from other systems)

example:
[ctrl_3]
distributed = 0 #manager will not receive dpid-table from any other system

or

[ctrl_3]
distSystemIds = "1-28, 46, 280-290, 320" #manager will only accept dpid-tables from the given systems

[mkoller]

I just need to mention that "locking up" should never, ever occur in a CTRL script.

All our functions, even the ones which wait for some asynchronous reply, e.g. a dpGet(), will not "block" the manager.
Such functions will just halt the execution of _this specific thread_ and wait for an answer to arrive.
All other scripts and their threads will continue to work as usual.