Today is...
Friday, April 19, 2019
The OPC Community Forum.
OPC interfacing for Infi90
Infi90 basics

I am trying to interface between a supervisory control system and a Bailey Infi90 DCS using OPC. The problem is I don't know the basics of Infi90, such as, what exactly are CIU04, NCIU04, ICI etc. Is there a resource I can use for this?

If some one can provide even basic explanation of the terms, that would be of great help.

Thanks

CIU04, ICI, etc. are the hardware modules you need to get access to the INFI-NET, which is the high speed communication highway INFI90 uses. Access is provided using either serial, SCSI or Ethernet connections depending on the model. CIU stands for "Computer Interface Module", so you will need then a computer where you run the OPC server that polls the data from the CIU. There are several vendors of OPC servers for the Bailey INFI90 system out there.

b.r.

Romulo Rodriguez
romrod at gmail

By Adriel Michaud on 4 February, 2009 - 2:57 pm

Like Romulo said, you'll need a PC interface card to get data from infi90.

You can connect using:
Harmony Network Coupler (HNCC)
INFI 90 / Network 90 - CIU04 / NCIU04
INFI 90 / Network 90 - HNCC
INFI 90 / Network 90 ICI01/INICT01
INFI 90 / Network 90 ICI03/INICT03
INFI 90 / Network 90 ICI13/INICT13INICT13A
using a direct OPC connection via this OPC Server for Bailey DCS: http://matrikonopc.com/opc-drivers/164/base-driver-details.aspx

More interface card options are available using the SemAPI OPC Server, but SemAPI is an additional cost.

Adriel Michaud
MatrikonOPC

In Bailey land, CIU means Computer Interface Unit. It is a generic term that applies to variety of models based on the type of Bailey system (Command Series, Network 90, Infi 90, Open Infi 90, Harmony, Symphony). All of the CIU models support RS232 communication at a maximum baud rate of 19,200. The protocol is proprietary, binary and sends data by exception so the amount of effective data that can be exchanged is very large. A few of the CIU interface models also support SCSI communication. Most interface names are made up of a couple of cards that each have their own names. Here is a list of CIU models and the cards they contain.

NSPM01
IMSPM01
IMCPM02
IMCPM03
NCIC01
NCIU01 - (SIM01 / PTM01 / LIM03)
NCIU02 - (LSM01 / BTM01 / LIM03)
NCIU03 - (LSM02 /BTM01 / LIM03)
NCIU04 - (SSM01 / LIS01)
INPCI01 - (SIM01 / PTM01 / LIM03)
INPCI02 - (PTC01 / LIM03)
IIMCP01 - (MCP01 / MLM01)
IIMCP02 - (MCP02 / MLM02)
INICI01 - (ICT01 / NIS01)
INICI12 - (ICT12 / NIS01)
INICI03 - (ICT03A / NIS01)
INICI13A - (ICT13A / NIS01)

There are a few vendors that sell OPC and DDE drivers that can interface with a subset of these CIU models. Some of those vendors also require purchase of the ABB Bailey semAPI software to interface with some of these CIU models. Our OPC and DDE driver can interface with all of these models and does not utilize the semAPI programming environment.

Hope this helps. Feel free to contact me if you have other questions - spafford@rovisys.com

By Wassim Daoud on 5 May, 2010 - 11:00 am

here is an OPC Server for Bailey Infi90:

http://www.matrikonopc.com/opc-drivers/opc-bailey/base-driver-details.aspx

Also, if you are interested in a cd rom of all INFI90 documentation, write me off forum at sales [at] workstationsexpress.com

Note it does not discuss OPC and was produced around 2000 or so, but it is very complete on the BAILEY product line.

If you have a Bailey Network 90 or Infi90 (both are just revisions of the same Bailey DCS), chances are it would already have one or more of the Computer Interfaces, the previous posters have mentioned. You haven't mentioned the type of HMI you are trying to connect it to, nor what it originally had in the way of operator consoles.

