Sign in to follow this  
Followers 0
valerio81

SCADA: VB.NET solution

16 posts in this topic

Hello everyone. I programmed lot supervisions with many kind of SCADA (WINCC Flexible, Citect, Wonderware, Cimplicity, CX-supervisor) and in the past I tried to do something simple with VB6 and Omron PLC, through CX-server Lite Now i have a standar plant to do (2-3 plants now, other in the future) and I would like to try something like VB.NET (to reuse code and dont spend money for lot of licenses) I read that lot of supervision are done with this instrument, or with V++. Any advice on how to start? In example which product is the best, how to learn to use it,some example and manual. I know a bit of basic and C++ and i suppose that can be helpful. The 2 things important are that i need to work with a SQL Express DB and with an Omron PLC. I accept any kind of advice, of course Thank you Valerio Edited by valerio81

Share this post


Link to post
Share on other sites
This might sound like a rant and it probably is, but trying to do pretty much anything with anything dotNET is an exercise in frustration unless it happens to be supported within the closed object model of dotNET. In a lot of ways, this is more maddening than even trying to write desktop applications in Javascript, since a web browser is another great example of a closed object model. One thing to keep in mind: Anything.NET is meant to communicate ONLY with SomethingElse.NET. The object stack is horrendous when it comes to interfacing to anything else. Essentially the object stack is about 99% a closed world which makes it almost impossible even to call Microsoft's other object stack (COM). The most common method of communicating to PLC's from a PC would be using the COM/DCOM object stack. DotNET was specifically intended to replace and not interoperate with the DotNET object stack. So until OPC UA becomes real/finalized, there's no decent, clean way to do it. It can be done but it's painful to say the very least. This is the reason that VBA and VB in general continues to be supported throughout the HMI/process world. Microsoft went off and created something that they don't even support in reality. Don't believe me? After 10 years, why is it that Microsoft's flagship product, Microsoft Office, STILL doesn't support dotNET. The object stack of Microsoft Office today is STILL VB/VBA. Microsoft has made no effort whatsoever to move Microsoft Office onto a dotNET object platform. That's saying a lot when Mr. Softy doesn't even support dotNET. Second, dotNET is not supported on ANY other platform than Windows. It is totally, completely nonportable. I mean, sure, the CLR is an "open standard". But imagine taking C or VB and making all the libraries off limits. What do you have then? Effectively, nothing. Microsoft did just that...they released the virtual machine language (the object code) but locked down the libraries. So at this point in spite of the best efforts of the Mono folks, dotNET is simply not supported unless you run Windows. Want to run your code on a Mac or Linux some day? Nope, can't do that. Worse yet, there are something like almost a dozen different versions of dotNET at this point. ALL of them are incompatible with each other, even in the upward direction. So if you write something in dotNET 1.5, not only will it not work correctly on dotNET 1.4 but it won't work on dotNET 1.6 either! You're locked in...and your users are stuck with a 500+ MB download/file to install the EXACT right dotNET version that you have if/when you try to install your software on a different machine. I can't tell you how incredibly dumb this design is...especially when the major reason for writing dotNET in the first place was to avoid all the problems with the COM platform and to try to compete with Java and some of the other object stacks out there. Third, dotNET is an incredible trap for your wallet. Need a library for say database work? No problem, open your wallet and buy another library. Need it for interfacing to a PLC? Same story. What if the library happens to suck, which is what usually happens? Tough luck...you bought it, you're stuck with it. Since only 1 out of every 10 libraries doesn't suck, plan on spending 10 times what you expect to pay to find a decent one that does what you want it to do. Don't expect those magazine/internet site reviews to do anything for you either. The magazines are making money off it too so they just take the press releases from the library retailers and rehash them into a story. Don't forget that dotNET comes with plenty of licensing and security, too. So you can plan on paying various royalty schemes in order to be able to install the required libraries on your end user's machine. Ca-ching, ca-ching, ca-ching. I highly suggest that you consider other paths before going down the dotNET trap. The easiest way out is to simply sell the programming based on a specific HMI and have the end user simply buy the HMI license (or sell both). The cost will be about the same and you won't spend your time doing a lot of code that is essentially automatic inside the HMI itself. Some of them (RS-View 32, iFix, and Cimplicity PE) already support VB/VBA if you really need custom programming. The easiest way to do PLC/PC programming other than using an off-the-shelf HMI is VB. The OPC protocol stack is specifically written in a COM/DCOM model and works best with that environment so consider VC++ or VB first. If you are willing to sacrifice the easy OPC interface path (and this is not an all or nothing deal), Java is just as non-PLC friendly (ie, you can get an interface library to go from Java to OPC but there are still some strings attached to doing so) but it is much more mature, the major libraries don't suck, it was specifically designed for "write once, run everywhere", and you won't get nickled and dimed to death for libraries that some 19 year old kid hacked overnight and turned into a product after buying the book "sell your crap on eBay"...basically everything dotNET promises but never delivers. And it has not one but two great IDE's (netbeans and eclipse).
1 person likes this

