Web based MMI

D

Thread Starter

David Nimmons

Following is my response to Davis Ray Sickmon after he responded to my inquiries about the Jaguar MMI he is working on. I decided to post it to the general list to see if anyone else is interested in participating.

- - - -
Thanks Davis for the information. I would be very interested in participating. I don't know anything about Visual Basic because I swore off
Microsoft products many years ago, so maybe I can help with the porting effort.

Like Mr. Joe Jansen, I also have a project at work in mind. I work in a complex that produces polyethylene and polypropylene plastic. and styrene. We also have a gas plant that produces the ethylene and propylene feedstock for the plastics plants. We have ABB Advant DCS systems in two plants, Foxboro I/A systems in two other plants and just installed an Allen Bradley
ProcessLogix in our Styrene plant. In addition we have just about every type of plc that Allen Bradley makes, including their new ControlLogix
system ( Not installed yet ). I guess what I am trying to say is that I've got a pretty good laboratory to play with.

My project is to develop a web based mmi for all of our Allen Bradley plc's. The first incarnation will be read only to provide troubleshooting
information for the maintenance techs. This will be the proof of concept stage. The next stage will be to add write capability to use for a full
operator interface. After that is done, my goal is to develop interfaces to the DCS systems to provide a universal operator interface to all of our systems. The idea would be to use the expensive Sun and HP workstations that Foxboro and ABB use only for the engineering and configuration and have the operator workstations be inexpensive browser based appliances.

I don't know how this dovetails with your plans, but, If you are interested let me know.


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

Midnight Ryder

> Thanks Davis for the information. I would be very interested in
> participating. I don't know anything about Visual Basic because I
> swore off Microsoft products many years ago, so maybe I can help with
> the porting effort.

Well, the first major obstacle would be to get ahold of Gnome Basic:
http://www.gnome.org/gb/

I don't know exactly how ready for prime-time it is. I was planning on waiting a while to see it mature a bit before really jumping into GB with
both feet and seeing how well it worked. :-/


> Like Mr. Joe Jansen, I also have a project at work in mind. I work in
> a complex that produces polyethylene and polypropylene plastic. and
> styrene. We also have a gas plant that produces the ethylene and
> propylene feedstock for the plastics plants. We have ABB Advant DCS
> systems in two plants, Foxboro I/A systems in two other plants and
> just installed an Allen Bradley ProcessLogix in our Styrene plant. In
> addition we have just about every type of plc that Allen Bradley
> makes, including their new ControlLogix system ( Not installed yet ).
> I guess what I am trying to say is that I've got a pretty good
> laboratory to play with.

Interesting environment!

> My project is to develop a web based mmi for all of our Allen Bradley
> plc's. The first incarnation will be read only to provide
> troubleshooting information for the maintenance techs. This will be
> the proof of concept stage. The next stage will be to add write
> capability to use for a full operator interface. After that is done,
> my goal is to develop interfaces to the DCS systems to provide a
> universal operator interface to all of our systems. The idea would be
> to use the expensive Sun and HP workstations that Foxboro and ABB use
> only for the engineering and configuration and have the operator
> workstations be inexpensive browser based appliances.
>
> I don't know how this dovetails with your plans, but, If your
> interested let me know.

Nod - I'm interested, but, I'm not sure what could be done here. Without GB being complete enough for Jaguar to run over there, I can't port it there :-/ As for using Jaguar to dump info to an intranet or Internet webserver - that actually should be relatively trivial under the Win32 version using IIS 4.0 by writing a module to be a CGI, and building a HTML processor that reads in a template and spits out the proper HTML document via CGI. Or pick any of a million other schemes to pull it off, too. It's possible to do.

