It was hinted in another post that Android tablet could be a good all in one PLC, including HMI (Armin Steinhoff, I believe said this). Rather than hijack that post I thought I'd get some comments in a new post. I'm interested in it purely from an HMI perspective, and would like to discuss that primarily. I'm speaking of a replacement for the 6"-12" HMIs that you plug in and they boot rather quickly and then display some pages that you designed in some programming package. All ideas and comments are welcome. It should be noted that I don't have or never have used Android devices, or even the iphone/ipad.
I've now seen some of these devices with wired Ethernet in the 7"-10" screen sizes for very low cost. I've looked at some of the SDKs for Android and it seems that they have facilities for XML based GUI layout, as well as some WYSIWYG designers. I'm assuming web based layout is not an issue as well ;-)
So why use an Android or other device instead of a commercial HMI? Well nearly infinite connectivity (if you are willing to code it or use others code) is one thing. The other is additional functionality that will evolve over time. Database reports, logging, etc, are not limited to what the HMI developer has locked you into. "Open" in the sense of being able to program your own or use others code (Lets not get into an open source discussion per se....).
OK, so why use Android vs. an embedded panel computer? Well, for one the platform is designed for navigation and use via touch. This has always been a problem for me in developing for windows or linux using touchscreens because the default buttons on everything were not coded to be a useable size for real fingers, not to mention lack of a good on screen touch keyboard (yes, you can probably install add on keyboard packages, but likely not as well integrated as iphone or android). Sure, you could code around these things for your particular application, but what about third party apps like web browsers, file viewers, database reporting packages, etc?
So what is involved in using one of these things as an HMI? Does anyone know if there is a simple method by which an automation professional could easily learn the programming tools given some predefined HMI type of widgets to do some simple screen layout? I'm now looking at Visual Studio or the open source SharpDevelop as easy to use WYSIWYG layout editor for drag and drop custom HMI widgets onto a screen to get some HMI functions. This is promising, but at the same time the embedded targets for .net are a bit funky. I've seen some windows CE machines that can run .net forms apps, but they aren't exactly growing on trees either (Maybe I'm wrong, I'd like to know this as well). Beign completely locked into Microsoft is disturbing, although using an embedded panelPC running linux with Mono is a good alternative. And, as I've mentioned the user interface experience with a touchscreen is not startling.
There are perhaps some minor "problems" with using Android tablets in the factory. For instance, when the machine shuts off your battery based tablet is probably going to stay running until it runs out of battery rather than shut off with the rest of the machine as is the case for a commercial HMI like from the big players. Can you "boot" your Android tablet or phone and have it automatically start up your HMI application? Can simple apps be simply FTP'ed over and run immediately, or do you have to go through some kind of registration/publish and then install process on the tablet itself?
Like I said, any thoughts are welcome here.
It does appear attractive. And it could certainly be done. But as you mention, there would be usability issues in the factory. Some of which could be programmed around. The big plus would be cost, as the volumes on these gadgets bring the costs down. On the other hand, there are many SBCs that are sold with a touchscreen and permanent power facilities, with the same processors and lots of bells and whistles. They would need packaging. Programming would be a wash as the same program might well run on both. But the volumes on the SBCs are not as high. It would be interesting to see a detailed cost analysis on one approach vs the other. I wouldn't be at all surprised to see an already existing package on Linux/Android that would enable user customization (you folks can jump in here). For my usage, where I want access to the hardware facilities, the SBC is obviously the way to go. I have seen hints that tablets already are being used for HMI and I have seen some commercial products. For instance. check these guys out:
No relationship here, I just saw them while buying some parts from Jameco.
The vast number of Linux/Android embedded projects are just now beginning to hit the market, and stuff like this will be coming out of the woodwork all over. You ain't seen nothin' yet!:^) This premonition was why I shaped my modest project the way I did. It focuses on the parts that aren't commoditized, but will be. I suppose I could do the big automation thing and patent using IO with Linux:^) Kinda like using a browser with PLCs:^) But, I intend it more as a humble, Open, reference implementation to show the obvious to the right people. I suspect by the time you got done, your project might be the same:^) If automation didn't change with such glacial expediency, we'd be overrun already. The merit and synergy are so obvious, that only the incorrigibility of the major players can stem the tide. And they risk irrelevance if they ignore it. It's just so much easier than the alternatives, the threshold is lowered to the point of extinction. And that's a good thing from the consumer end.
cww The Linux Automation guy.
In reply to Curt Wuollet,
I agree that we have yet to see what is to come with Android and industrial products. The fact that ICP-DAS has an "industrialized" 5.7" HMI based on it is refreshing. I did not know of this. Of course the price is probably going to be hefty compared to a tablet from Best Buy, but this will probably be worth it for companies that want a stable product that will last years in the same form factor. Nothing guaranteed of course, but more likely to be stable.
I have to be a bit careful, I once thought the wonderware compatable CPU from Automation Direct was going to be popular, but that is now a legacy product for them I believe. Its hard to predict the future in the automation world. It does seem to be a slow moving filter.
Actually the AD offering still lacked what will drive Android/Linux into the market. It was pretty spendy and it wasn't Open. That is, it's versatility was nil. One of the reasons I think automation moves so slowly is that the "new" stuff isn't much different than the "old" stuff. As long as the hardware and software are bundled and closed it's pretty hard to discern a difference between a new product and a 10 year old product.
Upgrades really aren't much of an upgrade and the leading cause of replacement is software or hardware planned obsolescence. To be really different and offer a real advantage, the ability to run more than one package on the hardware would be good, being able to run what _you_ want would be great. The hyper proprietary vertical model doesn't really advance things, it just adds more products to do the same thing the same way.
Yes, the "WinPLC" is legacy now, partly due to lack of interest and partly due to the fact that the processor it uses topped out speed wise and is no longer being enhanced.
I think those two items (lack of acceptance and brick wall to updated performace levels) are actually two facets of the same issue.
I think the "failure" of the WinPLC says more about the power level of the components available when it was designed than the validity of its concept, and therefore isn't a very good predictor of the fate of similar concepts implemented on today's hardware.
HMI must be client/server.
Then you can run the client on a mobile device.
The client might be a ordinary web browser.
But in that case your HMI will have a lot of limitations.
Our project http://pvbrowser.org uses a client that is based on Qt. Since Nokia is the owner of Qt it has been adapted to mobile devices. For example i can run our pvbrowser client on my Nokia N900 smartphone under Maemo which is an ancestor of MeeGo.
There is also a port of Qt to Android
We are currently evaluating this project and hopefully pvbrowser will be available for Android also. A practical problem with Android is that there are several versions of Android on current devices. Especially smartphones use Android 2.x and tablets use Android 3.x
> It was hinted in another post that Android tablet could be a good all in one PLC, including HMI (Armin Steinhoff, I believe said this). Rather than hijack that post I thought I'd get some comments in a new post. I'm interested in it purely from an HMI perspective, and would like to discuss that primarily. I'm speaking of a replacement for the 6"-12" HMIs that you plug in and they boot rather quickly and then display some pages that you designed in some programming package. All ideas and comments are welcome. It should be noted that I don't have or never have used Android devices, or even the iphone/ipad. <
> I've now seen some of these devices with wired Ethernet in the 7"-10" screen sizes for very low cost. I've looked at some of the SDKs for Android and it seems that they have facilities for XML based GUI layout, as well as some WYSIWYG designers. I'm assuming web based layout is not an issue as well ;-) <
> So why use an Android or other device instead of a commercial HMI? Well nearly infinite connectivity (if you are willing to code it or use others code) is one thing. The other is additional functionality that will evolve over time. Database reports, logging, etc, are not limited to what the HMI developer has locked you into. "Open" in the sense of being able to program your own or use others code (Lets not get into an open source discussion per se....). <
> OK, so why use Android vs. an embedded panel computer? Well, for one the platform is designed for navigation and use via touch. <
An Android based tablet PC is a complete LINUX system. It provides a very user friendly HMI for the end users. But from the developers point of view it's also an interesting target hardware not only for HMI oriented apps. The android accessory project shows some robotic applications and USB based I/O interfaces ...
I have seen a tablet PC with WLAN, RJ45 LAN, 2 USB host/client interfaces ... so why not running EtherCAT or Modbus TCP/IP on the RJ45 port for control purposes ? The WLAN could be used for administration or programming. These systems are also perfect for Java apps and with the native SDK for C/C++ apps.
And if you need real-time ... apply the PREEMPT_RT patch to the 2.6.3X kernel.
Just some wild ideas :)
In reply to PVBrowser:
Thanks. By client/server I assume that you mean that there is a server running on the control computer (whatever it may be) that can handle data/IO queries in some sort of polling scheme. Is this correct? One controller I am using would be a simple ascii query scheme using a telnet or ssh connection.
I'm looking to build a set of "smart" widgets with predefined signals that update themselves for display of data (like a commercial HMI does, for example) and uses an already available IDE to build a file for execution with a runtime (.NET, Java, Python, etc). Since it uses a runtime the user can test for visual appearance on their development machine and FTP the file to the remote machine for execution. That's the plan anyhow. I am currently thinking that communication layers will be built into the project file using references/includes to external dll's or equivalent. Very simple, hopefully not *too* limiting.
Perhaps QT and Java would be a good fit for a Android deployment? I don't' know how this differs from the "normal" android development tools. Widgets and things would be different of course.
>In reply to Ken Emmons Jr.
>By client/server I assume that you mean that there is a server running on the control computer<
Our client is something like a browser. But it uses Qt Widgets instead of HTML This client could run on a mobile device with android.
>Perhaps QT and Java would be a good fit for a Android deployment?<
Androids first programming language is Java but you can use Qt, C/C++ with http://sourceforge.net/p/necessitas/home/
Today i got http://pvbrowser.org client software running on the android emulator. There is one issue left with read/write files to disk. But the browser runs except that.
> Today i got http://pvbrowser.org client>software running on the android
> emulator. There is one issue left with read/write files to disk. But the
> browser runs except that.
These problems are now solved. See:
Now we have to test on real hardware.
> concept is great but it is really possible if yes then how?
Yes, in the mean time pvbrowser client on Android is working.
See "Android" at:
The pvbrowser client is done with Qt.
The Android support for Qt is provided by:
Since pvbrowser is running on Maemo/MeeGo even longer the GUI had already been optimized for small screens before.
In reply to Armin Steinhoff:
Those are interesting concepts. I still wonder if we want to wait for an automation vendor to provide at least the hardware for something like this. Having two ethernet ports might be nice, but perhaps not necessary if you have a nice switch attached to it to filter out unecessary traffic.
Do you have any experience with their SDK's (Java or native C++)? I'm wondering how nice they are to use and if the widget set is convenient.
In reply to Ken Emmons Jr.:
> In reply to Armin Steinhoff:
> Those are interesting concepts. I still wonder if we want to wait for an
> automation vendor to provide at least the hardware for something like this.
I see no problems with this.
Our pvserver's can also be done with Lua instead of C++.
In that case you could store the Lua pvserver on the android /sdcard and edit the application via USB from a normal PC
What would have to be evaluated is how to start daemons in the background.
One possibility is the "start" option within our pvbrowser client which can spawn background processes on startup. But there might be other solutions as well. Currently i do not know if startscripts in /etc/init.d are also possible on android.
> Do you have any experience with their SDK's (Java or native C++)? I'm
> wondering how nice they are to use and if the widget set is convenient.
Now i have some experience with
This is C++ development.
There you have the full Qt widget set + QML
You can simply recompile a ordinary Linux app.
For GUI applications you may make some optimizations if you have a small screen.
Have a look at: http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html
While an Android device might make a very nice small HMI, for the larger and more complex systems, an Android smart phone or tablet role might better be as a thin client. We have been developing this with a Vsystem Android app and a 3/4G or WiFi connection such that any of our graphics-based SCADA tools, including the HMI, can be brought up on a smart phone or tablet.
Vista Control Systems, Inc.
2101 Trinity Drive, Suite Q
Los Alamos, NM 87544-4103
All of these applications listed make use of client server or web interface. Both methods require overhead. AndroidS7 is truely an HMI using a wireless connection directly to a Siemens PLC.
They are also working on using the same technology in a tablet that can talk to Siemens or Allen Bradley.
Not sure if this would help but looking at the Google play store, there is an android app that claims can connect directly to an Allen Bradley PLC-5 unit. Called PLC-5 Mobile HMI. There is a free and paid for version. The free version can connect to the status registers and the paid version can connect to the input/output files.
Says no OPC server or third party library. Somehow, I guess, using the ENET protocol.
I have been using Android, iPad and iPhones to "mirror" the display on Siemens HMIs. They have an in built remote access function which uses a Java applet. This can be accessed remotely with a VNC program like Mocha VNC. Of course this does not do away with the existing HMI and the screens are identical to the HMI but it is a good solution for remote monitoring of plant. BTW the in built browser can not be used on phones as the browser wont install Java.
Our client for Android can be downloaded from
It is based on the Qt library.
Accessibility for mobile devices is one of the expectations HMI/SCADA software developers will have to embrace in the very near future.
One way this is being achieved is by leveraging the power of HTML5. For example, Status Enterprise Edition from B-Scada allows you to create an HMI screen using WPF controls, then access that screen on any modern browser that supports HTML5. This includes iPad, iPhone, Android, Blackberry, Kindle and Windows devices.
Basically, any smart phone or tablet can view the same screens you see on a desktop workstation.
Learn more at http://scada.com/Software/StatusEnterpriseEdition
We've developed just this type of HMI. We have an Apple version already polished up, and have just released the Android version. It's called Nanospark.
We focused on the iPod touch and on 7" Android tablets for our HMI for a number of reasons:
- Processing power is plenty for most manufacturing processes and facility management tasks.
- Easy of customization (there are a million programmers out there who can do complex apps for significantly less than custom PC software).
- Built in tablet features can so easily be brought to bear on the programming. With our in-house projects the wifi has always been used. But we've also used the microphone, camera and GPS.
- Apps as machine monitoring and control are super easy to learn.
- Price point (we all knew this was coming).
There are two main hurdles I'm running into with regards to using a tablet for HMI.
1. Getting people to stop thinking of their iPod, smartphone or tablet as a personal device and realize how much and how simply it can enhance their product or their manufacturing facility.
2. The sheer amount that COULD be done seems to overload the brain. So that then even what SHOULD be done gets shoved aside.
You guys seeing these too?
This subject caught my attention because I working on a project where we are using a Nexus 10 tablet as a human-machine interface. The plan is to keep it connected to a charger. Normally, a user would connect his charger to the USB port. In our application, the USB port is connected to a USB-to-Ethernet adapter which is connected to our machine's control PC. An app on the tablet communicates through the adapted interface. We are utilizing the tablet's magnetic "Pogo" adapter jack to keep it charged.
What we have learned is that the power consumption of the USB-to-Ethernet adapter exceeds the ability of the Pogo adapter to keep it charged. So the battery eventually dies, then the tablet turns off and we have no interface. To minimize power drain, all unnecessary functions on the tablet are off/disabled. We have tried a couple of powered USB-to-Ethernet adapters but none so far work. They come with driver disks and so appear to geared for use on PC's and not Androids. I can find no info on making these compatible with Androids.
I welcome any suggestions from anyone who has solved this or similar problem.
You need to connect the power supply lines in the USB connection to a high-current source that can provide in excess of the current draw of the tablet in service. This may require a bit of surgery on the USB connection - but is doable.
A standard USB 2.0 port will provide up to 500 mA - which is OK for charging phones but not necessarily for a tablet. A wall-wart charger is good for 2 A, (according my Nexus 7 charger nameplate) and will charge while the tablet is in use.
If you get hold of a suitable charger, you can modify the connection to the USB-to-Ethernet adapter to allow a feed from an external supply - or possibly get into the innards of the adapter and connect through that.
Gary, I've got a powered USB 4-port hub connected to my Nexus 7. I would think such a device should work for you.
I hope you all will not see my post as a advertisement.
We are a small family company that design and build panel pc systems. We now have Android Panel PC's from 8" up to 19" displays.
We have seen the no battery problem with a few customers when they use tablet Androids. With our own Android Panel PC that have NO battery but RJ45 port / Wifi / 24VDC and 12VDC input they dont have that problem. Only is that our systems are made for installation on one single spot, not mobile.
If any one have any thoughts about what wee need to add in terms of functions etc please send me a mail: firstname.lastname@example.org
Regards / Peter
I found a very good free apps for android and IOs devices (Iphone, Ipad) that is a SCADA where you build the interfaces directly in the Tablet and works with all devices that use Modbus TCP protocol (PLC, Drives, IO deported..) The name is ScadaTouch and is available in GooglePlay or AppleStore. This is the website where I found it www.appliworld.com.
You should tried SCADA+ on Ipad. A native SCADA application compatible with Modbus TCP. Integrated data historian and fully customizable interface. A promising apps that shows the potential of tablet in HMI world.
here below link: