Citect 2018 R2 multi page graphics limit

G'day,

I think we've found a limit with the Citect client process.  We have a number of clients, 2 of which exhibit issues displaying faceplates and other slow response problems.  These issues only surfaced when we updated from 2018 update 13 to 2018 R2 update 10.  The two clients that are exhibiting this issue both have 4xHD monitors plus 2x4K monitors, running the SA environment and runtime only client processes.

We traced the issue back to the CPU core that runs the Citect32 process reaching 100% utilisation.  The processors are quad core (non hyperthreading) Xeon 2.9GHz units.  We are going to look at replacing them with Xeon quad core hyperthreading 4.5GHz equivalents.  We haven't observed any other hardware limitations

Some of the symptoms we seem to be experiencing are:

  • Faceplates slow to load
  • Faceplates don't load
  • Alarms stop displaying (though this may be a different issue as it appears to occur on lightly loaded clients)
  • Alarm filtering resets to unfiltered periodically

For the end users - has anyone else come across these issues?  Has upgrading processor to one with a higher clock speed helped?

For the developers - is there anything in the works to split the Citect client process into a single process per monitor such that we can utilise the additional cores that modern PCs come with?  Is there a supported method to enable Windows to split the Client process across multiple cores?

Cheers, Owen

Parents
  • Most of the time I have seen these types of performance issues reported there is another factor at play that shouldn't be ruled out. Performance issues are also caused by "Bad Tags" in the Citect SCADA configured application/project. "Bad Tags" are tags that have been removed in the PLC project or a name changed in the PLC project, however they were never removed or the name was not updated in the Citect project, and over time this continues to deteriorate the performance of the system. There are ways to identify "Bad Tags" depending on the protocol used, and once these are corrected in the project, performance improves significantly. Additionally, there are Driver communication settings that also help to optimize performance as mentioned on this forum to increase scan time and others that will help offload the high CPU, but Bad Tags need to be identified as a priority.
Reply
  • Most of the time I have seen these types of performance issues reported there is another factor at play that shouldn't be ruled out. Performance issues are also caused by "Bad Tags" in the Citect SCADA configured application/project. "Bad Tags" are tags that have been removed in the PLC project or a name changed in the PLC project, however they were never removed or the name was not updated in the Citect project, and over time this continues to deteriorate the performance of the system. There are ways to identify "Bad Tags" depending on the protocol used, and once these are corrected in the project, performance improves significantly. Additionally, there are Driver communication settings that also help to optimize performance as mentioned on this forum to increase scan time and others that will help offload the high CPU, but Bad Tags need to be identified as a priority.
Children
No Data