I am a student and I'm working on a project to create a web client (remote) application to control a RTU/Modbus device. I'm thinking of using KEPServerEX OPC Server. I read that a Visual Basic Client can be created to connect to this specific OPC Server. Can anyone please tell me if this server supports ASP.NET or if I will need specific driver/wrapper?
Any other suggestion will be greatly appreciated.
To access COM objects (OPC Servers) C++ programmers use the OPC custom interfaces
- Kraig Brockschmidt, Inside OLE, Second Edition, Microsoft Press, Redmond, WA
- OPC Data Access Custom Interface Standard, Version 2.0, OPC Foundation
The OPC foundation created a common wrapper DLL to allow simpler programming environments with Automation capabilities (Visual Basic, Delphi, ASP...)
- OPC Data Access Automation Specification v2.02
For .NET development environment you either wrap the wrapper DLL or you install an OPC XML service which comes with your OPC DA Server to allow your program to call the web service interfaces.
Raymond van der Tas
Definitely use the KEPServer and go to http://www.opcwebclient.com/ to get the OPC client tools that you need for the web application. They have a free demo so you can make sure that everything works before you fork over you student loan money.
If you are a student, then you likely have more enthusiasm for learning than you have money. If the purpose is to create a simple web client, then I would suggest that instead of purchasing a proprietary software stack, that you use free software instead.
There are plenty of free source code implementations of Modbus available on the internet; no doubt others could recommend particular ones. The Apache web server is free. Web scripting languages such as PHP or Python are free. There is plenty of free documentation available on the internet on all of these.
You'll probably find that for a beginner undertaking a small project the fewer layers you add to your project the easier it will be to interface and troubleshoot, as it would be more transparent. Proprietary software like ASP and OPC have to add a lot of extra layers to the system to get around the problem of integrating it without source code.
I don't know how you intended your web client to work, but even CGI might do the job. CGI might be a bit long in the tooth, but it would probably be *much* simpler for something like this than just about anything else I can imagine.
Thank you guys for your help. I think that Kepware's server has some sort of time limitation so I don't think I will have to buy it...
I don't really understand what's is going on with this wrapper and the OPC XML service!!!! XML is the layer between the Client and the server????
I contacted Kepware and they send me a .NET-enabled OPC Automation DLL.
The controlled device will be a Dupline Master Generator. The only problem is that my teachers said that the Website must be created in ASP.NET.
Question from Leonidas Kallis - "I don't really understand what's is going on with this wrapper and the OPC XML service!!!! XML is the layer between the Client and the server????"
This is the part that applies to where I said that the fewer layers you had to deal with, the more transparent this would be to a beginner. We'll start with a bit of history. The following is an over simplified version of the story, but telling the whole tale would take much too long.
At one time industrial communications drivers from different software publishers or hardware manufacturers each had their own custom interface. Eventually someone proposed that for drivers used with MS-Windows, a common interface definition could be used so that drivers written by one company could be more readily used with software from another. The interface definition used the MS COM/DCOM object model, which was the method Microsoft was promoting at that time. This allowed the drivers to be "linked" to the application without having the source code for either (which was a concern with this sort of proprietary software). It only worked with MS-Windows, but that was a restriction they decided to live with. A forum for the software vendors which supported this was formed, called the OPC Foundation.
The OPC driver (OPC "server") talks whatever the actual protocol is to the field device (Modbus in your case). The OPC server has a set of COM/DCOM "tags" (memory variables) which other programs can read or write (you configure and name these tags when you set the OPC software up). These "tags" correspond to Modbus "registers" (variables) in the field device.
Now go forward a few years to today. Microsoft has now said that the Win32 and COM/DCOM which MS-Windows has been based on up to now are obsolete and shouldn't be used anymore. They are instead being phased out and replaced by "dot Net" (and other associated new stuff). They also don't work very well in larger and more complex systems. OPC is based on COM/DCOM. The OPC Foundation found the rug being jerked out from beneath its feet.
Their answer was to add an XML layer between the OPC software and the software using the information (the web server in your case) to try to abstract the COM/DCOM dependencies away. Why use XML to do this? Well, if you don't use XML these days, you're just not buzz-word compliant.
So here is what you have:
- A field device connected to the PC hosting the OPC server using a serial connection and talking the Modbus protocol.
- To this you are going to add an OPC server (driver software) with an XML based protocol. This may or may not be on the same computer as the web server.
- The web server is an MS-Windows server running IIS,
- It uses ASP with the scripting done in either C# or VB-dot-Net (probably C# if you want it to work properly with all dot-Net libraries). You need to write the web scripts to tie everything together.
- The information from the OPC server is sent to (is request by) your web application, and arrives in the form of an XML "document" (a package of XML). You need an XML parser to parse out the data you are interested in (and you need to do all this in reverse to send commands).
This sounds like a complicated combination, even for an experienced professional.
Something that has made me suspicious that there may be more complications is your statement that: "my teachers said that the Website must be created in ASP.NET". Who controls the server that the web application will run on? Is this your own dedicated server (PC), or is this a shared server that everyone in the class submits their project on? The latter is typical for web programming classes, in which case will you be allowed enough access to install, configure, and troubleshoot the OPC server software (likely not, if it is a shared server)?
On another note, can you get any documentation or examples for what you are trying to do? The Kepware web site states that "(t)he current examples that are installed with the Server do not support VB.net". The examples that I can find mention "Visual basic 5.0 or better" (in other words, they are old). I can't find any mention at all of C# on Kepware's web site. Unless Kepware has some examples for you, you may be doing a lot of research by trial and error.
Will the Kepware software work on the particular web server you have to use? Dot-Net has a lot of problems with incompatibilities between versions. That is, something that works with one version of the dot-Net run-time may not work with a different version (and the incompatibilities go in both directions - forwards and backwards). If you don't have complete control of the server you have to submit the work on, you can't fix, or even troubleshoot the problem.
My answer is going beyond your actual questions, and I am guessing at what your actual situation is. I am not trying to discourage you from your project, but I do wish to point out that it sounds as if it will be rather complex, in large part due to the restrictions placed on implementing it.
Now I starting to understand the situation... Kepware send me a wrapper for dot.net and an example.
Here is the link:
"Although the example is written in VB .NET, you should be able to apply the principles to ASP .NET.
The .zip file, when extracted, will create a project folder with an install folder and bin folder beneath. The install folder contains the .NET-enabled OPC Automation DLL. You will need to read the Readme.txt file to install the DLL in the proper location."
I will develop my project at home. Firstly I want to create a Visual Basic.Net client and to experiment with it.
I have 2 PCs at home connected in a network. I want to run the Opc Server on the first one and to control him remotely from the other with a client application. If I succeed then I will try ASP.NET.
When kepware says "Advanced Simulator OPC Server" does it mean that this Simulator simulates hardware devices????
One more problem is the documentation. I can download nothing from OpcFoundation.com...
So the question is if should use the wrapper provided by Kepware or use XML???
You think that the XML solution is better and me too.
The only good thing is that I have plenty of time.
In reply to Leonidas Kallis - KEP's "simple example" ("Simple VB .NET OPC Example.vb") has over 3000 lines! That doesn't sound very simple. It's a good thing that you have lots of time, as I think you will need it.
As for the XML layer, I wasn't recommending it if you don't actually need it. It is adding yet another layer that you will need to deal with. If you were doing this for a project that it is intended to run for a decade or more rather than as just a student project, then the XML layer might make sense. In planning for product with a long life, you have to consider how to remain compatible with layers that might need to be replaced at different times. XML is good for things like that. This project will however get thrown away once it is complete. If you wish to pursue the XML aspect, you might wish to consider adding it in once the rest of the project is working.
However, I could be wrong about this as I am assuming you can integrate the wrapper into ASP similarly as with straight Dot-Net. One of the key things to look into is how to integrate the OPC server with ASP. You may need the XML option just to get them working together.
As for your question on what the "Advanced Simulator OPC Server" product is, the KEP web site states: "The Advanced Simulator Driver was designed to plug into our industrial based communications server product. This product supplies reliable data access to any HMI, SCADA, Historian, or Enterprise application that supports OPC, DDE, FastDDE, and SuiteLink. This driver provides single-point access to multiple ODBC data sources via ODBC. The driver simulates live data by traversing through all the records in a selected table at a rate set by the user. Using the power and speed of OPC, the server is able to offer ODBC data to any OPC/DDE enabled client".
That is, it is extracting data from a database, and presenting it to an OPC client (program that is using information) as if it were coming from an actual "live" device. The "simulation" aspect comes in that the data simulates a machine by playing back recorded data out of a database.
It wouldn't be a very good machine simulator in the sense of creating an interactive simulation on its own though. It just plays back recorded data at a set rate rather than responding to different operator commands.
If however you didn't have the real field device (or couldn't otherwise use it), but could create a data set which could be used for testing purposes, you could record the data into a database and use the "simulator" to play the recorded data back while you debugged your application. When the real field device was installed and working, you could replace the data simulator with the real Modbus OPC driver and hopefully your application would be already debugged. This is also good for creating test cases that would not be encountered under normal operation.
Your overall testing plan sounds good. Get each piece working correctly individually before adding them all together. I would suggest however be sure to make some sort of integration test early in the project to make sure that you can get the OPC server to work with ASP.
I know this sounds hard nosed, but a 3K line "simple" example is where we're headed for the future. I've been telling people for a while now a that a thorough understanding of VB, or whatever language of the day is ruling the roost, is going to be as necessary for a controls engineer in the future as an understanding of electrical polarity has been for the past half century. In the 1930s you could get by with 3-15psi and not really know anything about "all that electrical stuff" whereas today you can know little or nothing about 3-15psi but you sure better understand 4-20ma. Even today you can get by without really understand data, but not very well. (I said "get by," not "be a star.") But in fewer years than most of us care to admit, complete understanding of the program code is going to be as necessary as being able to look at the ladder in a PLC to see what needs to change to implement the new feature of the week. It's just coming whether we like it or not, so we move forward or we get left behind.
The biggest trick is getting the operations people to internalize the fact that all this added functionality they want comes at a price of complexity, time, and money. Honestly, I've seen operations guys who think that just hooking up a CAT5 cable to the HMI will magically connect the line to the ERP system.(I remember one guy in particular who just couldn't understand that I wasn't trying to "hide it" from him. He knew that IT had "hooked him up" and he wanted the line to run based on orders.)
That illustrates nicely why there needs to be an abandonment of the current model of total incompatibility. The owner has some right to expect that he _can_ tie things together without throwing all his equipment away and buying new or doubling his investment with band aids and converters and bridges, etc. I think PC automation will hit this point long before proprietary hardware, to their peril. It may well become much more important than the PLCs advantages. Already people are willing to use garbage because it's connectible garbage.
Think about it. :^)
The current model must change (my opinion). The system must accept change (others opinions) -- this change will be in the order of incompatible processes defined and resolved (a huge task). Who knows where the next "Dick Morley" will appear to resolve this problem (or opportunity) or part thereof. People will always try to improve the converters and bridges with limited success while the project lacks the overall concept of where the future (or one of them ) should be.
I cannot think of a solution to any current owner of equipment other than pray (and wish for future uniformity).
cww, How long have we been hearing about the inevitable death of the PLC and here we are still buying them in bulk. I just upgraded a system in our plant because the PC-Based HMI was an old DOS based system that we could no longer get support and spare parts for, etc. The PLC on the other hand was a PLC5 which after 15-20 years is still as functional and useful as the day it was installed.
In reply to "Sonofaforester" - Ten years ago I was arguing on this list in favour of your point and Curt Wuollet was hammering away on the opposite point of view. I saw the problems of unreliable and expensive software and hardware as being unsolvable. I can see now though that I was wrong, and the problem is one of attitude and belief rather than technology and economics.
The increasing use of networked I/O means that hardware is no longer tightly bound to the old style PLC rack so the old style PLC CPU loses that inherent "lock-in". Low end "shoe box" PLCs with integrated I/O will probably still remain attractive in simple tasks. For more complex applications though, once you separate the conventional PLC CPU from its rack however, you realise that all you really have is an expensive proprietary computer.
PC hardware is available on the market now at a very low cost that looks very attractive for reliable industrial use. You just have to realise that a "PC" isn't necessarily the same thing that sits on your desk. Just because you can't play video games on it doesn't mean it isn't a PC. Once you also realise that the software you need to run video games isn't necessarily the same as the software you need to run production machinery, the problems start to look more solvable.
I don't see PC (computer) based automation simply replacing conventional PLCs one for one in the same task at this time. Rather, I see them coming into use in doing things that PLCs do poorly and then taking on the logic solving functions of the PLC as an additional task. Exchanging information and interoperating with the rest of the enterprise will become more and more important as time goes on. Being able to write ladder logic (or the rest of the IEC languages) will be only a small part of what an automation programmer will be expected to do in future.
I mentioned that we were arguing this point ten years ago. Dick Morley (considered by most people to be "the father of the programmable controller") said in these discussions here "I guess that the original concept of a PLC is that it is programmed with proprietary languages with proprietary tools and controls I/O through a proprietary protocol or bus system. It was even then a computer, but was not called that since it might scare off the user base, since they were not very 'computer literate' at that point".
I think that times have changed, and we need to be prepared to change with them.
After a conversation I had with my teacher he told me that I don't need to control the OPC Server on-line. All I need is to retrieve the data from the server and store it in a Database.
Is it possible to create an application to store the data from the server to a db and to displayed it in a web application?
In reply to Leonidas Kallistratidis - You said your teacher told you that you "don't need to control the OPC Server on-line". I take it from this then that the proposal is to record the data into a database on one computer, and then
at a later time copy the database to the computer with the web interface? If this is the case, this sounds as if the project objectives have been modified quite a bit.
Your original description was to exercise *control* via the web interface, which implies a two-way exchange of data. The new description seems to be just to record some data, and then read it back using a copy of the database
at a later time on another computer. This is more of a monitoring application using historical data rather than controling something.
If this is the case, the modified scope sounds possible. It is however a different project from the one you originally described. Logging data to a database is a routine application. Reading data out of a database and constructing some simple historical reports is also routine. For the former, KEP may have some useful examples. For the latter, there are numerous books and on-line references on constructing web applications.
I assume your data collection application would record data over a period of time into the database. You could adjust the dates which are recorded to simulate data being collected over a longer period time than the actual collection period. A simple example might be to record the air temperature outside your window over several days into the database.
The web application could then turn this data into some form of reports or graphs (e.g. a graph of temperature over time). The period of time used for the reports could be selected by the user.
The basic technology being used will still be the same. The data won't be "live" because you have to manually copy the database between computers. However, for educational demonstration purposes, that is not of major
I tried a simple Demo in ASP.NET/C# Example with the KepServerEx 4.0 an it runs well.
We have changed the subject of the project.
The Master Generator controls devices like switches, lights, electrical devices, ect...
What I need is to store in database data like "When the user switched ON a device and for how long". This data must be shown on a Website.
So OPC DA is not needed. Are we talking about a HDA now?????
If I use a web app to commmunicate with the remote DB and a ODBC Client to transfer data from and to OPC Server located on the same PC, you think it would be very hard to develop? Is there any easier way????