Is it possible to upload the current (installed in the controllers' memory) application software from a number of distributed AC800M controllers and view it on a PC?

And if 'yes', then how is it done?

Thanks and regards,

Phineas.

 

The simple answer is no.

-------------------------------------------------------
Torulf Wiberg Tel. +46 (0)40 59 50 50
Deterministic Control AB Fax +46 (0)703 83 08 08
Derbyvägen 6E Dir. +46 (0)40 59 50 56
SE-212 35 Malmö
SWEDEN

 

Thanks for your reply Torulf.

I'm trying to find out how many alarms are configured in the 800xA system and get the 'live' data.

Is it possible to do this via 'OPC server for AC800M'?

Regards,

Phineas.

 

Phineas,

To me it sounds strange that you have an 800xA system but not the source for a connected controller. Is it connected via AC800M Connect (integrated), PLC Connect (stand alone PLC mode) or Generic OPC Connect (would be strange)?

The number of configured alarms is not readily available as a number. Alarming in an AC800M is normally handled in the controller with all state information residing there. Alarms and other events are generated via functions and it is quite common to re-use the alarm function with varying alarm information in more complex functions, something that is heavily done in the standard libraries supplied by ABB. Finally the alarms and events are made available via OPC AE using the OPC server you mention.

What do you mean by "get the 'live' data"?

Regards

/T

-------------------------------------------------------
Torulf Wiberg Tel. +46 (0)40 59 50 50
Deterministic Control AB Fax +46 (0)703 83 08 08
Derbyvägen 6E Dir. +46 (0)40 59 50 56
SE-212 35 Malmö
SWEDEN

 

Torulf,

Thanks again for your reply. I'm learning the AC800/800xa as I go. I'm more used to dealing with Allen Bradley controllers where, via RS Logix or Rockwell 6200, a PC can upload the currently configured logic held in the controller's memory. As long as one has the appropriate comments and symbols files, it is possible to study the 'live' application either online or offline. That's what I refer to as live - what's actually configured in the PLC RAM.

It seems that downloading to a network of AC800's, the download software distributes the application program throughout the various controllers in the 800xa network. Is it this process of distribution that makes it impossible to connect to the network and 'upload' the current application?

If so, this implies that the only 'master' copy of the application is held elsewhere - on a PC for example - and downloaded to the network as required.

I understand that ABB use function blocks to manipulate data. My limited understanding is that each function block can have various alarms configured within it - High, Low, Bad PV, Fault, etc.

My aim is to carry out an alarm rationalisation exercise which requires me to count the number of configured alarms.

If it is not possible to upload from the network, is it possible to count the alarms offline by studying the function blocks?

I'm led to believe that the controllers are connected via AC800M connect...

Regards,
Phineas.

 

"It seems that downloading to a network of AC800's, the download software distributes the application program throughout the various controllers in the 800xa network"

--The control logic (along with libraries, graphics, etc.) resides on your Aspect Servers. The compiled applications (could be more than one per controller) are downloaded to the 800M controllers.

"If so, this implies that the only 'master' copy of the application is held elsewhere"

--Yes, on the Aspect Servers. On clients, the server based engineering applications (control modules, control builder applications, function diagrams if used, etc.) are "reserved" for editing. This is a typical client-server based scenario.

"I understand that ABB use function blocks to manipulate data. My limited understanding is that each function block can have various alarms configured within it - High, Low, Bad PV, Fault, etc."

--A few simple statements per my understanding:

1. From within a controller, only properties of objects are able to generate alarms.

2. Simple function blocks (and/or gates etc.) are not objects and thus can't generate alarms. Therefore "each function block" can't "have various alarms".

3. Not all objects will necessarily have an alarm, but each object can have one or more. You need to know the capability of each object type.

4. The ABB provided engineering tool to extract properties of object types (and can be used to extract the information needed for alarm rationalization (object name, description, analog range, units, alarm setpoint(s), alarm priority(ies))) is a Microsoft Excel plug-in called Bulk Data Manager (BDM).

With that in mind here is how I would proceed:

1. Find all object types used on your project that could possibly generate an alarm. Keep in mind that there are default libraries, but in addition you might also have ABB regional or industry specific libraries, libraries created by a third party engineering organization, and/or libraries created by your own company. Within control builder, library folder, you can open the libraries and run a "type usage" for each type of object. A tool might exist that would report which ones are actually used on a particular project but I'm not aware of one at this time. A reverse engineering approach would be to access the alarm list and go to the object structure aspect (via right click) to find out what the objects are. Chances are that you will discover your top 2 to 5 alarm generating objects rather quickly.

2. For each object type that you have that can generate an alarm, study how each alarm works and document what the property names are. For basic ABB function blocks and objects, when selected, clicking on the F1 keyboard key will often call up the correct page of the help document that describes how it works. For any other libraries (regional, industry, 3rd party, etc.) the available documentation depends on how thorough the people were that generated the code. If you have no help document, then you open the control module editor and study the code. Most ABB generated code that I have seen is pretty well documented and you should be able to figure out how the alarm logic works.

3. Once you know the objects and pertinent properties, import the data for each object type into Excel using BDM.

4. At that point you will know how many potential alarms you have.

Of course, for each analog based alarm, if the setpoint is outside of the operating range, and/or if some or all of the alarms for an object are disabled, and/or if the severity/priority are outside of the range used to generate an "operator alarm" and/or if the alarm list filters out the AEClass and/or area then those particular alarms will not appear to the operator and technically should not be counted. The point is that there is a whole host of ways to prevent alarms from getting to a particular alarm list. You need to understand if any of this applies to your project. Remember that the 800xA can be installed with a single client or with 50 clients, or with Multi-System Integration can access multiple large plants across the globe. Try to do alarm rationalization at that level!

Up to this point we have discussed process alarms generated by ABB controllers. There are other potential sources of alarms, of which I'll list two:

1. System alarms (hardware, services, networking)

2. Alarm expressions (we use these to generate alarms from third party PLC's connected to the system via OPC).

Do you have these, and do they need to be included in your rationalization efforts?

One final thought would be to consider discussing alarm rationalization with some folks that have already done so on the 800xA system. Matrikon, PAS, and even ABB come to mind. I know that at least one of those has an "enforcement" option that will routinely (i.e. daily) monitor all of the DCS alarm rationalization settings, and if changed, will force the DCS values back to the accepted values. This of course is optional.

"is it possible to count the alarms offline by studying the function blocks"

--All of the aforementioned work (studying/searching objects, extracting data with BDM, etc.) can be done off line.

I would also add that based on your questions, you absolutely need training or help from someone that has done something like this. I'm not selling any service here, just trying to help. If you have a manager that is just adding this to your workload so that he or she is covered, I wish you the best and feel your pain. If nothing else, contact ABB and ask for some on-site "coaching" services. Create a list of questions that begin with "how do I..." and get a quote from ABB on how long it will take to answer those questions. Hopefully the right person will show up and show you how to do those things on your own system. That is much better than a formal class that by its very nature will cover some things that you already know and some things that you will not need.

 

John,

Thank you for your comprehensive and highly informative answer.

Luckily, I have enlisted some extra help with the rationalization.

The first step - finding out the number of alarms - has had me stuck for about 4 months. Initially, ABB said it couldn't be done! Then I dug out some sales guff which suggested otherwise and now ABB say that it's a very complicated process and will take 3 weeks work... Oh, and they also claim it has to be done on site while connected to the 800xa via an engineering workstation. Hmmmm.

Regards,
Phineas

 

'they also claim it has to be done on site while connected to the 800xa via an engineering workstation'

--when I said it can be done "offline" I meant to say that you did not have to take any processes offline, download to any controllers, or gone online with control builder. However, as ABB says you do need to be connected to your system, such as via an engineering work station.

In order for this to be done while not connected to your production system (truly offline), you would need a separate engineering system and restore the AFW backup from your production system. If you have a spare server available and set it up for virtual servers (VMWare), you can create a truly offline engineering system that gives you more freedom to play and not worry about affecting your production system. A system like this obviously does not need redundancy. In an unlicensed configuration you will be annoyed with a license message. As an option, ABB claims to have reduced licensing cost structure for engineering systems, so that is something you might want to talk to them about. You can go further and procure some virtual controllers, do some modeling, and have a more robust system with which you can do some testing of modifications before deploying on your production system.

 

Thank you again.

Regards,
Phineas.

 

I'm not sure why ABB have told you this will take 3 weeks and a bunch of effort.

There is a System Diagnostic function block for the AC800M controller that will tell you the number of Created Alarms, Condition Names, System Alarms, etc etc. (as well as CPU load, memory usage etc)

The SystemDiagnostic function block is created by default when you start a new application program, so hopefully it already exists in your system. If not it is easy to create a new one.

Put one SystemDiagnostic function block in a task in each controller. You can either use the 800xA faceplate or the AC800M online interaction window to see a bunch of controller information. See the Control Builder Online help for more information.

I think this should provide you with what you are looking for. Let me know if not.

Rob
www[.]lymac.co.nz

 

Rob,

I could not find a system diagnostic aspect on any of my systems. I went to add an aspect and could not find any with this or a similar name. A help search came up with plenty of diagnostic references, but not the system diagnostic.

You mentioned a "function block" but I assume you are talking aspects.

Please clarify.
Thanks, John

 

Its a Function block which goes into the controller application software. Hence its an Object not an aspect. By default it is created in "Application1.Program_3" whenever you create a new project.

On your site it may have been moved or deleted. (If so, kick the application programmer who did this). If it is missing, you can add a new Function Block to an existing program or preferably a new small program. The function block gives detailed information about what is running in the AC800M controller, including the number of configured alarm blocks. You need one SystemDiagnostic function block in each physical controller in your system.

You can create a new temporary project in your system to see what the code looks like, then copy the code into your existing applications before deleting the temporary project again.

Rob
www[.]lymac.co.nz

 

I would be careful because ABB is famous to tell you it will take a long time and almost always has to be done on site minimum about 1 week. Often times it is a matter of hours.

IF they are mentioning an engineering workstation, then it is something you should be able to do yourself...it is a matter of knowing how to do it.

 

Rob,

Objects found, thanks.

There appear to be quite a few potentially helpful (for troubleshooting) control connections. Do you have any "best practices" information regarding which of these variables, if any, should be saved to a historian? Or are the basic system alarms and log files sufficient?

As far as to how this applies to the main thread topic started by Phineas (alarm rationalization), it appears that the alarm related control properties of the systemdiagnostic object are simply "number of created alarms" on a per application basis. I would imagine that this might be resettable, and would almost certainly reset on a controller cold restart.

While good information to have, it will not provide any real benefit to the alarm rationalization process, in my opinion. If nothing else, a process alarm generated within any application can be filtered out of the operator alarm list via a number of ways (class filter, area filter, severity/priority, alarm hiding, and coming soon in v5.1 - alarm shelving). Alarm rationalization needs to know the effect of these post controller processes. Since these post processes are done at the server level, the raw alarm count coming out of an application will be misleading at best.

However, there is still some pretty cool stuff that can help in other situations, so again, my thanks for bringing this object to our attention.

John

 

I am sorry but it is not possible if you don't have the exact program on your pc. but if you have you can activate the difference report somewhere on the software and you can see the differences between your program and the program that is running on AC800M. then make the modifications and try to be online again.

another way is if AC800m has a a cf card on it, I think you can get the program from it with a reader to your pc and do the same things I have told you. be careful not to download the program with differences.

 

Up to System Baseline 2, all the Controller source code resides on the control builder PC. If you loose the source code then that's it. There is NO WAY BACK !

In SV4.0 onwards the data that creates the difference report resides in the 800xA Aspect system. You cannot "loose" the source code unless the Aspect System is corrupted. If the source code is deleted you will also loose the HMI connected to the source code.

In order to get a difference report, you have to first download the program with the Difference Report option enabled, and then download it again after you have made any changes. The difference report cannot function unless it has data from the previous download. The difference report will not save you if you have lost the source code.

The CF Card contains the same compiled code that is executing in the AC800M controller. You cannot back-translate source from the CF card.

Moral : DONT LOOSE THE SOURCE CODE ! Back up your systems. Follow good security procedures. Don't let outside contractors wander onto your site and delete your property.

Rob
www[.]lymacco.nz