CITECT Questions

[mrtweaver]

Well it still does not answer my question directly. A previous post says that you need to go in and organize the tags yourself for optimum efficiency. So with that bit of information lets say you have 42 tags per IO device. In the DBF file as well as if you look at the tag listing within the CITECT software the first 42 records are for the first IO device, however they are not in sequential order. Now in my IO device, Horner PLC, they are in sequential order. So with all that has been said here, does the tag layout in the DBF, which the CITECT product uses for your tags, have to be in sequential layout as well for optimum efficiency?

Ex: In the PLC I have the information that I want to gather and setup in registers 362 thru 450. However in my DBF file for CITECT it jumps around, records 1 - 6 = R362 thru R372, then records 7 - 9 = R406, R413, and R423, from this point the rest of the records jump around are are not in consecutive order. But they are all still in the same grouping. Like I said records 1 - 42 are for machine center1, records 43 - 84 are for machine center 2, and so on. But if I get better efficiency by putting the records in sequential format then I will do that.

Just out of curiousity, do all SCADA software packages require that you put the tags in sequential format within the server portion?

Does this rule also hold true if you are using an OPC server such as KepServer?

Finally some people on this forum swear off of using an OPC server they prefer a direct connect from the SCADA software they are using to the device. What is gained by going directly to the device from the software?

Ie: In the line of say CITECT. They have a modbus driver which communicates nicely with my horner devices. However the system can also be setup with using a product such as KepServer. So what are the benefits downfalls of each method?

KnowledgeBase Article Q3414:

The Citect I/O Server (and compiler) will set up request blocks to optimise data requests and thus improve performance. Blocking is basically set-up on address and type but with OPC we are not using addresses but record numbers. Therefore, remembering that blocks are created using individual types, tags should be set-up per I/O device, per type in the variable tags database.

This means you have to manually sort the database.

 

[John Gaunt]

I suggest you forget about optimun efficiency for Citect and
organise your tags to suit yourself.
I do a lot of PID control and for each PID loop I have about
26 Citect tags. With up to about 60 PID loops in each PLC and
up to six PLC's networked to Citect I find it most convenient to
put all the tags for each PID together despite the fact that they
are a mixture of REALs, INTEGERs and BOOLs. Citect of course
recommend otherwise but I have been doing this for many installations and never found any problem.
If Citect have a driver you can use rather than OPC then that
would be my preference.

 

[PhilipW]

Yes.

I've observed that most Citect users don't like OPC... and guess why? It's because the Citect implementation of it is so miserable. By contrast a huge list of automation companies and major HMI vendors such as Rockwell, Wonderware, ABB and use OPC with excellent results.

[font=Verdana, Arial, Helvetica, sans-serif]The OPC Foundation is dedicated to ensuring interoperability in automation by creating and maintaining open specifications that standardize the communication of acquired process data, alarm and event records, historical data, and batch data to multi-vendor enterprise systems and between production devices. Production devices include sensors, instruments, PLCs, RTUs, DCSs, HMIs, historians, trending subsystems, alarm subsystems, and more as used in the process industry, manufacturing, and in acquiring and transporting oil, gas, and minerals.[/font]

http://www.opcfoundation.org/Default.aspx/01_about/01_history.asp?MID=AboutOPC

OPC is also being developed well beyond simple data access:

http://en.wikipedia.org/wiki/OPC_Foundation

If you buy a printer for your PC and you want the latest version of it...you go not to Microsoft, but to HP, Epson, Canon... to whoever made the printer. The manufacturer of the hardware is the best single point to develop, optimise and maintain the driver interface to their own product.

The same reasoning lies behind the OPC concept. RSLinx is optimised to talk to Rockwell CLX processors to a degree Citect can never match, nor do the comparable Citect drivers come anywhere near RSLinx for features, easy of use and diagnostics. Moreover I'm almost certainly to be using RSLinx anyhow to connect RSLogix5000 so it makes no sense to be hammering my CLX processors with several non-optimised ABCLX drivers and however many RSLinx/Logix engineering terminals that happen to be online at the time.

Instead I just create ONE RSLinx connection (maybe a second if I need redundancy)...create an OPC topic for the Citect IO Servers, and then turn on RSLinx Gateway and connect all my engineering terminals as remote Clients. Far more efficient.

By contrast Citect make their OPC client almost unusable and it is not surprising that most users get turned off it.

 

[mrtweaver]

I have a feeling I know what you are speaking about in this post. You mention about OPC and citect implementation. I think this is the problem I first ran into. And when citect did a remote login to my pc and tried to get the OPC to work it still would not. So I think you are right in this about being miserable and not well done.

