# DO PLCs have OPC?

J

#### james fang

I have one question -- does PLC (like siemens s7, ab's slc-500's) have OPC server (or client)? I've checked many web sites including the "WWW.OPCFOUNDATION.ORG":http://www.opcfoundation.org . None of them has a very clear answer. If not, how can a pc_based server exchange data with connected PLCs ?

D

#### Daniel Chartier

Hello;
If you open the link you posted to the OPC foundation, and go to the Member area list, you will find links top Siemens, Rockwell, Schneider, Mitsubishi, Moeller and many other PLC manufacturer sites. They ALL have OPC server/client connections (or risk losing market share). If you would rather have a 3rd party view, try the sites for Kepware, Synergetics, Matrikon and other automation software companies who develop OPC link for different PLCs.

Hope this helps,
Daniel Chartier

S

#### Steve Myres, PE

A PLC as such, does not have an OPC server. OPC is a standard for communications interfaces which run under Windows on a PC connected to the PLC.

Most PLC's, and many other industrial control devices have OPC servers written for them. You can think of an OPC server like a device driver. It is written to communicate with the PLC, using the PLC's standard proprietary comm commands, while providing a consistent interface for OPC clients running on the PC, or other PC's networked with it.

Frequently the OPC server is available from the PLC manufacturer, but many are also available from third parties like Kepware and Iconics, and can also be provided with communications cards for the PC, like the 5136 DH+ card from SST.

F

#### Frank Iwanitz

Hi,

up to now (released) opc specs are based on Microsofts Distributed Component Object Model (DCOM).
Therefore OPC products need the DCOM runtime to work. DCOM runtime is available for Windows OS (9X/ME/NT/2000/XP/CE) for VxWorks and UNIX flavors (including Linux).
I guess about 98% of opc products are running under Windows OS. That's the present.
OPC is specifiying a OPC XML and a OPC DX specification.
The first will support reading and writing of data by interchanging XML constructs, i.e. products based on this spec could run on any platform that supports XML. This also could be a PLC. OPC DX specifies peer-to-peer interaction between servers. To make this running on field devices is a goal of the spec. Then opc products can run on plcs.
There are two ways to make this happen.
Either to use OPC XML as the way as DX products interact with each other or the port a subset of DCOM to the devices.
There are two example for the last approach - PROFInet introduce by Siemens that provides a public domain DCOM implementation and a solution from Rockwell. They have shown a solution at Hanover Fair where a DX modul was running in a PLC. But they did not gave any information how this works.
About your last question - how to access data from a device by using an opc server.
The opc specs define the way how server and client interact with each other. The spec does not define how data is obtained by the server from the process (or whatever) and send to it.
There are a lot of protocols that can be used for this purpose - to exchange data between a program on the pc and peripheral devices.

Regards,

Frank

G

#### Greg Goodman

There's no reason a PLC cannot have an embedded OPC server. (There are probably some that do.) But there's no reason that a PLC manufacturer has to go to all that trouble to provide OPC access to their device. All that's required to provide OPC access to any PLC is a program running on the PC that implements:

a) the industrial protocol for talking to the PLC, and
b) the OPC server interface for talking to other PC programs

You'll find that there are hundreds of commercially available OPC servers that wrap the OPC interface around the comm protocols for
industrial devices.

Greg Goodman
Chiron Consulting

K

#### Kriebel, Rick

We currently have AB, Siemens S5 & S7, and Omron PLCs communicating through OPC servers. The Siemens and Omron OPC servers run on a PC with Rockwells's RSView. RSview collects process data from our manufacturing process via OPC and then writes the data to a SQL database running on a remote server. This data is then available, in real time, via an intranet to our engineering
staff. Works well with little problem. Getting the OPC severs to communicate with their PLCs took a bit of tweaking, but getting the OPC
servers to communicate with RSView was easy. Siemens sells its own OPC Server. Omron recently came out with it's own, but we're using InGears OPC server for the Omrons.
Reagrds,
Rick Kriebel, [email protected]

M

#### Michael Griffin

To perhaps add a wee bit more clarification to this subject - a PLC does not
need or use OPC. It is the application program which is running on a PC which uses OPC to talk the protocol which the PLC understands.

