WebHMI status

D

Thread Starter

David Nimmons

Here is a copy of the status report I just sent my boss, for you that are interested.

After spending the last two months researching the possibility of developing a web based interface to our Allen Bradley plc's, I am convinced that it is very doable. This is a summary of what I want to accomplish, how it can be done and progress to date.

Goal:
Develop a browser based HMI for Allen Bradley plc's that is completely standards based and does not require any special software or plugins on the client computer. The first incarnation will be read only to provide
diagnostic and troubleshooting information. This will provide proof of concept. The next stage will be to add interactive capability to provide
full operator interface capability. Full implementation would use a dedicated in plant network for operator interface access and provide read only access to the general network. This approach will allow us to use inexpensive internet appliance type devices for operator interface terminals in locations with a controlled environment such as the ROC and
lil' ROC. In the field, we could use the Allen Bradley ( or similar ) NEMA rated flat panel touchscreens such as Ken had in his office for a while.

Implementation:
I am using an older pc that the IT department said was not adequate for use on the network as a desktop computer. It is running RedHat Linux 6.0 which includes most of the web server and programming software needed. Any other software I need is freely available for download off the internet. All the software that I am using is free ( Ken oughta appreciate
that ). After first review of the HTML and XML standards, it did not look like it was going to be possible to meet the goal of not requiring java or some kind of plugin on the client computer, as the existing standards did not provide any way of developing dynamic graphics or any way of providing dynamic data links to drive dynamic graphics. After further research I
found two new standards being developed that eliminate the need for java or browser plugins.
1. SVG - scalable vector graphics.
This is the new standard for 2-D graphics for the web. The
specification has been released for approval and should soon be a
public standard. There is already several implementations for
developing SVG graphics, such as Adobe Illustrator, CorelDraw and
several other free and shareware programs. The SVG standard provides
much more capability then any of the existing DCS or HMI graphics
packages, although at this time it will require hand coding the
dynamic effects as there are no tools available yet that offer the
easy fill in the blanks configuration that traditional packages offer.
The dynamic effects can be programmed with java, javascript, vbscript
or any of the other scripting languages available. I plan on using
javascript, since every browser supports it.

2. XML-RPC - XML based Remote Procedure Call
This is a method for embedding a remote procedure call into a web page
to allow requesting data or services from the server. It requires a
XML-RPC server on the server machine to respond to these requests, but
does not require anything special on the client. The SOAP (Simple
Object Access Protocol) standard being proposed by Microsoft and
backed by IBM and others is an XML-RPC.

Progress:
PC setup with necessary software
Defined initial graphic screens
Demonstrated ability to access and manipulate data tables in plc5 over
ethernet using Allen Bradley ethernet library for Linux from Ron Gage.
(Way to go Ron)
Obtained program for drawing SVG graphics. Have a simple logic type
diagram complete.

In Progress:
Use javascript to make graphic dynamic.
Download and setup XML-RPC server.
Use XML-RPC to access data to drive dynamic graphic.
Write interface between XML-RPC server and plc to obtain data. I
believe that this is the only thing that will requre any C programming
and should be fairly minor. ( Good thing too, since my C programming
skills are fairly minor )



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
David Nimmons:
> After first review of the HTML and XML standards, it did not look like it
> was going to be possible to meet the goal of not requiring java or some
> kind of plugin on the client computer, as the existing standards did not
> provide any way of developing dynamic graphics or any way of providing
> dynamic data links to drive dynamic graphics.

There are at least two http headers that cause the client to refresh the page after some time interval. One of them is the "Refresh" header; I don't have the other on-hand, but it directs the browser to load a different page after a certain time.

Both, I think, are limited to an integer number of seconds, minimum one. (This may have changed since last I tried.)

I used to have a dummy example on-line, but it's been years since I last tried it, so I've no idea if it still works.
http://www.csse.monash.edu.au/cgi-bin/cgiwrap/~jirib/today


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> There are at least two http headers that cause the client to refresh the
> page after some time interval. One of them is the "Refresh" header; I don't
> have the other on-hand, but it directs the browser to load a different page
> after a certain time.
>
> Both, I think, are limited to an integer number of seconds, minimum one.
> (This may have changed since last I tried.)

There's still the third way of using multipart answers. Thanks to all the marketing spinmeisters this is better known as "web push technology" (or "pure resource hogs" to admins). The basic idea is that the server responds not with a single "document", but instead with as much as it wishes. No-one imposes a restriction on how
long you wait between sending each individual document. If each document of a multipart answer is of the mime type "text/html", then the browser will happily replace the old page with the new one.

Unfortunately I don't know whether some web servers impose timeout restrictions even on multipart answers. Anyone out there who knows?

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