Depending on what type of HMI you have, you will not need to use OPC for it - you might be able to connect it directly to the Infinet (or if it's a very old system - Plant Loop) via a ciu.

My advice would be to steer clear of OPC when it comes to Bailey systems, I tried it at one site and it wasn't too reliable. The Bailey system uses a specific type of addressing that the console tag databases point to and reflects a 'virtual' replica of it in the point table of one of the CIU types mentioned.

The consoles work very well with this 'natural' partnership, whereas OPC servers do not. OPC is a general purpose interface and I feel that not enough R&D was done with regard to Network90 / Infi90 exception report connectivity. The OPC servers (Software Toolbox is one that I remember well) tended to fall over far too often, for no known reasons...

If you just connect directly, you eliminate all the weak links and need a lot less hardware too.

By Joel Spafford on 18 February, 2011 - 9:35 am

I agree with you that companies that do not have enough R&D experience with the Infi 90 / Network 90 tend to provide sub standard OPC servers for that system. Having a thorough understanding of these systems and the functionality of the CIU can result in an OPC server that is rock solid, easy to use and ultra reliable. We have been offer such a product for over 10 years now. This was made possible because I once worked at Bailey and was responsible for development of the CIU, a number of the controllers and communication modules. I felt it important to provide this feedback because our OPC server is being successfully used in a large number of applications from historical data collection systems, loop tuning applications, MMI / HMI applications and process optimization solutions. Readers of these posts need to understand that OPC usage for the Infi 90 / Network 90 systems can and is being successfully used. The right OPC server choice is important to that success.

Is anybody have a wiring diagram to convert DB-25 to DB-9 for connecting INICT01 to PC?
I want to use OPC Server to grab data from INICT01.

Best Regards

>I want to use OPC Server to grab data
>from INICT01.

Have you tried using MatrikonOPC's OPC Server for this connection:

http://www.matrikonopc.com/opc-drivers/opc-bailey/base-driver-details.aspx

Cheers,
Wassim

By Hilton Lawson on 19 February, 2013 - 4:59 pm

Is there any way to get raw (bypass the exception report) process data from the Bailey INFI90 controller? Specifically I want to do some process analysis work that requires polled data at a 1 second rate with no compression. how can I get this data?

Set all the XRs in your DCS to 1 second max report time. This is done in the Segment Control block in each MFP.

Other than that, no you cannot bypass the exception reports - that is how Infi 90 talks.

>Is there any way to get raw (bypass the
>exception report) process data from the
>Bailey INFI90 controller? Specifically
>I want to do some process analysis work
>that requires polled data at a 1 second
>rate with no compression. how can I get
>this data?

Did you ever find your solution to 1-second data from Infi-90.

This is a loaded question if there ever was one.

1. Vintage of equipment matters. Current controllers and communications have 10+ fold capability increases over the MFP family. Then some still run MFCs.

2. Networks matter. LIM/BIM or NIS/NPM. Plant loop or Infinet?

3. Size matters. How many exception reporting tags, and at what rates.

You just can't take 20,000 tags and get them all at 1 second intervals.

What specifically are you trying to accomplish?

If a value is not changing "significantly", why take up bandwidth in exception reporting it, which will slow down the opportunity for other tags with valid significant changes from getting around the loop in a second.

If you have a reasonable number of tags that you are interested in, here is what I would do:

1. Add another segment control FC82.

2. Run the segment at 100 ms.

3. Leave the minimum report time at 1 second, and leave the maximum at 60 seconds.

4. Set the significant change paramater for 0.1% (used for FC80)

Then put only the subset of exception reports you are interested in in that fast segment.

Also for these exception reports turn the exception reporting spec to near zero or zero.

It should be noted that what is recommended above could hurt the performance of the system and other tags, as well as the process. This was really done to discuss the steps involved.

Someone (or some team) with a knowledge of your process, and your control system should tread carefully, perhaps making changes in phases.

Before doing anything, assess the overall health of your system, and re-assess after every change. ABB provides a Harmony Fingerprint service that you should consider.

That gets fast data to your ICT. You also need to look at your OPC interface since that can be a funnel as well.

Thanks!

@ John

We are implementing a loop monitoring system that requires 1-2 second update on PV, SP, and CO parameters. Using MatrikonOPC Bailey Direct via SCSI on Windows 7 to share existing PI connection.

Our initial thought was to decrease Tmax, we were at 10 seconds with very little issues. I was also using 150 block reads (P,I,D,OLL,OHL). Had some issues (OPC data flat-lining) where the CIU locked up, but locking down the SCSII at 10Mbaud appears to have fixed that issue.

There were minor issues was adding OPC tags. Seems the server or the CIU (03) is having difficulty resolving some items.

During the spring outage control logic for two ID fans (not just the APIDs) where added to a module that was already taxed running 40+ loops. That is when we began having issues on the PCU (BRC400).

Meeting today to discuss options. Thanks for sharing your thoughts! Any additional insights are greatly appreciated.

> 1-2 second update on PV, SP, and CO parameters.
> 40+ loops

> That is when we began having issues on the PCU (BRC400).

First off to be perfectly clear you will never get 1 second deterministic data via the Infinet due to the inherent design of the system. That said, with a little thought and proper execution you should be able to get the information you need.

Changing the segment control function code 82 specification 9 (significant change) from the default 2% to some lower number affects ALL function codes that don't have their own sig change spec (i.e. 30) This is probably not a wise choice on a heavily loaded module, which appears to be the case here. Adding another segment and re-blocking is usually too much work to take advantage of this.

This means targetting the specific blocks you are after. For station SP, PV, and CO you would need to add AOLs (FC30) with numerically small sig change (S7) values. These are in percent of span. Rather than setting them to zero, I would ask myself what value change would I really need to get what I'm after, calculate the percentage, and then set the values there. Of course if you already have an AOL (typical for the PV) all you need to do is change S7 and not add another exception report.

Regarding the problems on the PCU - the BRC400 is the controller, NOT the PCU. The PCU is the node on the Infinet, as determined in this case by a NIS (typically redundant). Each NIS is attached at the hip with an NPM, and the NPM will communicate to other modules (i.e. BRC400 controller). You can have several controller pairs in one PCU.

So is your problem with the BRC400, or with the NIS/NPM, or both? Since you have a BRC400, you most likely have the NIS21 and NPM12. Correct me if I'm wrong.

There are upgrades to these parts that provide a significant improvement in performance - BRC410 and NIS21/NPM22. You can then trickle down your replaced equipment to a different location.

Also you might want to check out the SPIET800 to move from SCSI to Ethernet for the CIU.