Bob,
I've been using Citect intensively for about 3 months now, and I have to say that I think it's OPC implementation really sucks. Because it's code base is very dated, it cannot properly handle OPC style string names in the graphic animations so it has to cross-correlate the OPC string tag names to an intermediate "OID" value that is generated in the variable tag database.
This works ok as long as you have just a single project, but introduce multiple servers, multilple clients and clustering, then it becomes a total nightmare to keep all the OID's lined up across the whole system. Simply doing an "OID Reset" does not always fix the problem; in the end Citect Support had us manually delete ALL the OID's in ALL of our projects, re-pack and recompile them all.
The problem is not just confined to the servers. The Citect Server/Client architecture is totally weird. The clients are really very THICK clients, that run a complete copy of the tag database, graphics and cicode files. As a result you cannot just do a change at the server level and expect that the clients will reflect the changes...oh no you have to propagate all the changes to the client as well.
Worse still you only have to get one processor address mis-spelt and a raft of other OPC tags nearby all fail as well resulting in #COM's all over the page, resulting in no obvious clue as to which tag is the cause of the problem. Nor is there ANY attempt to support OPC Tag Browsing that is such an excellent feature of OPC2.0. In discussion with Citect it appears that their very dated code base simply cannot support OPC properly and they have admitted that they really have no plans to fix these issues in future.
Citect have relied on the concept of having a zillion "free drivers" as a marketing edge that OPC has rendered obsolete. If for example you buy a printer for your PC, when you print from any application the "printer driver" that the OS uses was supplied by the company that built the printer hardware, NOT the company that supplied the application, or even the OS. It is the same with Automation, the company that provides the hardware, eg Rockwell, Seimens or Omron are the best people to write the driver, they know their hardware best, and can best keep their drivers up-to-date. This is why Citect have finished up with a mess of 8 different AB drivers, none of them anywhere as near as good as RSLinx.
Let me add in a few more grizzles:
No structured tag database, ie every tag, whether 10 or 100,000 are all in one single flat database. If you want to create tag structures (the HMI equivalent of UDT's) you are going to want to use an external database tool. Several third party tools exist but they don't bring much to the party, so Excel it is.
Ah but now if you want to edit the variable dbf's in Excel, you HAVE to save the file using the "Save-dbf" macro otherwise on saving you corrupt the columm widths. Or if instead you decide to use the "Export/Import Tags" tool, this will work better without the need for the special macro, BUT if you are using clustering and all your IODevices are defined in a single Include project....the Import tool drops all the new tags into the Include project where the IODevice is defined...NOT the project that you have open and want them to be in...so you are not much further ahead.
You cannot do something as simple as animate the colour or textof a PushButton, instead you have to superimpose another graphic object on top that peforms the animation desired and then group the two together. AHHHH...but NOW you cannot edit the components of the groups, instead you have to ungroup the object, (and loose any group animation in the process), select the element and edit that, then re-group, and tack back in any group animation. Major sucky. No copy and paste of animations between objects either.
Search and replace has ONLY just arrived in the last 6.1 Version....how the hell did anyone tolerate that basic ommission for the 15 years Citect has been around?
You can only pass a maximum of 8 variables to a pop-up (or super-genie) without resorting to a chunk of Cicode. And although the ability to pop bits of Cicode in almost everywhere is very powerful, the downside is that you find yourself HAVING to define Cicode functions to do things other HMI's do as standard.
The alarm system does not easily support remote acknowledges and handshakes, making a true global alarming system very hard to achieve. Sure Citect manages global alarming ok within its own architecture, but if you have OTHER HMI devices such as local pushbuttons, PanelView type terminals or even other remote Citect projects that have no network connectivity...then true global alarming is hard work to achieve. (At least I am working towards it, but the problem is still not cracked.)
The Citect GUI is an absolute refugee from the early 90's. This nonsense of having to constantly flick between the "Explorer Explorer", "Project Editor" and "Graphics Editor" and the "Cicode Editor" applications is absolutely naff. There is no reason whatsoever that Citect shouldn't be integrated as ONE single application with a single Explorer tree as are almost all modern applications.
If you are only creating a single HMI project with no Includes, no clients, no clusters and no complex networking, then Citect produces a nice compact and apparently robust code base that does not take much PC resource to run. The datalogging and trending is fairly snappy as well. Overall I can make Citect work, it is not too bad....but it is a whole generation behind RSView32 and WAY behind RSViewSE and the FactoryTalk concept. I am not here to rubbish Citect, unlike some people who knock a product without giving any reason to back their opinion. But head to head with the latest generations of HMI, Citect shows it's age.