Share this post


Link to post
Share on other sites
Wow, that’s many words about how poor the .NET platform is. I have to agree with you on almost everything regarding the COM communication... But I can’t agree with you that Java has two great IDE's... I can’t develop java anymore after working in Visaul Studio, Netbeans and Eclipse is so dam slow working in. Anyway back to the subject. If you still want to make a HMI in the dotnet world using a OPC Server check out Kepware ClientAce. It’s a .NET API that handles the OPC communication, I’ve been using it for a couple of OPC clients and it works real good. Sure it’s not free (just as paulengr says, nothing is free in the .NET world), $995 + $295 (1 Year Service Agreement) but I think its worth its price. The API supports C#, J#, and VB.Net. You can read more about it here... http://www.kepware.com/Products/OPC_ClientAce.asp Regards /Edmund Edited by edda

Share this post


Link to post
Share on other sites
@ paulengr : Yes , this definitely is a rant . I'm not MS fan boy (more like Python fan boy), but if your target platform is Windows I find VS and OPC very easy to use. So far Interop ( .NET <=> COM ) worked for me every time - have quite a few projects installed and running for years. I don't know anything about Omron though - my place uses AB-Rockwell almost exclusively and I don't use VB.NET but C#. And I definitely would not like go back to VB6. @valerio : If you are still interested send me a message.

Share this post


Link to post
Share on other sites
The .NET platform is a very powerful platform with a huge base of classes that make developing software very fast and easy once you learn it.I have developed a group of components in VB.NET for building HMIs including some drivers. The project is named AdvancedHMI. Once an HMI is built with it, it is a completely stand alone application that does not rely on the outdated OPC-DA drivers. The application is open source and you can get the code here: https://sourceforge....ts/advancedhmi/ Also if you search youtube, you will find several tutorial videos on how to use it. Currently there is not an Omron protocol, but their protocol is not very complicated.

Share this post


Link to post
Share on other sites
Paul - I can't disagree with anything specific that you accuse .NET of being or not being. However, the OPC Foundation and a disproportionate number of Industrial software vendors have invested too many of their eggs in the Microsoft basket - including the .NET migration. I guess they've felt too invested to make any changes based on lessons learned. For that reason alone, .NET could make sense for industrial end users who want to write/roll their own system. The OPC-UA reference code was written in .NET, but the standards were defined in a platform/library independent manner. Ignition, for example, implemented the entire stack purely in Java. There's no reason that it couldn't be done in C++ or any other language (hint, hint, Sourceforge enthusiasts). As to the Java thing - you're right about the language being "non-PLC friendly" - unless you write your own "module" that runs on the Ignition platform, which provides significant hooks to PLCs, databases, and visualization. The OPC-UA server is free as is the platform to use. That's a lot to leverage for a Java programmer. You just have to be comfortable knowing that the platform is designed to host "for money" visualization, historian, and reporting plugins, which is how Inductive Automation makes their money to develop the product.

Share this post


Link to post
Share on other sites
VBA is still included in Office because .NET never was meant to replace VBA, it was meant to replace VB and C++... However, more and more software projects utilizing VBA is looking to replace it with .NET. Eg. the developers of CitectSCADA are looking into replacing VBA with VB.NET or C#.NET in V.8...
1 person likes this

Share this post


