| View previous topic :: View next topic |
| Author |
Message |
Denis
Guest
|
 Posted: Fri Sep 26, 2003 8:07 am Post subject: how Can i conncect to opc server(da 1) from c# |
 |
|
| Subject? |
|
| Back to top |
|
 |
Kurt
Guest
|
| Posted: Fri Sep 26, 2003 2:47 pm Post subject: |
|
|
You have a number of options but you can save yourself a lot of time and troubles by using a commercial wrapper product, such as the OPCDA.NET client development component offered by Technosoftware
Kurt |
|
| Back to top |
|
|
Randy
Joined: 27 Feb 2003
Posts: 3523
Location: OPC Foundation
|
| Posted: Fri Sep 26, 2003 3:07 pm Post subject: |
|
|
The DA RCW already contains the DA 1.0 interfaces so you wil not need to do anything there.
On the CS side you will have to write COM inter-op code that can de-serialize the buffers containing the data from the callbacks. This could be added to the sample code and the .NET API if there is a strong demand for it.
Regards |
|
| Back to top |
|
|
Martin Boers
Joined: 06 Mar 2003
Posts: 24
Location: Ireland
|
| Posted: Fri Sep 26, 2003 4:52 pm Post subject: |
|
|
| Quote: | | ...if there is a strong demand for it. |
I'm interested to know if any figures have been collected that show what the demand actually is for an OPC DA .NET wrapper.
Kurt - any hints about what the demand for your product has been like since it was launched?
Martin. |
|
| Back to top |
|
|
Kurt
Guest
|
| Posted: Sat Sep 27, 2003 1:27 pm Post subject: |
|
|
As a demand indicator I can state that Technosoftware has over 50 new OPC .Net product users per month. Even if this is considered a strong demand, I feel strongly that the OPC Foundation should concentrate on defining standards and providing simple (specification explaining) sample code, but not additional wrappers.
A good tool for the .NET OPC client developer has to be much more than the actual wrapper code.
OPCDA.NET e.g., is an OPC DA .Net wrapper that integrates into Visual Studio .Net, providing context sensitive help and project/class generation wizards. It also offers high-level functions such as browsing the server into a TreeNode structure. These additional features make usage simple and save the user a lot of time.
The application software developer should not be encouraged to work on COM InterOp level. The required data type conversions are difficult enough for the experienced system programmer and cost way to much time when done the first time. |
|
| Back to top |
|
|
Randy
Joined: 27 Feb 2003
Posts: 3523
Location: OPC Foundation
|
| Posted: Sat Sep 27, 2003 6:24 pm Post subject: |
|
|
I guess the better question is how much demand is there for a .NET equivalent to the VB6 automation wrappers where the OPC Foundation defines a standard .NET API and provides a base reference implementation.
In other words: should the OPC Foundation define a .NET API specification that offeres an alternative to the proprietory .NET APIs offered by various vendors?
Regards |
|
| Back to top |
|
|
Martin Boers
Joined: 06 Mar 2003
Posts: 24
Location: Ireland
|
| Posted: Mon Sep 29, 2003 7:46 am Post subject: |
|
|
I absolutely agree with Kurt (good sales pitch, by the way  )
I think the OPC-F has arrived at the right place with the DA Automation Interface - the OPC-F controls the interface specification, but it's up to individual vendors to provide products that use that specification - just like it is for the other OPC Specs (DA, DX, XML etc).
I think the complication with the DA Automation (VB6) interface is that the spec expicitly says that OPC DA Servers must implement the Custom interface but may also implement an Automation interface that 'wraps' the Custom interface. This means that, in theory, there is one single 'best' implementation of the Automation wrapper, and for a while it seemed to make sense that the OPC-F should develop and control that single best implementation.
The XML-DA spec didn't impose a similar restriction - an XML-DA server may wrap a Custom interface, but this isn't explicitly required.
I think any .NET specification should go the way of XML-DA rather than DA-Automation - a DA.NET server may wrap a Custom interface, but not neccessarily.
Also, on Randy's point - I don't think that the development of a .NET API specification would be providing an alternative to vendor-specific implementations; rather, it would be providing a standard interface (in the form of a .NET Interface Class Library) which all vendors would use to build their DA.NET servers. I don't think the OPC-F needs to provide a 'base implementation' any more than they need to provide a base implementation of an OPC-XML-DA Wrapper of a DA-COM server.
Sure, Technosoftware et. al. would have to release new versions of their products that conformed to the OPC .NET specifications, but it would all be in the interests of interoperability (the OPC-F's raison d'etre).
I wonder how vendors like Kurt would feel about having to release new versions of their product based on an OPC .NET specification, given that any OPC .NET spec probably wouldn't be 100% compatible with their existing product interfaces? |
|
| Back to top |
|
|
Kurt
Guest
|
| Posted: Mon Sep 29, 2003 1:00 pm Post subject: |
|
|
If a .Net API specification is required depends on the question: Is XML DA suitable for all applications or is a higher performance (no XML serialization/de-serialization) required ?
If there is a requirement for a performance .Net API then next question is: should I be modeled after OPC DA 2/3 or after XML DA ?
A .Net API specification that defines the XML DA web service stub interface would allow the same server/wrapper assembly to be used as a web service or as a .Net assembly. A client could use either, just by having a web reference respectively a .Net assembly reference.
Are there any plans / studies for a .Net API specification ?
Regards,
Kurt Haus
Technosoftware Inc. |
|
| Back to top |
|
|
Randy
Joined: 27 Feb 2003
Posts: 3523
Location: OPC Foundation
|
| Posted: Mon Sep 29, 2003 6:33 pm Post subject: |
|
|
The OPC Foundation has been looking into the possibility of a .NET API specification for several months. The current releases of the sample code for XML-DA and DA3 contain a prototype for such a specification that is based on the following assumptions:
1) The .NET API should provide transparent access to servers over multiple protocols including (but not limited to) DCOM, XML Web Services and .NET Remoting.
2) The .NET API should (like the automation wrapper) provide some basic client side state management capabilities that make it easier to develop applications using the API.
3) The .NET API should be based a 'unified' data access model that combines XML-DA and DA3 into a single set of APIs. Functionality such as asynchronous callbacks that are not supported directly by the underlying protocol can be implemented effictively within a client side wrapper.
The current sample code demonstrates that it is possible to design a fully featured .NET API based on these assumptions. This .NET API will be maintained as sample code for now, however, it may be a useful starting point for discussions on a future OPC defined .NET API specification.
Regards |
|
| Back to top |
|
|
Martin Boers
Joined: 06 Mar 2003
Posts: 24
Location: Ireland
|
| Posted: Mon Sep 29, 2003 8:41 pm Post subject: Re: |
|
|
| Kurt wrote: | | If a .Net API specification is required depends on the question: Is XML DA suitable for all applications or is a higher performance (no XML serialization/de-serialization) required ? |
The applications I've been involved in definitely need higher .NET inter-process communication performance than Web Services can provide. It seems that Remoting (TCP/Binary) is the only option here, but without an OPC DA .NET spec we're stuck with defining our own .NET Remoting interfaces 
| Kurt wrote: | | If there is a requirement for a performance .Net API then next question is: should I be modeled after OPC DA 2/3 or after XML DA ? |
(or something different again?)
| Kurt wrote: | | A .Net API specification that defines the XML DA web service stub interface would allow the same server/wrapper assembly to be used as a web service or as a .Net assembly. A client could use either, just by having a web reference respectively a .Net assembly reference. |
This is a good idea. I saw a (non-OPC related) discussion of this on discuss.develop.com. The conclusion was that, if you want to define an interface that can be used by both Web Services and .NET Remoting, the people who use Remoting will wonder why the interfaces are so limited in their definitions (e.g. there will be no 'properties' or 'events', only 'methods'). If you were to focus on Remoting alone, your interfaces can be (almost) as rich as if you were linking to an in-process .NET assembly.
I heard a whisper that MS might be working on Web Services that offer as rich an interface as .NET Remoting, while still conforming to the WS-* specifications. Now that would be worth seeing, if/when it ever materialises.
Regards,
Martin Boers |
|
| Back to top |
|
|
RMahnA2
Joined: 09 Jun 2003
Posts: 25
|
| Posted: Wed Oct 01, 2003 3:07 pm Post subject: Re: |
|
|
| Martin Boers wrote: | | I think the complication with the DA Automation (VB6) interface is that the spec expicitly says that OPC DA Servers must implement the Custom interface but may also implement an Automation interface that 'wraps' the Custom interface. This means that, in theory, there is one single 'best' implementation of the Automation wrapper, and for a while it seemed to make sense that the OPC-F should develop and control that single best implementation. |
The complication today is the OPC Server vendors end up needing to provide an Automation wrapper so the customer has a wrapper that has been tested with the server. Then when the customer calls the OPC server vendor for support, the vendor needs to isolate the problem by having the customer change to use the vendor supplied Automation wrapper. I many cases, the customer isn't in a situation that they are prepared to change their source to use a different Automation wrapper. The customer is again left in the middle trying to resolve a wrapper and/or server problem.
Seems like the Automation wrapper et al should be an open source project, so that everyone is trying to produce one best of breed solution instead of producing headaches for the user. |
|
| Back to top |
|
|
Randy
Joined: 27 Feb 2003
Posts: 3523
Location: OPC Foundation
|
| Posted: Wed Oct 01, 2003 3:59 pm Post subject: |
|
|
| Quote: | | Seems like the Automation wrapper et al should be an open source project, so that everyone is trying to produce one best of breed solution instead of producing headaches for the user |
The VB6 automation automation wrapper was supposed to be maintained like an open source project from the beginning, however, the problems arose because there was no one to who could co-ordinate updates to the baseline and manage releases.
I am currently collecting the source code for the VB6 wrapper that has been donated by various vendors. I intend to merge these into a single 'best of breed solution' in the near future.
All new re-usable components of the sample code such as the .NET API will be maintained on a similar basis. In short, the OPC Foundation has commited resources to ensure that problems like the VB6 automation wrapper problems do not happen again.
Regards |
|
| Back to top |
|
|
Martin Boers
Joined: 06 Mar 2003
Posts: 24
Location: Ireland
|
| Posted: Wed Oct 01, 2003 7:54 pm Post subject: Re: |
|
|
| Kurt wrote: | | should I (a .NET API) be modeled after OPC DA 2/3 or after XML DA ? |
I'm interested in hearing the arguments for and against these options (plus the third option - "start with a clean slate"), from all the OPC product vendors out there - especially OPC .NET Client developers.
Kurt has already given a good argument for the XML-DA option: OPC Clients can switch from XML (Web Services) to .NET Assembly almost transparently.
Other opinions?
Another question I'm interested in getting opinions on:
"Should an OPC .NET API be a Wrapper (like the DA-Automation wrapper), or should it be allowed to be a stand-alone API (like XML-DA) ?"
Martin. |
|
| Back to top |
|
|
Randy
Joined: 27 Feb 2003
Posts: 3523
Location: OPC Foundation
|
| Posted: Wed Oct 01, 2003 8:19 pm Post subject: |
|
|
| Quote: | | Kurt has already given a good argument for the XML-DA option: OPC Clients can switch from XML (Web Services) to .NET Assembly almost transparently. |
I think Kurt's argument meant that a .NET API should define a single interface that allows the same server to be accessed via multiple protocols.
If my interpretation is then correct then the prototype .NET API in the sample code already does this. In other words, a single server implemention in .NET can be exposed as a COM server, a XML web service or a .NET remoting server.
| Quote: | | I'm interested in hearing the arguments for and against these options (plus the third option - "start with a clean slate"), from all the OPC product vendors out there - especially OPC .NET Client developers. |
I think a two stream approach makes sense: working on a 'clean slate' spec can progress in conjunction with work on a .NET API. I see the .NET API as something that should happen in the short term because a lot of people are starting to develop client applications in .NET and want to use these applications to communicate with existing servers.
Regards |
|
| Back to top |
|
|
Kurt
Guest
|
| Posted: Thu Oct 02, 2003 3:46 pm Post subject: |
|
|
With an XML-DA modeled .Net interface specification I didn’t mean a .Net API that combines OPC-DA and XML-DA into a single .NET API specification. With the fundamental differences between OPC-DA and XML-DA a combined API cannot be a clean and user friendly solution.
I suggested to use the XML-DA specification as the .NET API. Instead of defining the XML messages as done in the XML-DA specification, the .Net API would define the classes and methods as generated by .Net for the XML-DA WSDL.
A client using such an API would be able to access a XML-DA webservice or access the server assembly directly, without XML serialization overhead. Also a single XML-DA server implementation could be used both ways.
I view an XML-DA modeled .Net API as future oriented approach, giving a user friendly API but placing more burden on the OPC DA wrapper and not allowing the optimized use of all OPC DA features.
For performance reasons an OPC DA specific .Net API may be required. If so then I rather see tow different API’s than one complicated API combining all the features of OPC DA and XML-DA.
Kurt Haus
Technosoftware Inc. |
|
| Back to top |
|
|
|
