How to Build a Free HMI for AB

Cool video! A bit hardcore, but the geek in me loves it! Is there a sourceforge project for .NET AB ethernet drivers? I see lots of people posting that same question...

Archie said:
Here is a video that shows step by step how to get freely available software and use it to make an HMI that communicates to an AB SLC or microLogix via serial connection.

It is about 9 minutes long and the final step shows the simple HMI displaying the accumulated value from a timer in a SLC500.

http://www.youtube.com/watch?v=CiPzqc5jDlE
 
surferb said:
Is there a sourceforge project for .NET AB ethernet drivers?

There are a couple open source projects for Ethernet, but most are for Linux.

Ethernet/IP for Windows and VB Express has been on my "to do" list for a while. I've had trouble getting the hardware to use for development and its hard to justify spending about $2k on hardware not related to any current projects. I was promised the other week a loaner ControlLogix with Ethernet. I still need to follow up to see if he is going to come through with it for me.

Once I get the hardware, it will probably take 4-6 months to develop. Ethernet/IP is a very complicated protocol.
 
I'm very impressed. I made a donation and recommend that others consider doing the same. Archie's spearheading one of very few open source projects that actually help with industrial software - and it looks to have potential to be useful (sorry Linux and C++ projects, at this point I'm just not convinced). What are your thoughts on LGPL vs. GPL?

Now for my personal and biased, opinion and facts of life for controls software rant:

1. Projects at this stage, and the forseeable future are great learning tools for the technically savvy. They allow geeks in their garages to make really cool projects that are only expensive in time. This educates and de-mystifies how stuff works, particularly for integrators/PLC programmers that usually only interact at a fairly high level.

2. If you go LGPL you might get OEMs or someone to take off with your project. Obvious annoyance - they profit on your work. But realistically, they could get a very mature development package like this for a one time fee and unlimited distributable "runtime" licenses for <$1000.

3. Insert shameless advertising - I was really impressed with the youtube video showing a truely free HMI creator, end to end - and even more impressed with the HMI graph screen that you created in 40 hours. I have a computer science degree and have programmed enough to know that something like that would take me quite a bit longer, especially working out those last little bugs. I'd really like you to check out FactoryPMI, particularly the new major release coming out next week. It's very interesting from a programming standpoint. I would recommend downloading a trial or just doing a half hour web demo - tell them Nathan recommended that you do it with a technical guy rather than a sales guy. A novice user should be able to set up a similar screen from start to finish in under an hour. The real test is how programmatically flexible it is (any HMI can do a precanned graph). I'd really like your opinion because I don't know many people who are real software developers and also knowledgeable with have real world experience in the field in industrial controls. There will also be a web launchable demo here by next week that shows it flex its muscles a bit.

Good work. I'm hoping this and other projects are leading the way to an eventual, truely workable Industrial "open office" of controls software.
 
Nathan

Thank you for the donation, it is hugely appreciated. All donations go toward purchasing hardware for developing more projects like this one.

As for LGPL vs. GPL, I have several thoughts on it.

Currently there are a number of products (software controls) on the market similar to my open source project, such as the one Automated Solutions. My DF1 control gives a "no cost" version for those that do not need tech support or want to learn or experiment and do not have the budget. It also gives a chance to peer into the what is really happening over the DF1 protocol, which few really get to see. Ebay has helped a lot for aquiring hardware at a much lower cost and I hope to help supply the software. Where I am trying to go with this is... controls like this were on the market as commercial products before open source options were. The LGPL gives the opportunity to take features that are only available in open source to the commercial market.

Don't get me wrong, the DF1 open source control offers all the features needed to use in a production environment. I have one project in real production and about to put another.

Another reason I would hesitate to use LGPL is shear perception. Someone could take this control and sell it "as is" and would probably get more users than the open source version simply because the market tends to perceive open source projects as "less capable" or more difficult to use than commercial software. I'm a strong believer in open source and software sharing and want to help encorage its use.

I probably covered much of your points 1 & 2 within all my ranting above. As for point 3, I will take a look at that software and give any opinions.

To give a quick history and future of this project, it started from some of my frustrations with existing solutions from years ago. I have been programming PLC's and building PC based HMI's since the mid-90's. While doing some of my first projects, I kept running into limitations of the available HMI software, not counting the thousands of dollars spent on the development packages and run-time licenses.
Having a background in software development, I explored the use of high level languages to build HMI's. One big reason was because there were virtually no limitations to what could be done from a software perspective.

As software development environments improved, I began to explore the idea of merging the ease of use from an HMI package to the un-bound limitations of high level software, such as Visual Basic. My thought was...Why couldn't HMI specific components be in the VB toolbox to allow basic HMI functions without the need for coding and use coding for the more advanced things you need to do?

I wanted to do this as open source in hopes that other developers may jump in and build components based on this model and grow the "HMI tool box for Visual Basic". After Microsoft released the free versions of Visual Basic (express version), it now made it much more accessible to everyone.

I have built the first model using Beckhoff TwinCAT because their communcation drivers were available and free.

Once I have seen the possibilities, I started with the most popular platform with a published protocol, the AB DF1.

I have shown in the video how to display a number with one line of code. After I build the "HMI label" this will be able to be done with no code, you will only need to simply set the properties of PLC address and the poll time.

Look forward to more features being added to this project and even non-programmers will soon be able to build "Free HMI's"
 
Archie,
Good points on the GPL/LGPL thing - I can easily see both sides. It's interesting that we both had very similar experiences with HMI software. Given the price and quality in the early 2000s, I guess it shouldn't come as much of a surprise.

Thanks for sharing your story. I also have a software background. I have a computer science degree, but more real world experience in IT than programming. The other guys that I worked with at the time both had strong software development backgrounds. We were doing HMI projects for a local integrator. They were a Rockwell Certified Solution Provider, so our projects were mostly in RSView and panelviews, but we had to write plenty of custom apps and do VBA scripting to make up for the deficiencies of the software at the time.

Each of us acknowledged that HMIs could be better written with general purpose programming languages. The integration company had (unsuccessfully) previously tried to write a powerful HMI that was targeted toward wineries. It was a wrapper or plugin or something for Borland's Delphi (Turbo Pascal, I think). The application helped create HMI-ie things easily and did a lot for you. It was incredibly powerful. The problem was that you really had to be a programmer, as in a professional software developer, to really utilize or troubleshoot the HMI applications. Our integrators in the field would get hosed trying to support the thing. At the time, HMIs were clunky and inflexible, but at least integrators could figure them out. You can't learn a general purpose software language/environment on a job site with the customer looking over your shoulder. Keep this in mind as you weigh in the value of instructional videos and ease of use features (which you have done with the YouTube video and plans of the HMILabel component).

The things that drove us to develop alongside our working single terminal HMI stations were: lightweight distributed access (managers wanted to see production info in realtime from their desk), and database integration (better historian, and integrating existing database data into the system). We really focused on utilizing existing technologies. As of 2002, HMI terminals that stored historical data in flat (text) files that linearly slowed the computer down over time, and often corrupted, made it patently obvious that basic computer science was not being applied in our industry. Each HMI computer needing (configured) drivers to communicate with the PLCs directly obviously wouldn't scale far, and the distributed apps of the day (todays aren't tremendously different) used proprietary concocted protocols that really should have been based on standard networking. The point is that an HMI application isn't unlike any other application, except that it communicates with devices. Distributing these applications is strikingly similar to the problems faced, and solved, by the corporate world and the Internet. This is a tangent compared to your application, which is a driver and HMI that I presume isn't designed to scale greatly (without the author coding it that way in .NET).

