Hi all,
I want to start to learn C++ for build some apllication on window Xp. I check few info on MSDN microsoft web pages but still have question.

- What is .NET framework ??? I see this expression everywhere! It is the new way to program in C?
- It is possible to communicate with plc for get some data (thru serial or ethernet). Do I need driver or soft package?

I know VB is more userfriendly but I earing C++ is more powerfull.

Thanks

G'day,
The .net framework (http://en.wikipedia.org/wiki/.NET_Framework) is a common set of libraries that .net languages can all use and a runtime environment that once a .net application is compiled it can run on.

>It is the new way to program in C?

hmmm... the .net framework is not restricted to one language (vb.net and c# both use the same framework).. but yeah, if you like, c# is an evolution of C/C++

>- It is possible to communicate with plc for get some data (thru serial or ethernet).
Yeah, to save a lot of hassle, build yourself something with an OPC client in it with source from here http://www.opcconnect.com/source.php

> Do I need driver or soft package?
Yeah, don't try and build your own drivers, get an OPC server like RSLinx or Kepware..

>I know VB is more userfriendly but I earing C++ is more powerfull.
I don't like to be too subjective on forums so I'll limit myself to this: VB is the devil. The new languages do take a little learning but you can do amazing things quickly... especially by taking the tutorials/labs/videos on msdn.

~Mike

There is nothing subjective at all about that statement. It is an honest objective undeniable hard fact.

dotNET is marketspeak.

In the mid 80's, CORBA and RPC arrived on the scene. These systems allowed programs to interoperate with one another in a common, defined way by exposing the programming interfaces to one another. You could programmatically access and use another application merely by making function calls to it and passing data (objects) back and forth. CORBA and Sun's RPC provided the mechanism for doing this. Implementations were even springing up on DOS and Windows PC's.

In response, Microsoft created COM (Common Object Model) to allow data to pass easily from one program to another for cut/paste operations. This model was eventually extended to allow programming libraries, "live" object connections...really any time that you need inter-application object communication. COM however had a LOT of shortcomings, too many to bother worth mentioning. Whatever the weaknesses, it was a viable competitor to CORBA and RPC primarily because it came as part of Windows.

Eventually even stronger object models came about. Perhaps one of the most powerful and successful is Sun's Java. Not the language itself but the virtual machine and the very powerful and extensive object library and support it provides, as well as the ability to "write once, run anywhere", and security designed right into the virtual machine itself. At first it was incredibly painfully slow and not even close to a competitor. But as of Java 1.5 (and especially more recently Java 1.6R10), it is lightning fast and can beat C++ for certain applications.

Meanwhile, Microsoft had incorporated COM into Internet Explorer...and, BIG MISTAKE. All the weaknesses, lack of security, etc., came roaring out and COM's security weaknesses became immediately apparent. Microsoft began releasing patch after patch, trying desperately to fix COM. In the end, they finally threw their hands up and went another route...

That route is CLR. Fundamentally, CLR is a virtual machine similar to Java. There are some differences between the two but the basic idea of a just-in-time hotspot optimizing compiler reading virtual machine code is at the heart of both designs. Interoperability similar to CORBA / RPC / COM is trivially easy since all applications written for the CLR virtual machine are talking the same language and run on the same virtual "hardware". Other than a few idiosyncracies, this is at the heart of the Java system. There is a constant debate over who has the better performance platform because both systems have certain attributes that make them more friendly to certain types of code, and I'm sure the debate will go on as long as the Java platform and CLR are popular.

Microsoft wrote a bunch of new languages for the CLR platform (C#, J#, etc.) but eventually went full circle and started writing compiler backends for standard languages such as C++ to compile into CLR code.

They also coined a new brand name, "dotNET" with the implication that everything is "NET centric", "NET based", etc...whatever that means. Just forget all that gobbledegook and realize that what you are talking about is CLR or "Common Language Runtime". It's not just a library however. It's a full blown virtual machine. The machine has been cloned (called the Mono project) but so far due to various limitations, many of the key libraries written on top of it for graphics have not been successfully cloned. The result is that the dotNET platform as a whole is limited to running on Windows-based systems only. So it lacks the portability and true open source nature of the Java platform or Perl (if they ever finish Parrot).

At one time, I'd recommend you learn K&R C. As in the original, high performance system. C++ just mucks up a perfectly good language, and ANSI C is where the language snobs got involved. However, since the performance "hit" these days is no longer very large and since they have an incredibly good, free IDE (netbeans), I've actually changed my tune a bit and I'd actually recommend that you learn Java. C++ is slightly different from Java but Java is much more portable and has incredibly deep and wide support libraries, especially for network-based projects.



You can talk to AB PLC's via either Ethernet or serial port. One of the annoying problems with this is that Allen Bradley saw fit to develop slightly different command formats for every single PLC family. The basic protocol is DF-1, and Allen Bradley documents this pretty well. You can also use "PCCC" to talk to all of them, even ControlLogix (though you have to encapsulate it inside a CIP packet). PCCC is a variation on the DF-1 protocol adapted for Ethernet. Documentation is kind of rough. Finally, most of them (except the SLC's?) support Ethernet/IP which uses the CIP protocol. The CIP protocol is extremely well documented by the ODVA but unfortunately at this point I have no idea where you can get free documentation. The ODVA used to publish the specs for free but now it appears that you have to pay thousands to become a member and a few hundred dollars per spec. for the CD's. However, enough code has leaked out that I've seen at least one or two libraries that you could potentially use.

I have successfully written my own protocol driver to talk PCCC in Python using just Allen Bradley's published documentation and Ron Gage's C++ code (no longer free but there are still copies floating around the Internet) as a template. It's not hard and works very well but it does take time. There are some other free libraries floating around the internet such as "TuxEIP" but for whatever reason, none of them seem to have quite the staying power of the much simpler Modbus and Modbus/TCP protocols with competitor PLC's. The easier way is to get someone else's library that is already written. There are a few free ones drifting around the internet. Rockwell USED to promote their "C library" for use with their own driver, aka RS-Linx. However in recent years apparently they have discontinued this. Instead, if you are working on a Windows PC (and only under Windows since it is based on COM, although there may be alternatives where say for instance the Jacob's ladder project duplicated the entire COM interface in Java), you can use OPC. The idea here is that the OPC protocol is a programming library with a standard interface. The underlying driver may be different for every PLC but all PLC's can be interfaced using the exact same protocol (OPC).

The merits of OPC are great. There are two basic problems though. The first one I already mentioned: COM. With regard to this, the OPC group in frustration with Microsoft's official abandoning of COM is slowly publishing the details of OPC-UA which is their COM-free replacement for OPC. The second problem is that OPC is not an open protocol. Access to the specifications is tightly controller by the OPC Foundation and the only way to get access is by paying thousands to join, and this is true regardless of whether it is OPC or OPC-UA. Documentation on the XML implementation of OPC used to be freely available but this particular protocol is not very popular and not common.

So..if you are willing to pay for at least the OEM version of RS-Linx or else buy an OPC server from Matrikon or Kepware (the two most popular vendors), then you are halfway there. All of these come with an OPC interface DLL that you can use from a DOS/Windows program with say standard C++. If you want to use a virtual machine though such as CLR, Java, or Parrot, there's a problem. You've got to somehow talk to the OPC driver which exists in the COM object model from within an entirely alien and foreign object system (CLR/Java/Parrot). This is no easy feat in itself even though you forked over money in the first place. Hence the reason that OPC-UA is so important, because among other things, it frees us from the COM object model which Microsoft has deprecated.

+1 paul on your post; a good read.

Great read Paul, appreciate the effort you put into your posts.

Thanks everyone for the help and web site. Last question, it is a good idea to use C++ for build window based application? All documentation I see is for console (command window) it's hard to found documentation on where to start for do a project with windows, push button, textbox, ect...

Suggestion for the Forum for administrator: The web site should have a C++, VB & JAVA section. We have a lot of member who know this code and they knowledge can be helpfull.

Thanks again

This forum is one of the most powerfull forum on the web...

C++ was originally designed in the text world. It can certainly do graphical applications. Usually these days, you use an IDE for developing these because manually writing draw commands and such gets very tedious. A very popular one is Qt. Google it and you'll get several references immediately. I believe you can use netbeans and Eclipse the same way since both were originally conceived to support Java but now support almost any language.

As an alternative, Microsoft Visual Studio can also support several languages if you are planning on buying an IDE, but there are some issues. First, you've just locked yourself into dotNET and you can't just recompile your program to run on a Mac or Linux down the road. Second, you have to deal with all the ugly details that programs written to run on dotNET 1.x will not run on dotNET 2.x or 3.x, and that simply installing the other versions to coexist won't fix the problem either, forever dooming you to a software troubleshooting/maintenance headache if you develop under dotNET. So if you do go down that road, prepare to have a permanent troubleshooting job dealing with installation issues.

You can almost think of .NET as a toolbox with nearly every tool made. Before .NET, programming was like using a hammer, adjustable wrench, and two screwdrivers. Any other tools you would have to make. I would strongly recommend learning a .NET based language (C#, VB.NET, etc). VB is actually much more forgiving and easier to get started with. Microsoft offers Express versions of their development environments for free.
http://www.microsoft.com/express/

You can find a driver written in VB.NET that works nicely with AB PLCs over serial communication. You can find it here:
http://sourceforge.net/projects/abdf1/

http://sourceforge.net/projects/advancedhmi/

The second project has the DF1 driver included into a larger package and it is a newer version of the driver.

You can also find other open source PLC drivers on sourceforge.


As for C++ being more powerful... on a windows based system, that is probably only true when you get down to low level hardware development. I've done a lot of VB.NET programming and have yet to run into anything that was not possible to do.

If you are using Java, I have had success with JEasyOPC. Not the easiest implementation to setup, but the documentation isn't bad.

--HandledException