As someone else put it, an OPC server can be thought of as just a driver for the PC. This "driver" is the OPC "server". The application program is the OPC "client" which talks to the driver. OPC is used with WIndows operating systems. I'm not aware of an equivalent standard for any other operating system (although I've never really looked either). Before the OPC standard, the drivers were part of the application program which meant that your choice
of software was often limited by what protocols it supported.

So the way it works is, the PC application (the "client") talks to the OPC
"server", which in turn spits out the appropriate protocol on the industrial network. The PLC (or other device) sees the message and responds to it in the other direction (I'm obviously simplifying the networking here). The PLC doesn't know anything about OPC, it just talks its normal protocol.

************************
Michael Griffin
************************

D

#### Donald Pittendrigh

Hi All

Some PLC's.... As such..... Do have OPC servers, take a look at the PLC Direct range for one.

Bye
D. C. Pittendrigh

C

#### Curt Wuollet

It's a matter of perspective, here's mine.

Yes, just think of it as another kludge you need because things can't communicate directly and a great way to make your system as reliable as Windows. And best of all, it's Windows only and no interfaces need be exposed without a credit card.. :^) It is a universal kludge though,
effectively discouraging more suitable and open, not to mention less lucrative, interfaces and reinforcing the monopoly. You get to sell and maintain at least one Windows box with each system. Microsoft thanks you, and for the privilege of moving a few bytes between two digital machines, you get roped into a whole MS infrastructure. What a deal! If you like that, I've got this "bridge".........

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

M

#### Michael Griffin

> It's a matter of perspective, here's mine.
>
> Yes, just think of it as another kludge you need because things can't
> communicate directly and a great way to make your system as reliable
> as Windows. And best of all, it's Windows only and no interfaces need
> be exposed without a credit card.. :^)

Well, yes - it's Windows only. Why wouldn't a Windows "driver" be Windows only? If you ignore all the OPC mumbo jumbo, all it really is, is a driver. It is certainly an improvement over the days when every Windows MMI program came with its own set of drivers and your software selection was limited by the available drivers.

> It is a universal kludge though,
> effectively discouraging more suitable and open, not to mention less
> lucrative, interfaces and reinforcing the monopoly.

It's not a "universal kludge" - you just said so yourself. It's Windows only, and only for so long as Windows supports the methods OPC uses.

> You get to sell and maintain at least one Windows box with each system.

I think you've got things backwards. You don't buy Windows to use OPC, you buy OPC if you are using Windows. If you are using an operating system other than Windows, then you use some other driver format. What is the standard, universal, industrial communications driver interface for Linux? Can you tell us how that is done the "right" way?

> Microsoft thanks
> you, and for the privilege of moving a few bytes between two digital
> machines, you get roped into a whole MS infrastructure. What a deal!
> If you like that, I've got this "bridge".........
<clip>

The people at Microsoft who make the real decisions as to how Windows works don't even know this market exists. They're not plotting to take our money, because we don't have enough money to interest them.

Where people are going to run into trouble with OPC is with the following.
Microsoft will change Windows and the old OPC drivers won't work. You won't be able to get new OPC drivers for all your old production machines with proprietary protocols because the manufacturers won't bother supporting all
the hardware they aren't selling anymore. If you ever have to replace a computer with a new one (and there's no "if" about that), you are going to have machines you can't talk to anymore.

OPC is an improvement over the old situation where every application program
came with its own set of proprietary drivers. That's all it does though. It's not a long term or universal solution to industrial communications. It can't be when it's so closely tied to one company's proprietary software (Windows), and changes to that software are driven by factors totally outside of this industry.
The only real "solution" to the industrial communications question is to use
communications protocols which are open and come with no strings attached. I won't criticise OPC for being only a partial solution. I would criticise anyone who makes it out to be more than it really can be. Perhaps you ought to direct your attention in that direction rather than pursuing red herrings with Windows.

--

************************
Michael Griffin
************************

C

#### Curt Wuollet

Hi Michael

Actually, we're closer on this than most but the idea was to start a dialog, so here goes.