In any event, we tried our best to create an HMI that is simple to use, is programmatically flexible, is scaleable, leverages existing technologies, and can be supported by IT. I think that after 4 years, we're at that point. Using SQL databases, standard web servers (Apache), web technologies (Java Web Start), and many LGPL projects has paid off in performance. We have a respectable and growing install base without dissatisfied customers. It's surprising, and not too uncommon to hear integrators (rarely end users) complain that the product isn't "proven" because it hasn't existed for 15+ years. We're supposed to be an industry that embraces change and innovation - since the Industrial Revolution. And what other industry cares about age in software products (not progamming languages or operating systems)? It's more common to hear, "hey I have this cool new program that...". Even Citect is commonly regarded as "new"! I'm going to guess that they've been around for nearly 20 years! Unfortunately, I think you may run into this same problem in commercial adoptability. We get end users who say things like, "We love your software, and your install base references were great, but do you have any in our specific nitch who have been running for years and are doing X". Lol, I feel like telling them that an HMI package is an HMI package - it doesn't know if you're manufacturing widgets or ice cream.

In any event, I like what you're doing/have done. Using a general purpose programming language is the most powerful way to create an HMI. And, if you're willing to trade time for money, it's really affordable. Best yet, the huge range of novice programmers (myself included) can learn what's really going on with device communication and appreciate what goes into software development - particularly when we get the urge to criticize precanned packages. The common expectation to be able to create ANY flexible, custom application without programming, and in less time, is absured. If they want to write their own app, they can get started with your project. If they want the assistance of an HMI package they should try FactoryPMI.

