Android tablet for HMI?

K

Thread Starter

Ken E

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.

KEJR
 
C

curt wuollet

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:

http://www.icpdas-usa.com/

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.

Regards
cww The Linux Automation guy.
 
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

http://sourceforge.net/p/necessitas/home/

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 :)

Best Regards
Armin Steinhoff
 
K

Ken Emmons Jr.

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.

Thanks,
KEJR
 
K

Ken Emmons Jr.

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.

KEJR
 
K

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. 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.

KEJR
 
C

curt wuollet

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.

Regards
cww
 
S
Ken
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.
 
>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.
See:
http://pvbrowser.de/pvbrowser/pic/prinzip.png

>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/

PS:
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.
 
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
http://sourceforge.net/p/necessitas/home/
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.
 
P
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.

Peter

--
Peter Clout
Vista Control Systems, Inc.
2101 Trinity Drive, Suite Q
Los Alamos, NM 87544-4103
[email protected]
http://www.vista-control.com

 
A

Automation Man

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.

www.androids7.com

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.

https://play.google.com/store/apps/details?id=com.jca.plc5exp&hl=en

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.

Dwain
 
Top