|
.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.
|
|
|
|
|
I made some changes... check it out now
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.
|
|
|
|
|
Seriously?? This is your entire article:
IntouchToolkit = New Intouch(0, 0)
IntouchToolkit.WriteDiscrete("Valve1_Open_Req_MMI", 1)
There's got to be more to this than two lines of code. Your text is still covering next to nothing about the library, if you wrote it, how it was written, use cases, examples, ...
|
|
|
|
|
I edited it... you can tone down the attitude a couple notches though. I dont mind a little critiquing and welcome it.
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.
|
|
|
|
|
All you had to do was read it and ask yourself a question: "If I knew nothing of what this was talking about, would I understand this?". It's a simple question and is what they start teaching in middle-school English and Composition classes.
Do you know how many times a day I read an "article" that doesn't pass this one little test? Or find "articles" that are nothing more than a code dump? I'm not talking about just stuff submitted to CP. Sadly, I mean all over the web. It seems a large portion of people willing to "share" their knowledge don't because they think that posting a code snippet is enough to convey concepts and designs. You don't see Newsweek or Time managize writing an article by posting a single picture, do you? There's a reason for that, and it's called "context." Writing a technical article is no different. Just posting a code snippet does not convey the contexts in which it is used, nor how and why the design it implements works. Too many times I see "This code does (a one sentance description of a low level item)" and that's it. How does this piece fit in with the overall design? Better yet, where is the discussion of the overall design?
In your case, you say add a couple of .VB files to the project, but then you don't go into anything about what's in those files, what they do, or what they are used for. That's a large chunk of the meat of your article and it's just not there! Right now, all your article says is "This is how you use a couple things in my library..." That's it.
You also might want to go back and check your spelling...
|
|
|
|
|
...it's pretty much a code dump. You need to explain the code and concepts rather than just dumping them on to the page: if you removed the code there is nothing left!
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
|
Long time since I mentioned those terms, though I have to say doing those sorts of things for a proper engineering firm, sure showed me how to program, far better procedures than in some of the leading finance industries let me tell you.
Arhcestra used to be my boy, along with Rs5000 Allen Bradley PLCs.
Sacha Barber
- Microsoft Visual C# MVP 2008-2010
- Codeproject MVP 2008-2010
Your best friend is you.
I'm my best friend too. We share the same views, and hardly ever argue
My Blog : sachabarber.net
|
|
|
|
|
I mostly write SCADA stuff from scratch in VB .NET. From time to time I use WOnderware, Proficy or iFix, and I hate all three.
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.
|
|
|
|
|