Link to post
Share on other sites
Comments can be really amusing sometimes... Anyways, .NET world is not all doom and gloom, and VB.NET is not a bad candidate for an HMI implementation. There is a .NET-based product called CSWorks that can do the database and PLC data exchange plumbing for you and lets you focus on the UI part. It supports SQL Server Express and CX Server OPC (both scenarios were actually tested). There are educational videos on YouTube that show and . Samples are in C#, but you won't have any problems translating them into VB.NET if you have C++ experience.

Share this post


Link to post
Share on other sites
.net was for Web Based applications......its a ridiculous platform for a standard HMI. And you don't need a license to create an application in VB and install it across multiple machines. Its application and interface is better, and is and should be, the programmers choice. Want VB.net? good for you. You just increased your development from 1 week to 6 months.....guess your workload is light and you have to justify your salary. next you'll want to develop in C++. sheesh........

Share this post


Link to post
Share on other sites
Have you actually tried developing on the .NET platform? Firstly, it's not only for web applications - it works perfectly for desktop applications as well. You also won't need any license for any of the .NET platforms, you may even get the IDE for free! (Express edition) VB is practically dead, it doesn't even work on Windows Vista (without messing with the registry and adding old system files, if you can find them)! If the development time increases from 1 week to 6 months by moving forward and choosing the newest technology - then you really should find something else to work with... (VB.NET is not that far away from VB6) After I moved from VB6 to C#.NET 3.5 both my productivity and knowledge increased - fast! I would like to know which IDE you use for VB, because if you think the interface is better than for .NET - you have to be using something else than me!

Share this post


Link to post
Share on other sites
I use VB6.....and from what I've seen, yes you can develop .NET for desktop app's. there is however a lot more overhead. And the entire .NET environment was not meant for standalone desktop applications. (that's from Microsoft) It was meant for developing Web based, internet and multi-node applications. In this its significantly better then VB6. But cumbersome as all heck. That's like saying C/C++ is a good language for development of anything.

Share this post


Link to post
Share on other sites
Well, C/C++ is actually the only language you can use to develop anything, for any platform (almost)... I really can't understand how you can find .NET more cumbersome than VB6, what do you use it for?

Share this post


Link to post
Share on other sites
well nearly everything. And as for C/C++ being 'portable' it is and its not. It was never developed to be portable at this level. K&R simply needed a small compiler to do some things....'C' is born. It was portable as it didn't use (or was not designed to use) any h/w specific drivers. So it theoretically would work across different platforms. In practice however, no one wanted their Windows screens in 320x200 resolution in black and white. And the h/w was so different that the coding became too h/w dependent even when they started to use h/w specific drivers. Now as to development.....the worlds managers somehow decided everything needed to be C as is was portable and would save all that coding time. As for 'C' itself, its a terrible, terrible language for developing high end applications. Because it was never intended for it. First its an untyped language. So the compiler makes no difference if you decide a string address in memory is a code pointer, or a pointer to a number or anything else. Its extremely prone to syntax errors because of the same thing. Try that in Pascal or Basic and the compiler will catch the error. You can do it in C now by turning on the type checking. But then you're making C a typed language, which is exactly what its not.

Share this post


Link to post
Share on other sites
Where do you get this from? K&R never developed C, they wrote a book about it (and maybe did some tweaking of the syntax)! C was developed by AT&T for UNIX and later implemented as a standard by ANSI. I will agree that it's a more difficult language to use, but no other language is as powerful as C/C++. But I don't personally use C/C++, I primarily use C# and PHP VB6 is officially dead, Microsoft ended the extended support period in March 2008 and the designated successor was Visual Basic .NET. That should be enough for anyone to stop using VB6 to develop new applications, as I mentioned earlier - it doesn't even work on new computers! And then of course you have all the limitations, how do you make a VB6 application multi-threaded? You can't... But you still haven't answered my question, what do you use it for?

Share this post


Link to post
Share on other sites
Well, C/C++ gives you enough rope to hang yourself, but that is also what makes it so powerfull, at least for low level stuff. I don't know what it has to do with putting together a HMI application, though. I would go for using the .NET framework if you want to knock something together in a reasonable amount of time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0