It is the thing to do at the moment - well, sure, if someone else wants to do the work to handle it. Problem is, for now, it would still be stuck on Win32 :-( The upside it, there's not thing that says that it has to be written in VB - while the most internal portion is being written there
(mainly because most of the MMI people I know at the customer and integrator level know VB, but don't know C/C++, and aren't Linux people) if someone wants to implement one of the external tools or programs in C or C++ (or COBOL for that matter) there's definitely no one gonna stop them <GRIN>

One other bitch about this is that it's currently using DDE for communications with drivers and external programs (slow) and Joe Jansen is
thinking about implementing named pipes for communications which would be much nicer and faster, and provide for making distributed systems nicely. However, I think both solutions would end up being "Windows Only" (But I could be wrong about Named Pipes.) That presents a new problem. Instead, a TCP/IP protocol may be developed (or something pre-existing used) to prevent from getting stuck on Windows Only platforms. (In fact, after thinking about it, that probably is what's going to happen eventually.)

Jaguar is still in its infancy - if you are looking at implementing something tomorrow, well, it can't be done. Right now, the idea is to have
something ready to run in the real world by November (when there's a project that would be a great for using Jaguar)

If you are looking for a totally Microsoft free option at the moment - sorry, I really can't help ya a the moment. I plan on it in the future,
it's just not there yet. :) If you want to implement it on WinNT for now, great - I can help ya just as soon as the system is 'stable' and ready for production environments. It's just not there now, mainly because of my pickyness behind my design, and a lack of time. (Now that someone else is helping out with development, that's probably going to speed things up
considerably!) I started Jaguar MMI to handle my needs first, then the needs of the masses <GRIN> My needs are at the moment a WinNT based MMI
package - I figured I'd make that the first goal, then move to the next (Linux). For those wanting to get involved, holler at me and I'll give you
the full lowdown on what needs to be done (which is still alot) and you can help shift Jaguar to fit your needs, as long as the tools are there.

For now - if I were you I'd chat with Rob Martin who just posted that he's doing something similar to what you are needing at the moment :)

Davis Ray Sickmon, Jr
Author, Boulder Panic!, Boulder Panic! 2
President, MidnightRyder.Com

(There is one other option - file formats, etc. are being set so that any programmer who wants to implement an MMI development and runtime package
like Jaguar can just load Jaguar formats and go on if they wish. So if someone really hates the idea of using VB or GB, then implement the Jaguar
MMI Core and external stuff in C. Use the same file formats, etc. and you can make use of the tools we do have as they are available, and we can do the same :) I'll dump ya the internal design stuff as it's available, and you can even make the internals identical if you so desire - that does cut down on the design time. However, new difficulties do come out of doing something like that...)


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Wed, Aug 30, 2000 at 01:53:08PM -0500, David Nimmons wrote:
> Following is my response to Davis Ray Sickmon after he responded to my
> inquiries about the Jaguar MMI he is working on. I decided to post it to
> the general list to see if anyone else is interested in participating.

I'm interested in this as well, and am solidly in the MS-free camp, at least for the server aspects. The clients ought probably to be
platform independent, especially if they use web or other protocols. I've used Perl for the server programming, and Perl/Tk for some simple
clients, in addition to web clients.

I've called my effort a PLC server, with the goal of providing an interface to different types of PLCs and other controllers or systems. The client makes a query identifying the particular site, controller, point, etc., and the server starts up a daemon to handle those queries. Each such daemon does whatever it needs to do to get information from the actual PLC, and returns a response to each query. The daemon might timeout and die, e.g., if the target PLC is remote and accessed by modem, or could run all the time.

The main PLC server sits on a "well-known" port, and dispatches queries locally to the appropriate daemon. The server is configured to support
certain types of PLCs, and looks up the type as each instance is started, so the actual daemon runs code specific to the type of PLC, and also
can be specific to the owner, site, and controller.

I'm inclined to use XML for formatting queries and responses, but haven't (by any means) nailed down the details. Something like SOAP, XML-RPC,
Jabber, etc, might be applicable to the transport aspects, which must address authentication and other security considerations.

On the other hand, HTTP and CGI could be used as the transport and query protocols, as they are fully developed and well supported by browsers.
In my PLC server scheme, this would be done using a web-server client, but that might be more overhead and complexity than the problem calls
for, particularly for supporting one or few types of controllers. At this level, the problem is not very different from standard CGI servers, e.g,. using a database on the backend, so there are many ways to make this work.

This is, I think, not necessarily appropriate for _the_ Linux PLC project per se, so maybe another forum might be identifed, or a new project started, to carry on these sorts of discussions.

Ken

--
Ken Irving
Trident Software
[email protected]


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