Michael Griffin wrote:
>
> On May 25, 2002 12:20 pm, Curt Wuollet wrote:
> > It's a matter of perspective, here's mine.
> >
> > Yes, just think of it as another kludge you need because things can't
> > communicate directly and a great way to make your system as reliable
> > as Windows. And best of all, it's Windows only and no interfaces need
> > be exposed without a credit card.. :^)
>
> Well, yes - it's Windows only. Why wouldn't a Windows "driver" be Windows
> only? If you ignore all the OPC mumbo jumbo, all it really is, is a driver.
> It is certainly an improvement over the days when every Windows MMI program
> came with its own set of drivers and your software selection was limited by
> the available drivers.

And now your software selection is limited by the fact that the only OS supported is Windows. A sub-optimal choice by any standard. And entirely in the control of folks not noted for their benevolence.

>
> > It is a universal kludge though,
> > effectively discouraging more suitable and open, not to mention less
> > lucrative, interfaces and reinforcing the monopoly.
>
> It's not a "universal kludge" - you just said so yourself. It's Windows
> only, and only for so long as Windows supports the methods OPC uses.
>
> > You get to sell and maintain at least one Windows box with each system.
>
> I think you've got things backwards. You don't buy Windows to use OPC, you
> buy OPC if you are using Windows. If you are using an operating system other
> than Windows, then you use some other driver format.

That's the whole problem, you _can't_ use some other driver format because either one end or the other requires support from the builder of the equipment or a cartel and they _only_ support Windows. If it were that easy, I would be busily supporting everything out there. That's the "Let them eat cake!" argument that ignores reality. The reality is that if you are going to use the automation equipment that's available, you are going to buy and use Windows or it's useless to you. As an experiment, try to do otherwise and let me know what you find. There are a few exceptions but I'll bet you can't find them. It's like arguing that you can start your own Electric Utility or Gas company or other monopoly. As a practical matter, their exclusive support for the monopoly binds you to that monopoly and dictates the surrounding infrastructure. Or course, you can build your own PLC and automation system but that hardly disproves the above. It never looks like exploiting a monopoly from the inside.

What is the standard,
> universal, industrial communications driver interface for Linux? Can you tell
> us how that is done the "right" way?

Absolutely. It shouldn't be neccessary to use Windows, or Linux, or any particular vendors product to achieve trivial communications. It is glaringly obvious that no automation and control processor will always be standalone anymore. They should share at least one common protocol and transport that is universal, vendor blind, and open so that this silly neccessity to kludge things just goes away. It should be reasonable to code on any platform and retrofit to existing equipment with perhaps a coprocessor if needed.(EG BASIC modules, C modules). It should support both serial and Ethernet transport to make use of the greatest commonality and the most ubiquitous network existing. It need not be perfect or a be all, end all solution. We could make do with almost anything reasonable that you could _always_ count on to be supported. This level of comms is simply common sense and would solve enormous numbers of problems for everyone. Whether you are using SCADA or not, no matter which vendor you favor, any two intelligent entities should be able to pass data without an intermediary or regard for your existing infrastructure. It needn't replace the more specialized, proprietary, Tower of Babel offerings, but it could in the 80 or 90 percent of cases when all you need is to move a few bytes back and forth. It should be the "No Big Deal" method of choice.

What's the downside of that?