David Nimmons

I looked at using push technology, but, decided against using it for some reason, don't remember why. Probably did not understand what I was reading. Thanks for replying.

ps. I looked at ACPLT ( is that right.) . Looks very interesting. Look forward to playing with it one of these days.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Gilles Allard

>There's still the third way of using multipart answers. Thanks to all
>the marketing spinmeisters this is better known as "web push
>technology" (or "pure resource hogs" to admins). The basic idea is
>that the server responds not with a single "document", but instead
>with as much as it wishes. No-one imposes a restriction on how
>long you wait between sending each individual document. If each
>document of a multipart answer is of the mime type "text/html",
>then the browser will happily replace the old page with the new one.
>
>Unfortunately I don't know whether some web servers impose
>timeout restrictions even on multipart answers. Anyone out there
>who knows?

This seems to be a byproduct of version 1.1 of HTTP where the connection is kept opened by both sides until one side issues a "close" command. This scheme is known as "persistent connection" and is the default mode for HTTP1.1. CERN (source of the HTTP protocol) specified that this feature
would reduce traffic on the net (since less openings of connections would be required). They were right until some bandwidth abusers found it was a good way to inundate users with unwanted data. For details about HTTP1.1, look at http://www.w3.org/Protocols.
Gilles


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

As far as I know, multipart messages have been around at least since the HTTP/1.0 times. As multipart messages are a special mime type they are not part of a particular HTTP protocol version. You do not need persistent (aka keep-alive) connection to use multipart messages. In fact, the web server or its client can perfectly run multipart messages over HTTP/1.0 or close /1.1 connections after annoying the client with enough unsolicited advertising. The idea of multipart is not related to persistent connections but rather to the problem where the server needs to send a set of documents belonging together. With several GET requests this would be a non-atomic operation (remember, HTTP is
stateless). With a single GET and a multipart answer the whole things turns into atomic mode. The push operating model is just a nice side effect, albeit marketing spinmeisters will see this different.

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
T
David Nimmons, I would very much like to discuss your application and the approach you are currently following. Your comments describe a product that is, functionally, almost identical to a product that we have created for the Allen-Bradley SLC500 platform. Rather than being resident in a personal computer, we have designed a product that is resident inside an SLC500 I/O module case. We call our product WebPort; it is an embedded Web server that will host a Website that provides the user with status information from any data register within the SLC500. In addition, WebPort provides the user with the ability to change any data register within the SLC500. Accompanying the WebPort hardware is a software package called InSite Pro. The software package is what enables the HMI capabilities within WebPort. With InSite Pro we have created a fairly feature-rich environment that includes Web Page Building, Security Control, Data Read, Data Write, Alarming, Event Logging and full communication control for the module which includes both a serial port and an ethernet port on the front. All data is manifested in table format making it extremely easy to build multiple tables on multiple Web pages. InSite Pro allows the user to do all of this without needing to learn any HTML programming commands. It appears that we have arrived at an overwhelming roadblock to bringing WebPort to market as we are nearing the prototype stage of our project. Our biggest challenge is not coming from hardware or software implementation but rather from Schneider Electric who claims to own the patents for Web connectivity to PLCs. According to Schneider, if we are willing to pay them a $2000 royalty for every WebPort that we sell, they will grant us a license to sell our WebPort product. Seeing that we had planned to sell WebPort for a user price of approximately $1300, it is unlikely that customers would buy the module if we had to add $2000 to our cost, which would have an even greater effect on the user’s cost for the product. I know that there has been some earlier conversation on this site with regard to Schneider’s ownership of at least three Web connectivity patents for PLCs. From my perspective it is hard to justify the high royalty price that Schneider is asking the customer to pay. We have done a thorough analysis of the Schneider patents and strongly believe that our WebPort does not infringe on these patents. As a small company it is impossible to fight any potential litigation that might result from us trying to bring this product to market (our lawyers are telling us that it would mean $1 million to $2 million of legal costs and we don’t have anywhere near that kind of bank account). As a result of Schneider's challenge to our product we have pulled it from the market, we are not offering it for sale and are pondering what our options might be. What’s a small company to do? We clearly have created a solution that customers are asking for but unless customers are willing to pay $3000 to $4000 for this solution it appears our only option is to flush hundreds of thousands of development dollars down the proverbial toilet. Mr. Nimmons, your company should be prepared for Schneider to come knocking and asking you for their $2000 royalty for every PLC5 that you enable. Give me a call and we could discuss the challenges that might be ahead for you. Tom Benson, Strategic Alliance Manager Spectrum Controls, Inc. PO Box 5533 Bellevue, WA 98006 Phone: 425-746-9481 ext. 126 [email protected]
 
Top