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"