As for the drivers for my PLC they are actually contracted out by Horner to KepWare. Or at least that is what I have been told. The problem is their driver is somewhat buggy, which is why it is recommended that people use the modbus.

Thanks for the info. ANd have a great day.

Yes.

I've observed that most Citect users don't like OPC... and guess why? It's because the Citect implementation of it is so miserable. By contrast a huge list of automation companies and major HMI vendors such as Rockwell, Wonderware, ABB and use OPC with excellent results.



http://www.opcfoundation.org/Default.aspx/01_about/01_history.asp?MID=AboutOPC

OPC is also being developed well beyond simple data access:

http://en.wikipedia.org/wiki/OPC_Foundation

If you buy a printer for your PC and you want the latest version of it...you go not to Microsoft, but to HP, Epson, Canon... to whoever made the printer. The manufacturer of the hardware is the best single point to develop, optimise and maintain the driver interface to their own product.

The same reasoning lies behind the OPC concept. RSLinx is optimised to talk to Rockwell CLX processors to a degree Citect can never match, nor do the comparable Citect drivers come anywhere near RSLinx for features, easy of use and diagnostics. Moreover I'm almost certainly to be using RSLinx anyhow to connect RSLogix5000 so it makes no sense to be hammering my CLX processors with several non-optimised ABCLX drivers and however many RSLinx/Logix engineering terminals that happen to be online at the time.

Instead I just create ONE RSLinx connection (maybe a second if I need redundancy)...create an OPC topic for the Citect IO Servers, and then turn on RSLinx Gateway and connect all my engineering terminals as remote Clients. Far more efficient.

By contrast Citect make their OPC client almost unusable and it is not surprising that most users get turned off it.

 

[AJMUL]

citect is one of the worst scada

citect

 

[mrtweaver]

If you dont mind my asking, why do you say it is one of the worst? And if that is the case what would you say is/are the best? Please rank them in the order you think and state why if its not to much trouble. This way I can present all the information at our next inhouse meeting.

citect

 

[AJMUL]

citect issues

1.Compare with another it is not user friendly

2.It doesnot have more features.

3.It doesnot have any technical support and information

4.lot of bugs

ex: I have a Menu Page,As Per my customer Requirement the screen
bottom side i have to design a alarm viewer.For this I cannt able to do it.

Ajmul Khan

 

[BobB]

1.Compare with another it is not user friendly

I do not agree. All SCADA packages have good and bad things - I guess OPC is really one of Citect's weaknesses.

3.It doesnot have any technical support and information

Technical support is excellent in Ozz. Better than IFix for example. Like extracting teeth trying to get help there.

4.lot of bugs

Have not had a problem with an old V5.41 application I converted to V6.1 except I had to fix a few graphics. Runs very well.

bottom side i have to design a alarm viewer.For this I cannt able to do it.

The little red toggle is a direct link to the alarm page and no programming required.

 

[mrtweaver]

I am not sure why one would say OPC is a weakness. From what I can gather, and please correct me if I am wrong, there are two distinct ways to communicate with a PLC from a SCADA software package. Way number one, use a program written by a company, such as KepWare, this of course does the OPC way from my understanding. Then use this to connect to your SCADA software. Way number two, write your own code, most likely in VB or C, and push and pull the information from the PLC to the SCADA software. While both ways can basicaly be called drivers what are the advantages and disadvantages in doing this?

As for the Tech Support issue, while we have not yet purchased a software package, it looks as of right now that CITECT is a winner hands down. Mainly because of the pre-sales support they offer. I have not had any trouble getting assistance from them. So in the respect I have no complaints. But as mentioned I have tried other software packages and do agree with some of the flaming threads in this forum about the support on other products.

The one thing that I dont exactly like right now with CITECT is the Server issue. In a few of the packages of software that I tested some of them right out of the box had the ability to have two servers with no extra fee. Where the information I get from Citect is you want two server you purchase two licenses, so this doubles your initial cost. They should realize that PC's are not fool proof and they do sometimes crash so to build in this kind of backup server would be a definate sales advantage in my book. The other issue that I dont necessiarily like is the way in which you input tags if you are using citects own drivers. But like they say take the good with the bad.

There is one thing that I have to agree with AJMULE, sorry if I got the spelling wrong I forgot to write down your name on here. Anyway I must be missing the same thing this person is, because I can see this red toggle that BobB is talking about, I can click on it and it does go to the alarm page, however it will not let me clear or ack the alarm. So I think this is what is being talked about. Not sure.

I do not agree. All SCADA packages have good and bad things - I guess OPC is really one of Citect's weaknesses.