> > Microsoft thanks
> > you, and for the privilege of moving a few bytes between two digital
> > machines, you get roped into a whole MS infrastructure. What a deal!
> > If you like that, I've got this "bridge".........
> <clip>
>
> The people at Microsoft who make the real decisions as to how Windows works
> don't even know this market exists. They're not plotting to take our money,
> because we don't have enough money to interest them.
>
> Where people are going to run into trouble with OPC is with the following.
> Microsoft will change Windows and the old OPC drivers won't work. You won't
> be able to get new OPC drivers for all your old production machines with
> proprietary protocols because the manufacturers won't bother supporting all
> the hardware they aren't selling anymore. If you ever have to replace a
> computer with a new one (and there's no "if" about that), you are going to
> have machines you can't talk to anymore.

It would make a lot of sense to avoid that since it's a known problem.

> OPC is an improvement over the old situation where every application program
> came with its own set of proprietary drivers. That's all it does though.

No one would argue that, but what you get in trade has proven to be an even bigger set of problems. People ignore them because everyone has them so they're no "automation" problems, but they never existed before. And they predominate the problems posted to the list if you keep count.

It's
> not a long term or universal solution to industrial communications. It can't
> be when it's so closely tied to one company's proprietary software (Windows),
> and changes to that software are driven by factors totally outside of this
> industry.
> The only real "solution" to the industrial communications question is to use
> communications protocols which are open and come with no strings attached. I
> won't criticise OPC for being only a partial solution. I would criticise
> anyone who makes it out to be more than it really can be. Perhaps you ought
> to direct your attention in that direction rather than pursuing red herrings
> with Windows.

As I said, we're closer than most on this issue. But if everyone keeps using Windows without question and expects someone else to make things change, it will never happen. Conversely, if half the folks here merely asked twice for alternatives that favored them instead of the vendors, I and everyone else, could use whatever was needed to automate things. Accepting the status quo is how we got here. And apathy is the lifeblood of the monopoly.

Regards

cww

M

#### Michael Griffin

Curt Wuollet wrote:
> Actually, we're closer on this than most but the idea was to start
> a dialog, so here goes.
...
> >
> > I think you've got things backwards. You don't buy Windows to use
> > OPC, you buy OPC if you are using Windows. If you are using an operating
> > system other than Windows, then you use some other driver format.
>
> That's the whole problem, you _can't_ use some other driver format
> because either one end or the other requires support from the builder
> of the equipment or a cartel and they _only_ support Windows. If it were
> that easy, I would be busily supporting everything out there. That's the
> "Let them eat cake!" argument that ignores reality.
> The reality is that if you are going to use the automation equipment
> that's available, you are going to buy and use Windows or it's useless
> to you.
...

I'm not disagreeing with you, but I think you are confounding two separate problems - proprietary communications protocols and OPC as a "solution" for it. OPC isn't even a solution for proprietary protocols when using Windows. If the owner of the protocol doesn't want to update their OPC "driver" you are just as stuck when using Windows as you are any other operating system.

This is a rather compelling argument for me at the moment, because I am facing an analogous situation with a proprietary driver for a special board from a well known major company (who will remain nameless). The old driver won't work with new PCs - it needs a minor "tweek" in a timing loop. The company who made the product has decided to not support it any more. There is no new driver available, no replacement, no upgrade path, and they don't want to discuss it. I can't even pay someone else to fix the problem.

In a couple of years, this list will be receiving a steady stream of sob stories from people who are in the same boat with their OPC servers. Their old computer died, the old OPC stuff doesn't work with the new computer, and they can't get a new OPC server for the proprietary protocol because the company who originated it doesn't feel like updating it any more. And spouting all the OPC/DCOM/WXYZ acronym mumbo jumbo isn't going to get their machine running again no matter how much they beg and plead.

This doesn't mean that OPC is bad. It just means it doesn't solve the main problem of proprietary protocols - which is the risk involved in using them at all.

--

************************
Michael Griffin
************************

C

#### Curt Wuollet

Hi Michael

Michael Griffin wrote:
<clip>
> I'm not disagreeing with you, but I think you are confounding two
> separate problems - proprietary communications protocols and OPC as a
> "solution" for it. OPC isn't even a solution for proprietary protocols when
> using Windows.

They are actually facets of the same problem, giving others control over your vital functions by using their secret IP to accomplish them. You
can never truly own it, you are totally at their mercy. And some are less than merciful.

> If the owner of the protocol doesn't want to update their OPC
> "driver" you are just as stuck when using Windows as you are any other
> operating system.

Actually you are stuck more often with Windows because you can guarantee that even if the vendor remains faithful your platform will be
obsoleted.

> This is a rather compelling argument for me at the moment, because I am
> facing an analogous situation with a proprietary driver for a special board
> from a well known major company (who will remain nameless). The old driver
> won't work with new PCs - it needs a minor "tweek" in a timing loop. The
> company who made the product has decided to not support it any more. There is
> no new driver available, no replacement, no upgrade path, and they don't want
> to discuss it. I can't even pay someone else to fix the problem.
>
> In a couple of years, this list will be receiving a steady stream of sob
> stories from people who are in the same boat with their OPC servers. Their
> old computer died, the old OPC stuff doesn't work with the new computer, and
> they can't get a new OPC server for the proprietary protocol because the
> company who originated it doesn't feel like updating it any more. And
> spouting all the OPC/DCOM/WXYZ acronym mumbo jumbo isn't going to get
> their
> machine running again no matter how much they beg and plead.

Open Source is the obvious cure for that.

And that isn't all. If the big software folks get their way, they will be entitled to "self-help" where you keep paying or your software simply stops working. That's a bit from UCITA. It's really strange, people always use the example of "what if the company goes out of business" when actually that's the best they can hope for in some cases.

> This doesn't mean that OPC is bad. It just means it doesn't solve the
> main problem of proprietary protocols - which is the risk involved in
> using them at all.

I do disagree there, OPC is bad exactly because of this exposure and the risk that it can be scuttled at any time it is profitable to do so.
I wonder how many people actually consider these things before they just use whatever is provided. That's an awfully trusting attitude considering who you are dealing with and the examples that have been made. Taking the easy way out can have big implications for the future. I think it's a reasonable expectation that once you build a solution no one should be able to shut you down and needed tools and facilities should not expire. Perhaps legislation that when a company stops support for a product, they need to open it up so the customers can take over. Pretty soon we would have quite a collection of old, but
supportable software.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

H

#### Heavner, Lou $FRS/AUS$

Curt Wuollet wrote:
>>>>>
I do disagree there, OPC is bad exactly because of this exposure and the risk that it can be scuttled at any time it is profitable to do so.
I wonder how many people actually consider these things before they just use whatever is provided. That's an awfully trusting attitude considering who you are dealing with and the examples that have been made. Taking the easy way out can have big implications for the future. I think it's a reasonable expectation that once you build a solution no one should be able to shut you down and needed tools and facilities should not expire. Perhaps legislation that when a company stops support for a product, they need to open it up so the customers can take over. Pretty soon we would have quite a collection of old, but
supportable software.
<<<<<

Hey Curt,

Do you drive a car? It's pretty risky, dontcha know! Do you really believe that in the cut throat automation business, somebody is going to risk alienating their customer base by scuttling OPC? Or maybe you believe that all of these competitive automation companies would be capable of conspiring together to kill it. There is a pretty big gulf between possible and plausible. And besides, don't you stand to make a huge "killing" by making things right if that were ever actually to happen.

Regards,

Lou Heavner
Consultant
Emerson Process Management
Phone: (512) 834-7262
Fax: (512) 832-3199
e-Mail: [email protected]

C

#### Curt Wuollet

Hi Lou

Haven't heard from you for a long time.

"Heavner, Lou [FRS/AUS]" wrote:
> Hey Curt,
>
> Do you drive a car? It's pretty risky, dontcha know! Do you really believe that in the cut throat automation business, somebody is going to risk alienating their customer base by scuttling OPC? <

I wasn't thinking about the automation companies, they would be victims along with their customers. Let me illustrate with a parable ripped from the headlines as it were.

Some folks have invested a great deal of time and effort using another MS technology for file sharing and print service and the like. They have
been very succesful at it and it's widely installed and would cause a lot of disruption and much litigation if it went away. MS changed it's
protocol enough to require updates and it's licensing to disallow their use, citing patents they hold on the technology. They can use their
"old" technology but, it won't work with Microsoft's new stuff. And MS will sue if they use the new stuff, probably even if they reverse engineer it.

I don't make this stuff up, that's the situation with SAMBA today. Do you know of any reason they couldn't do the same with OPC if they so desired? And they may desire, so that everybody has to get on board bloat.NET or whatever they decide is to be the new way. The disruption is simply a market opportunity to them, they could do it and almost
everybody would meekly go along or risk jumping off the gravy train. I am glad I don't have "partners" like that.

> Or maybe you believe that all of these competitive automation companies would be capable of conspiring together to kill it. There is a pretty big gulf between possible and plausible. And besides, don't you stand to make a huge "killing" by making things right if that were ever actually to happen.<

No on the first clause and the second. I doubt that I could somehow coerce users to flood me with money for software that is and always will remain free. That's what _our_ license is about. We might build a community more quickly, but that would be in the public interest. I suppose we would be happy to see it, but you could still leave your credit card in your wallet.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

M

#### Michael Griffin

On June 5, 2002 09:41 am, Lou Heavner wrote:
<clip>
Do you really believe that in the cut throat automation business, somebody is going to risk alienating their customer base by scuttling OPC? Or maybe you believe that all of these competitive automation companies would be capable of conspiring together to kill it. There is a pretty big gulf between possible and plausible.
<clip>

I'm sure that Mr. Wuollet has his own answer to this question, but I found your comments so peculiar that I couldn't let them pass. Are you actually suggesting that automation suppliers never leave their customers stuck
without a solution when computer operating systems have changed? I have seen this happen so many times in so many ways that I find it difficult to believe that you are in the same business as the rest of us.
How many times do we see people posting questions on this list about their old software won't run with their new version of Windows? What is the solution people often give - "stockpile old computers". We tried that one, and our stockpile just ran out recently. Now what?

You mentioned yourself that the business is "cut throat". This means these companies are not going to always provide upgrades to old software which is not intended for current products. If it doesn't help generate new sales with current product lines, they often won't support the old software. They take the position that they don't control Windows, so it isn't their fault. What is so special about OPC that will make it different from all other automation
software in this respect?

French economist Frederic Bastiat said to look at things from the point of view of the consumer, because the interests of the consumer are the interests of the human race. When it comes to industrial communications, the consumers
today are being poorly served.

************************
Michael Griffin
************************

R

#### Ranjan Acharya

I agree with Curt. The proprietary systems such as Windows are a bit of a pain to support. We already have dead systems out there (e.g., a SCADA package with no source code running on an older version of Microsoft Windows with no source code). How do we support them? They work, but the customer just needs one more feature that the SCADA software (and perhaps Windows too) are unable to support. The completely functional system has to be ripped out and replaced with an equally risky system (don't worry, we tell them, OPC is a standard ....).

I had an argument with a representative from a manufacturer regarding product life cycles. They thought it was no big deal that the product life
cycles were now much less than a year for many systems rather than the traditional fifteen years or so. I have probably used that story before, but I think it is indicative of OEM thinking, especially if they hold all the cards regarding closed systems. PLC-5 and Modicon 984 were closed too, but at least they were (or are still) around for ever.

Not to mention all the young keen chaps we hire that do not have a clue what to do at the command line.

England 1 - Argentina 0

RA

R

#### Ranjan Acharya

<clip>
French economist Frederic Bastiat said to look at things from the point of
view of the consumer, because the interests of the consumer are the
interests of the human race. When it comes to industrial communications, the
consumers today are being poorly served.
</clip>

I think that Mr. Griffin has provided an excellent point. It is not just with OPC either. Consider the following:

- Cheesy IEC field bus standard (61158) that is not really a standard but eight non-interoperable buses that represent political wrangling and voting blocks and not the interests of the end users or real "engineering"

- Cheesy IEC programming standard (61131.3) that was originally supposed to be the Holy Grail of industrial system programming. I remember going to presentations that showed it as a programming package that would go to any PLC. Take your software from brand A and load it on brand B. Not really I think. Instead we have each manufacturer deviating from the standard however they please

- Non-interoperable top-layers for Ethernet - Modbus over Ethernet TCP/IP, PROFInet, EtherNet/IP and so on. The only solution has been to push OPC-DX and OPC-DA, but I think we all know where that will lead

At the end of the day all we have is complex and cumbersome systems. We spend an incredible amount of time on any project working with
non-interoperable (either because the OEM said it would work and it doesn't or because the OEM is not going to provide a solution or because there isn't an OEM anymore) systems. Customers are frustrated and angry, often at the integrator. "We just bought this from you a couple of years ago, and now you are saying that we have to upgrade to version 7, but we cannot import the version 6 application directly and therefore you are charging us X thousand republic credits to re-write code that has nothing wrong with it to begin with".

My rant for the day. I feel much better.

RA