I hope you get help and support from the open source community! I would also love to see people writing/sharing components (now I can't even get people to share industrial images, which would be useful for any HMI package, commerical or otherwise). I look forward to seeing your progress.


Archie said:
Nathan
To give a quick history and future of this project, it started from some of my frustrations with existing solutions from years ago. I have been programming PLC's and building PC based HMI's since the mid-90's. While doing some of my first projects, I kept running into limitations of the available HMI software, not counting the thousands of dollars spent on the development packages and run-time licenses.
Having a background in software development, I explored the use of high level languages to build HMI's. One big reason was because there were virtually no limitations to what could be done from a software perspective.

As software development environments improved, I began to explore the idea of merging the ease of use from an HMI package to the un-bound limitations of high level software, such as Visual Basic. My thought was...Why couldn't HMI specific components be in the VB toolbox to allow basic HMI functions without the need for coding and use coding for the more advanced things you need to do?

I wanted to do this as open source in hopes that other developers may jump in and build components based on this model and grow the "HMI tool box for Visual Basic". After Microsoft released the free versions of Visual Basic (express version), it now made it much more accessible to everyone.

I have built the first model using Beckhoff TwinCAT because their communcation drivers were available and free.

Once I have seen the possibilities, I started with the most popular platform with a published protocol, the AB DF1.

I have shown in the video how to display a number with one line of code. After I build the "HMI label" this will be able to be done with no code, you will only need to simply set the properties of PLC address and the poll time.

Look forward to more features being added to this project and even non-programmers will soon be able to build "Free HMI's"
 
Last edited:
Well done Archie! I've been following this project since you first posted it here.

It's funny because I noticed a couple of days ago that M$ offered a free version of their programming softwares, so I downloaded VB express. Then I saw this post yesterday. This should keep me busy for a while.
 
Wow, GREAT job Archie, this is really neat!

Keep up the great work! :D

Edit:

Is it possible to make a program that acts as a OPC/DDE server?
 
Last edited:
You're asking him to write a free, open source OPC server for AB PLCs? Rockwell, Kepware, Matrikon, and many others may send thugs knocking at his door ;). I, for one, would welcome the project!

nettogrisen said:
Wow, GREAT job Archie, this is really neat!

Keep up the great work! :D

Edit:

Is it possible to make a program that acts as a OPC/DDE server?
 
Well yeah :)

As the DF1 is opensource there would be nothing illegal about it, right? Rockwell, Kepware and the others can just lower their prices ;)

I have already been fiddeling with connecting to an SQL server wich gives me some nice abilities, but I'm a newbe with Visual Basic, so at the moment I'm only able to read from the server and not write. Maybe Archie can make a movie about it :)
 
I don't think there would be a problem whether DF1 was open source or not. Consider the fact that Open Office can use the proprietary Microsoft Office format.

By 'writing to the server' are you referring to:
1. updating tags in the PLC
2. INSERTING/UPDATING records in the database
3. creating/modifying tables/permissions in the database?

nettogrisen said:
Well yeah :)

As the DF1 is opensource there would be nothing illegal about it, right? Rockwell, Kepware and the others can just lower their prices ;)

I have already been fiddeling with connecting to an SQL server wich gives me some nice abilities, but I'm a newbe with Visual Basic, so at the moment I'm only able to read from the server and not write. Maybe Archie can make a movie about it :)
 
surferb said:
I don't think there would be a problem whether DF1 was open source or not. Consider the fact that Open Office can use the proprietary Microsoft Office format.

By 'writing to the server' are you referring to:
1. updating tags in the PLC
2. INSERTING/UPDATING records in the database
3. creating/modifying tables/permissions in the database?

I'm referring to the 2 last points, I'm not that pro with SQL databases yet either :)
 
Don't worry about it. There are a lot of available resources to learning SQL. There are 4 basic query types to learn when dealing with tables. SELECT, UPDATE, INSERT, and DELETE. I would recommend reading an online tutorial and playing with those queries in a frontend (enterprise manager for MS SQL Server). It's not difficult to learn and ends up being very powerful (interfacing relational database model with SQL). At that point I would get into running queries through VB (MS Dev studio).

I compiled a list of free online SQL tutorials here.

On the very last point, you can modify tables with SQL queries. The Microsoft VB.NET and MSSQL may make this easier for you. I wouldn't worry about that too much just yet.


nettogrisen said:
I'm referring to the 2 last points, I'm not that pro with SQL databases yet either :)
 

Similar Topics

Find the software ADP Configuration Software Text apresentation: "This free software allows easy configuration of advanced objects including...
Replies
0
Views
11,040
I'm looking for some clarification if anyone here is familiar with UL698a panels. Panel is out of zone/class'd area. with thermocouples extending...
Replies
0
Views
81
Hey guys, last week I posted part 1 of a series of OPC UA articles in Node-RED. That article covered some important concepts of OPC UA and how...
Replies
8
Views
3,851
Hey everyone I have an 1756-CNBR/E CONTROLNET goes faulty sometimes and now it's still faulty until I restart the main racks It shows this message...
Replies
0
Views
859
Good afternoon all I'm having some troubles trying to go online with a twincat3 project that has been developed with another laptop (I will call...
Replies
1
Views
1,557
Back
Top Bottom