Technical support is excellent in Ozz. Better than IFix for example. Like extracting teeth trying to get help there.



Have not had a problem with an old V5.41 application I converted to V6.1 except I had to fix a few graphics. Runs very well.



The little red toggle is a direct link to the alarm page and no programming required.

 

[BobB]

There is an "acknowledge all" button that can be placed on the page. I think it is in the example project and/or on the side of the alarm page. To reset alarms just allocate a reset bit in the PLC to a button - very easy. I have one jobe with 9 PLCs where a reset button was allocated to each individual PLC. Just used a bit of cicode to "sleep 2" to keep the bit on for 2 seconds and away it went. Probably did not even have to use sleep.

The weakness with OPC was agreeing with Philip. It does not really bother me as I have taken a decision to not use OPC as it is way too slow, apart from other problems I have had with drivers. I use a proprietary PLC network that is very fast as most of the time I am trending frequency of generators every 100 or 200ms. I have not found an OPC server that can handle that rate of reads.

 

[P.d.L.]

1.Compare with another it is not user friendly

Please... if you want to get the most out of something by putting the least effort in, buy any low end SCADA. If you want something fully customisable and 100% reliable, get Citect and put in the effort.

I agree the price is a big drawback against other software.

2.It doesnot have more features.

More important, it does not have less

3.It doesnot have any technical support and information

Perhaps not locally, but I have found the best support to be right here, or on MrPLC.

4.lot of bugs

Although I have not encountered some if any, more important is that when the Explorer, Project Editor or Graphics Builder crash for any reason, the project files are never affected and you can always re-compile to runtime. Perhaps unsaved changes are lost but I have never had any corrupt files where other SCADA software can give headaches on this part.

By the way, unless you value the true colour support greatly, my sales rep has advised me to stick to 5.5, which is the most stable version so far. He said the shortcomings of V6 are not worth the true colour support yet. Any ideas on this ?

There is one thing that I have to agree with AJMULE, sorry if I got the spelling wrong I forgot to write down your name on here. Anyway I must be missing the same thing this person is, because I can see this red toggle that BobB is talking about, I can click on it and it does go to the alarm page, however it will not let me clear or ack the alarm. So I think this is what is being talked about. Not sure.

I am guessing this is because you are not logged in on a user privilige that is allowed to do this. Add a new user with privilige 8 at the project editor > systems > user dialog, recompile and run. Good chance you can now.

About your comment on the double server costs, it isn't that uncommon to pay 2 licences when you get 2 fully functional stand alone I/O servers ? I agree the initial costs are high but the fact they are accounted for single server use is normal IMHO.

By the way you should see how it works when you put both servers which have their own line to your I/O network on a separate ethernet link and use the primary/standby server principle. When both servers are online with their I/O devices (they check eachother), one acts as a client to the other server to reduce the load on your I/O devices. You define them as primary and standby server, so if the server looses comms to the I/O devices, the client becomes server and connects to the I/O devices, and the other server becomes client. In both cases you keep both stations.
If both I/O comms are fine and they are running Server/Client, pull the patch cable out of the switch and the client immediately switches to server mode. Have never seen any SCADA software that handles this so good. It definitely needs time to configure and set it up correclty (Have had some help from Citect myself on this) but once it runs it is excellent.

There is an "acknowledge all" button that can be placed on the page. I think it is in the example project and/or on the side of the alarm page. To reset alarms just allocate a reset bit in the PLC to a button - very easy. I have one jobe with 9 PLCs where a reset button was allocated to each individual PLC. Just used a bit of cicode to "sleep 2" to keep the bit on for 2 seconds and away it went. Probably did not even have to use sleep.

Using alarm categories it makes it very easy to display, acknowledge and clear alarms in a single, multiple or all categories at the same time.
You can use all kinds of handles to create animations on alarm category buttons and lamps.

As an example here's a snapshot of an alarm page with 24 categories.
Every buttons calls the AlarmSetInfo[] function to display the category, and I change the text colour to indicate a present alarm and display an animated exclamation mark to indicate an unacknowledged alarm within a category both with the AlarmFirstCatRec[] function.

I wanted a customised alarm view, and I admit I have put some hours or even days work in but in the end it works great and is easily adjusted.

You can learn a lot from the example project.

The reset button also calls a Cicode function, that uses the AlarmGetInfo fucntion to determine the particular category that is displayed and the corresponding alarm bit is pulsed.
If te category is 0 I pulse all alarm reset bits.
Same goes for the acknowledge and clear buttons.

By the way Bob, the Pulse[] function is great for single bit pulses with Controller link. No need to use the sleep function which can be dangerous for memory leaks (so I have been told)