|
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.
|
|
|
|
|
I thought so too, when I first started working with WinCC. Their documentation is certainly not helpful, but then I compare it to WW's, and, well, what documentation? I asked around the office thinking I was missing something, but they don't know of any, either!
I will admit that WinCC has a daunting learning curve. But when it comes to dropping in a custom .Net control, I LOVE WinCC over WW. Unfortunately, it's the nature of our business that we have to make our controls work in various consumer preferred HMI hosting environments, so I have to code to the lowest common denominator. So, even though I don't need all the interop crap for WinCC, I still have to code it because someone will need to drop it into WW sooner or later.
This peculiar working environment, where the next user will likely have a different PLC investment than the past six, is why we have a strong preference toward OPC. Write once, use many is much preferred to maintaining code for over a dozen drivers. It makes it especially nice when the hosting tools (WOnderware, WInCC for example) already include an OPC Server built in. But we're not the only vendor that works this way, so it will be a long, long time before OPC breaths its last breath.
Thanks for the offer of help. The biggest problem we're having is proving our code, since we can't get hands on a trial version of WW! But the thing is, I'm working in the other direction. Instead of writing programs to access WW stuff from Windows, I'm writing Windows programs to run inside of WW. If anyone reading this is intrigued by the idea of using .Net UserControls inside of WW or WinCC, let me save you man-weeks of effort by pointing you to Microsoft's InterOp Forms Toolkit. (Google or BING will give you the link.)
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I have writen a framework consisting of a Client, Server and Config program. All is .NET. The server does all of the communications with devicces and the Client gets point data from the server with this set up I can have multiple clients but one communication to devices. I currently have about 54 PLC drivers , including MODBUS and other comm protocols. All is native .NET, use what ever controls you want. The server only updates the clients on the points they need and alarms as they change, not every scan. By doing this I have boosted efficientcy to 3 times that of WinCC, iFix and WW. Oh and I am 25% of the price.
|
|
|
|
|
I also do OPC but why... I have written .NET based drivers for most PLC's out there... Why have something running in the middle between the software and the PLC... OPC's days are numbered. Its all activeX and com. But have written OPC related stuff in .NEt if you want it I will give it to you.
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.
|
|
|
|
|
Not so much with the ActiveX, Com/DCOM stuff no more.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
Code comments do not make for a good article at all.
You have to discuss the topic at hand, not just breeze over it with "This code does this", then dump a section of code.
|
|
|
|
|