|
Just copy the 2 Dll's to your project folder and it will work.
|
|
|
|
|
Good for Wonderware Profetional
Thanks
|
|
|
|
|
I'm just overjoyed to find ANYTHING on here related to programming for automation -- it's so underrepresented.
Ok, since this is posted here as a comment anyway, I'll edit this and add some comments.
Other users can't explore this unless they already have Wonderware (WW) Toolkit and would also likely need some type of PLC running to test it. You might want to create a section to talk to the prerequisites for running your code. If you know of a trial version of WW they could experiment with, that would be a great link. Anyone? (Someone from Invensys feel free to comment here!)
Also, you might want to walk through the whole form, even if the whole form just displays a textbox and a button, using the form to read from one tag and write to another. I do have to ask, though, since Wonderware has an in-built OPC server, why not use that? If your wonderware SCADA is ever replaced, the amount of code changes to your form might be as little as zero, just pointing to the new OPC server.
modified on Tuesday, August 24, 2010 1:02 PM
|
|
|
|
|
first off Thank you for the vote. I know its not a perfect article but it is my first. I do not know of a trial version of wonderware, or if one has ever existed.
You need wonderware, but you can read and write system tags so a PLC isn't a requirement to run the code. The code just reads and writes tags regardless if they are a device or system.
as for the walk thru I will add to this part, I see your point, and agree.
I do not like to use OPC, because it is dying. I unfortunately have to use it from time to time. Because of its use of COM and ActiveX it has issues on anything newer than XP.
As for OPC angle, then it wouldnt be an article on wonderware anymore!!! just kidding, I will probably write an article on OPC and some others just because Automation is under represented here. I just wanted to show how to interact with wonderware directly without adding a $900 driver from Kepware, Matrikon, etc...
Plus this site has 4 articles on OPC
Give a man a fish, and you feed him for a day
Show him how to use the internet and never have to deal with him again.
|
|
|
|
|
The thanks is mine for writing the article. I'm working on creating ActiveX (InterOp, not truly ActiveX) control to run inside of Wonderware, and I'm quite sure they don't have any trialware. I just think you might want to warn the non-automation or beginning automation reader that this is a requirement.
You may want to read up on OPC's Universal Access (UA), which is capable of running on Unix (and doesn't require COM/DCOM). The COM/DCOM was overcome a few years ago, even if you don't use UA. The recent .Net implementation has left OPC Foundation chewing their leg off, since even the specification requires a prohibitive fee just to read it, but it's not the first product we automation engineers have had to learn without documentation (Wonderware, for instance).
And you don't need any driver -- it's built into Wonderware. Any tag you have defined in WW can be exposed via WW's built in OPC Server. And if you walk through how to set it up in Wonderware, it would be an article on Wonderware! But I wasn't recommending a change, just wondering the reasons for your decision.
I'm guessing from your responses, though, that you weren't aware of this option. That said, if you do explore it, you might want to add your experiences onto this article. I suspect you'll be pleasantly surprised. (I haven't setup OPC Server on WW, but I'd be happy to help out where I can on the code.)
One of the greatest things about using Kepware or Matrikon is that they DO offer trialware versions. Kepware provides drivers that you can download for free that expire after two hours. It's perfect for experimenters.
ReallY? Four articles? (And you said OPC was dead! ) Seriously, though, that's four more than I was aware of.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I didnt say that they were four recent articles and 2 are just the spec nothing much more.. i don't like OPC. Most of my work is I write a .NET based driver and read/write the PLC directly nothing in between, and that is what I did here with wonderware, was read and write the database directly.
In this day and age why use ActiveX.. its like taking a step backwards in technology.. I also have driver for Linux/Unix, but all my windows drivers are pure .NET, no activex.
|
|
|
|
|
I still can't escape ActiveX because WonderWare doesn't truly support native .Net UserControls. In fairness, the controls aren't really ActiveX controls, but .Net Controls with embedded InterOp commands to mimic much of the same functionality as ActiveX controls (enough to be supported by WonderWare). Again, though, I'm coming at this from the other side of the fence, I believe. At least in this article, you're accessing Wonderware from the OS environment, and I'm creating embedded controls to run within the Wondware environment. (If you know of a way to drop a native .Net UserControl directly into one of the WonderWare forms, I'd love to see that article!)
When I'm writing an external app, I try to avoid tying myself to any custom packages at all if I can. Here again, I'm coming at this from a different perspective. I'm writing an application that needs to run at a hundred different locations, each using a different SCADA or even PLC, and I don't want to have to perform significant modifications to my code to adapt it to WinCC versus WonderWare versus hosting in a native Windows Forms stand-alone application. If I were writing an application to run in only one specific plant, using one specific SCADA and one specific manufacture of PLC, then I'd likely be doing it solely for that tool set.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I'm also working from the "other side of the fence". I need to create a control that can be embedded in the Wonderware environment. I understand Wonderware supports ActiveX controls. I don't have any experience with building ActiveX controls and I'm having trouble finding any concise information on how to do it.
KnockNRod, would you be willing to let me touch base with you about how you're going about the .Net controls with embedded InterOp commands to interact with Wonderware?
I'm also working in a steel plant on an automation project. I need to be able to get high speed, high resolution data displayed on a trend in a Wonderware screen. We have stand-alone applications in C / C++ that handle the high speed comms over TCP/IP with no problem. I'm thinking of building a control (C++, C#, whatever) in .Net that will be able to handle TCP/IP comms and have the control displayed in Wonderware.
Any tips are much appreciated!
|
|
|
|
|
This article was for writing VB .NET apps that will communicate with the Wonderware database not creating Wonderware components. I may write another one explaining how to do that. I have only done it twice.
|
|
|
|
|
I'm actually trying to write my own article on this. There are two of us trying to rewrite our HMI to better support embedding within WinCC and Wonderware's InTouch. Unfortunately, I'm the WinCC guy.
To get started, download Microsoft's Interop Forms Toolkit. It won't work on the express versions. Read the related documentation. It adds two new projects to your project list, and if you want to go this route, you'll want to use the Interop Control Library project. Multiple controls haven't been tested yet in our Wonderware project, but I have no reason to suspect a problem.
Since you're working with C/C++, you have the option to create an actual ActiveX control, which Wonderware supports.
I'm having some trouble working in the article submission tool here, or I'd have someplace to at least send you. IIRC, InTouch does have some pretty serious limitations on what can be displayed in terms of colors. For this reason alone, you may have to rethink the notion of hosting it there.
Something to consider regarding data access. If you create a series of controls to embed independently, each control has to handle its own data independently. Using sockets, you drop 30 controls on one page, open that page on 10 clients, and you have 300 socket connections. I believe the intent was to expose public properties in the embedded control and use memory tags (or PLC tags) to supply data to those properties as the mechanism for getting data into (and out of) these embedded controls.
We are trying to create a control library and use Interface objects (and contracts) per control to define a Data Access Layer (DAL) within the control library. Using the Singleton Pattern, we are able to pass a reference to this DAL object around and share data among all of our controls. This method allows you to do some more interesting solutions: Create a System Service that communicates via IPC to a proxy object that provides all the interfaces, replace the DAL object with an unlimited number of concrete classes which implement data collection using things like SQL Server, Oracle, Sockets, various combinations of each, or even SOA services. Our level 2 code provides most of the data, and it's written in C/C++. As a result, WCF isn't supported directly within C/C++, but if that gets migrated to C# or VB (we still have to support VMS, so that's not likely), then we could also use WCF to service these interface contracts.
Hope that helps. Keep an eye open for a new article on here for embedded controls from me! I'll take whatever feedback I can get. (Update: It's by no means complete, but here's the link http://www.codeproject.com/KB/miscctrl/HMI_Embedded_Controls.aspx)
Without darkness, there are no dreams.
-Karla Kuban
-- Modified Monday, September 6, 2010 3:28 AM
|
|
|
|
|
Why would you want to embed your HMI inside of WW or WinCC... seems messy. Most of my HMI/SCADA projects I have my server running on a Windows or Linux box (I have three versions, Windows 32 and 64 bit as well as a redhat enterprise version).
From the server I do all communications, this includes Wonderware, PLC's, Robots and any other devices. From there every desktop client will get its data from the server, now this will stop your communications issues. Now if 10 Clients all request points from Wonderware, they all get queued up and done via the server then the tag values are sent to the clients.
The server handles tags on a subscription basis. each client subscribes tot he points it requires and the server pushes the tags when they update. This cuts down on the traffic by resending the same value every scan. The server updates all points that are subscribed, has an alarm associated with it or set to always update.
|
|
|
|
|
There's so much more you can do with a full-blown windows application (or Linux application), than what I can do inside of a SCADA, but we don't create HMIs for ourselves, we make them for our customers, and their greatest depth of continuing, in-house support may be within a specific SCADA system -- an investment they intend to protect. We don't feel like it's our place to dictate to our customers; instead, we prefer to accommodate our customers' efforts to build on whatever depth of in-house expertise they have available.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I don't dictate what customers will use, I just show them if you use wonderware you're gonna pay 50,000 a year in support that is less than stellar. Wonderware, WinCc and iFix will dictate to you what you can do. That's why I wrote my own, I never say oh, it can't do that, I just build it. I run cheaper (about half), I run faster (130,000 tags per server), and can do a lot more out of the box than wonderware, iFix or WinCC. I spent about a year writing my scada server before ever showing it, since than (about 10 years) I have converted about 150 wonderware apps to my system. I currently have my stuff running 8 major pipelines, 3 tank farms, and even a fertilizer plant. Everyone running my stuff also says that I actually give support, as compared to the dismal stuff Wonderware calls support.
I wrote my own because I got tired of lack of support from Wonderware, iFix and WinCC. I was spending at one time 100,000 per year with wonderware and still took them a week or so to give me an answer which was usually, we dont support that. I got fed up.
|
|
|
|
|
Ok, nix my previous comment regarding color limits. It turns out that's a limitation of WonderWare's in-built controls. That same limitation does not extend to embedded controls, so this is a very good reason why you'd want to supplement WonderWare with an embedded control.
Again, I'm not sure how much I can help, since I'm the WinCC guy. Our WonderWare guy just took off to Thailand, too. But I can tell you the two greatest surprises we've had so far is the lack of support for embedded controls in WinCC which claims it supports them; and the amount of success we've had with InterOp controls in WonderWare which claims it doesn't support them.
I'm convinced that this will turn around in time. I'm just not sure how much time.
In the off chance that you're working with bitmaps, I'll share something we discovered only by accident. We create a run-time isotherm image based on our simulated temperatures on a cross-section of the steel inside our furnace. We have an MxN matrix that calculates heat transfer (and temperatures), and we can display this as an isotherm. We build this by making an MxN bitmap and set the pixel colors manually, then use GDI+ mixing to quickly blend those colors. If you try using NearestNeighbor shading, it's supposed to expand the pixels into solid-color blocks, but you'll find they're offset by half a block. (This same offset exists regardless of shading method, but its pronounced in NearestNeighbor.) To correct this, Dot Net has a HalfPixelOffset that shifts it back and renders the drawing correctly. (I'm not positive about the name of the property. If you need me to, I can look it up.)
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
.NET Controls using InterOp are the bane of my existence. I have this model of laser I have to use from time to time and I have to use interop with the activex, and it breaks things. I try to avoid it like the plague, and only use it when I have no other choices.
I deal with about 150 different drivers from every PLC imaginable to every HMI you can dream up. I don;t know how you plan to write a single application to handle every instance, with every different HMI and PLC combination... do what I did.. just write your own framework and drivers and just toss out the wonderware's and the WinCC's and just run your HMI/SCADA. By doing that you now can handle every situation.
I have an HMI/SCADA server written totally in .NET, supports 150 PLCs, as well as Modbus, Controlnet and devicenet. Here is the kicker, I can do it cheaper than WW or WinCC. and I can handle more points on a single server than WW... I have a site now with 130,000 tags on a single SCADA server. I am in the process of converting the system to Linux, and making a version of the client that controls can be added without visual studio (components added at runtime).
|
|
|
|
|
Interop is a pain. There are probably more people who understand quantum mechanics than InterOps. Microsoft's InterOp Forms Toolkit does add a LOT more stuff than you need to make it work in most cases, but the fact that it builds these into the project for you does ease the burden quite a bit. And there are a fair number of folks willing to help you cure or avoid the warts interop causes.
We're not trying to deal with all 150 different versions. Sorry, didn't mean to imply that. Most of our customers that are requesting that our Level 2 HMI be integrated with their Level 1 HMI are running either Wonderware InTouch or WinCC. We did have one using Factory Link, but we already know the problems there preclude a one-size-fits-all, so we made the strategic decision to not even try and address that in our design. Even in that scenario, though, packaging our HMI as a set of stand-alone controls does make it easier to pull out pieces. These pieces, then, can be embedded into a VB6 application, where a true ActiveX control can be created, which does work in Factory Link.
PLC access is a bit different. Not all of them have drivers supported by OPC, but I suspect that all the ones that work with WonderWare and WinCC do. Because WinCC and WonderWare both include an OPC server as an in-built part of the package, you can at least avoid writing in-house drivers for all the PLCs.
In this case, the drivers are provided by Wonderware and WinCC, but you've got to be willing to write controls that make use of OPC calls. If you've got to access a different manufacture of PLC for your controls than what you intended to support by Wonderware, you will have to purchase another driver from Wonderware to use by its OPC server for accessing that additional PLC. I understand WinCC is a little better about licensing in this area, but I haven't had to do this, so I'm unsure. In fact, I haven't tried to even call into the OPC servers of either product, and one thing I've learned in my own project is that you can't take anything for granted -- if you haven't tested it, it probably won't work. (Public methods are and raised events appear to be dead in WinCC. I'm awaiting confirmation on the latter from Seimens. That last one may be impossible to work around since raising an event causes an out of memory error even if you try to handle the event between controls, although our hope was to program WinCC scripts against those events. If you're interested, I encourage you to also keep an eye out for my article.)
In short, you can't avoid eating the bitter pill in all cases, but you can at least design the coating around the pill so that it's easier to swallow. Of course, it's always our preference to do everything as a native Windows Forms application for exactly the reasons you mention. (I don't think we have the expertise or resources to create our own SCADA system, so we won't be leaving OPC anytime soon.) However, our customer's often have a deep commitment to a particular SCADA and insist we embed various amounts of our HMI within their system. I can't avoid it, but I can sure sweeten the pill.
Without darkness, there are no dreams.
-Karla Kuban
-- Modified Monday, September 6, 2010 3:35 AM
|
|
|
|
|
i have WW intouch 10.0 but i can't run this code, can you help me?
Did i must have wonderware toolkit to run this code?
modified on Monday, November 8, 2010 6:28 AM
|
|
|
|
|
I have done my share of automation, bus systems, communication protocols, what have you. But I was unfamiliar with wonderware.
So I read the title, the subtitle, and the intro, and still did not know what the article was about.
"Wonderware" was mentioned about five times, explained zero times. I had to turn to wikipedia to learn what your article is about; this is a major mistake. An introduction has to be a self-supporting invitation to read on, and not a mystery.
You should have given:
1) wiki: Wonderware is a brand of industrial automation and information software products, owned by Invensys Operations Management.
2) site: http://global.wonderware.com/EN/Pages/default.aspx[^]
Of course doing so would emphasize each of those contain more information than your article.
Sorry, I'm disappointed.
|
|
|
|
|
Thank you for the advise and I will edit the document accordingly. I am a good programmer just a crappy writer. Thank you for giving advise without an attack.
Give a man a fish, and you feed him for a day
Show him how to use the internet and never have to deal with him again.
|
|
|
|
|
NP.
You improve the article, I may re-read and re-vote.
|
|
|
|
|
Seriously, you've never heard of Wonderware?
I've been thinking about doing a similar write up on OPC and maybe even one on WinCC. Our company sells furnaces for the steel industry. Sometimes, our Automation group just gives the HMI a facelift. We're getting a lot more jobs lately to use SCADA systems to merge our Level 2 and Level 1 HMIs, so we're investigating compartmentalizing all our Visual Basic screens into ActiveX components so they can be easily hosted in a variety (Ok, just Wonderware and WinCC) systems more easily. (Yes, I know OOP/OOD etc and know this should have been done ages ago, but it is what it is.)
We were just talking about the inability to pass in an array and were wondering how to access external data sources from within a Wonderware hosted ActiveX control. I will say it might have been nice to see a little more to the article than this, but hey, it's a great start! For this industry, it's just amazing to see any article at all!
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
knockNrod wrote: you've never heard of Wonderware?
No, I hadn't. I have been involved in lots of automation and distributed (mostly embedded) systems for over 30 years, and have used things such as HPIB/GPIB/IEEE-488, RS485, I2C and some of its variants, FireWire, USB, and lots of CAN. And I am aware of a dozen others I haven't used, and I am sure there are several I haven't heard of also. In my view there are just too many solutions.
|
|
|
|
|
I just thought that Wonderware was one of the leading SCADA solutions out there. It's certainly one of the oldest.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
old, yes... leading well that's up for debate.. I write HMI/SCADA software totaly out of VB.Net war from VB .NET when I can. I have projects totally in VB.NET with over 130,000 tags on a single server... try that with wonderware. That and add tot he fact wonderware pricing... I know one company who pays 50,000 USD per year for Wonderware licensing and support, and they still haven't gotten help to move past wonderware 7.1 (10 years old). I don't like wonderware support because of lesss than stellar support experiences, graphics look like windows 3.1 era, and there are tooo many limitations with the software.I have figured out how to do everything wonderware can but in VB .NET, and often time better.
In a lot of places they use wonderware because somebody up the chain who doesnt use it and looks and the money spent on it and that why they use it.
|
|
|
|
|
WinCC is more of a pain to do than wonderware. I started interfacign with wonderware with DDE which was as fun ans self dentistry. With WWheap and PTacc dll's from wonderware it is now pretty painless. These are part of the Wonderware toolkit and are not supporrted by wonderware, but they wrote them.. oh well... The way I am doing things in this article is how I have 4 pipelines and 3 tank farms running. Using pop up windows written in VB.NET to extend the wonderware in a way to fill the gaps between the customer and wonderware's limitations.. Give me a shout and I can help you if you need it. I can even help with WinCc and iFix.
Give a man a fish, and you feed him for a day
Show him how to use the internet and never have to deal with him again.
|
|
|
|
|