• Replies 15 replies
  • Subscribers 582 subscribers
  • Views 700 views
  • Users 0 members are here
Options
Related

What is the main goal of Multiprocess ?

Anton

When we select multiprocess we have any troubles (each process has personal local variables and etc)/ Which bonus we have when we select multiprocess ?

In other SCADA systems (for example WinCC, InTouch, RSView32, iFix, Proficy) we have not anything like multiprocess/single_process in Citect .....

  • Hi Anton,
    With modern computer hardware becoming more parallel processor capable, it was a logical step in the architecture of the product. It just makes sense to run each sub-system on its own process to make the most of available resources and give more capacity to each function.
    With regards to local variables each residing in their own process, this is by design. You can engineer or properly configure your SCADA system to work they way you need it to, e.g. via standard variable tags (can still be set to Memory - but truly distributed across the entire system).
    So short answer, to keep up with modern tech and unlock more capacity and performance.
    Please tell me which SCADA system on the market offers the performance and scalability with n-level device redundancy that Citect offers.

  • OK.

    So this processes are Windows processes .... not a process in Citect terminology ... but why we must care about the distribution of processes by the operating system ? When we run any program in Windows we do not care about so much processes ant threads the program will generate .... it is a task for operation system or the program's programmer ...

    If  "modern computer hardware becoming more parallel processor capable" why Citect don't run in multiprocess mode by default ?

    About local variables - usually   I used to local DIGITAL variables tag1, tag2, tag3 and alarms for it to test my personal alarm page and run Runtime in single process mode, but when we started run Runtime in multiprocess this alarms stopped worked .... Not so fast I knew that it was because of multi process mode ....

    About standard variable tags in Memory - we must give unique address (i100, d12 etc). Its requests to be carefully with  pairs tag-address . It is extra work. Plus local variable is unique on each Runtime client (for example one server and two clients) but with memory tags we will have one value for each client. Why Citect does not  automatically make an address for memory tag ?

    I have never used redundancy in Citect .... I used redundancy in WinCC only ....

  • >So this processes are Windows processes

    Yes, in multiprocess mode, each Citect runtime process will be a separate Windows process. In the Windows Task Manager you will see multiple copies of citect32.exe (or citect.exe) running. Compare the process ID (PID) in Task Manager with the process ID shown in the Citect Runtime Manager to tell which is which.


    >why we must care about the distribution of processes by the operating system ?
    >why Citect don't run in multiprocess mode by default ?
    >when we started run Runtime in multiprocess this alarms stopped worked

    I think you answered your own question. When you switch from single process to multiprocess you can break certain functionality in your project and have to manually change how it is designed to make it work again. Originally, Citect only had single-process mode. Then, multiprocess mode was added, but each process was locked to a single CPU. Now, each process runs on all available CPUs. Citect still needs to support older projects so you have to choose which mode you want. Tech Support strongly suggests using multiprocess mode since it makes troubleshooting easier, in addition to supporting online changes, improving performance, and allowing each process to access 4GB of memory. However, you have to be aware that local variables and Cicode variables are not shared between processes. Also, some Cicode functions (like alarm and server info functions) need to be run from the correct server process, and some will work differently depending on whether they're called from the client or server process--see the help for each function for details.


    >Why Citect does not automatically make an address for memory tag ?

    That would be nice. However, you can make it easier if you use OPC as the protocol for your memory devices. Then, Citect doesn't care what address you use for each tag. I just copy the tag name into the address field. You also avoid the GENERIC protocol's limits for the number of tags you can have for each data type. That's why OPC is now the default for any new disk/memory devices.

  • >> >Why Citect does not automatically make an address for memory tag ?

    I talked about GENERIC which can save tag values on a hard disk ....

    We use it to save setpoints behind computer  reboots. OPC in MEMORY isn't that we need.

    OPC in MEMORY is much more a lifehack than standard SCADA function ....

    Totaly we have zoo with tags: local variables (personal value on each client PC but some troubles with CiCode functions), GENERIC in memory (requests an address, one value for each client PC, don't save value after reboot), GENERIC on DISK (requests an address, one value for each client PC, save value after reboot), OPC in MEMORY (without address, one value for each client PC, don't save value after reboot) , tags in devices .....

  • When you have a disk or memory I/O device, it does not matter what protocol you use. The protocol just determines what address format you use for the tags you create. Using OPC does not mean you are communicating with an OPC server. Since you have the device configured for Memory mode, all it means when you use OPC is that Citect doesn't care what addresses you use. This is not a hack--it is the recommended method for creating disk/memory/persisted devices. The generic protocol was the recommended method many years ago, before OPC had been invented. It only exists for backwards compatibility with old projects.

    If you use disk mode or you enable persistence mode (which is the easier and more reliable way of having values saved to disk), then the memory values will be backed up to disk so Citect retains them when you restart the runtime. Still, it does not matter what protocol you used.
  • Yes, I know that option MEMORY for any protocol .... You started to talk for OPC as example and I continued .....
  • I often use the option MEMORY for my OPC device to debug my SCADA project without PLC
  • Hi Anton,

    Eric was just indicating that what is common for customers who want variables that are shared between all computers and processes, and not stored in a PLC, then we typically create a OFSOPC device, set it to Memory Mode and set it's Persist property to True. If you don't set the persist property then the value will be lost on shutdown. See "Using Memory Mode" and "Using Persisted I/O Memory Mode" in the help for more info.

    The "Local" Variable Tag in Citect is typically used for usecases where you want something stored just for that machine. E.g a user interface option in your project, so that different clients can have different settings.

    I hope that helps.

    Cheers,
    bradley

  • Currently we use the GENERIC protocol for tags which we want to save after reboot Citect

    Here people recommended me to use OPC protocol anв MEMORY = TRUE and PERSIST=TRUE - in this case we have two variants - which is better?

    The variant 1: PROTOCOL is OPC but Port Name is DISCDRV and ADDRESS is a binary file *.CDK

    The variant 2: PROTOCOL is OPC and PORT NAME is PORT3_BOARD1 and ADDRESS = "any string" and file is *.XML

  • Definitely go for option 2.

    Option 1 is the classic disk PLC mechanism, which is less reliable and only redundant up to 2 I/O servers.
    For the redundancy to work you need to share a folder on each I/O server and point the CDK files to both folders, which is unreliable.
    Also, a CDK file has a proprietary binary format which does not allow you to see the values of the tags in it.

    Option 2 is the "new" Persisant Memory mechanism, which uses standard Citect server-server communication channels and supports redundancy for all I/O servers in your system.
    The XML files are plain text files which can be useful to debug / inspect tag values.

    The reason why OPC (or OFSOPC) is suggested for the protocol is that you don't need to specify Variable Tag addresses like you would with the GENERIC protocol (D1, I1, S1, etc.).
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.