XML (was: Re: LinuxPLC:Hardware)

J

Thread Starter

Jiri Baum

Curt:
> Or we could go for buzzword compliance and use XML or something and
> send an order of magnitude or two more data to accomplish the same
> task while invoking 100 times more code.

> Those last two statements were jokes.

Perhaps, but at least for sending, XML would probably be a good idea and not all that difficult to implement.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

Well, if the rest makes sense, I'll certainly ponder the cost/benefit. I do think that this tranparent IO would be a big feature compared to what you have to do with existing products. I do lean towards a low level implementation to save resources and silence the "Ethernet is too non-deterministic" crowd. With any reasonable dataset, on a cheap switched 100mb topology, it would be too fast to worry about.
Give the demon an address and let it fly.
Or as Ron Popiel of Ronco fame says, "set it and forget it".
Is Ronco strictly an American phenomena?

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

I thought it a good idea to state where I'm coming from on this before folks decide I'm hopelessly anachronistic or an incorrigible Luddite. This is an example where by being engineers instead of populists, we can vastly outperform and outsimplify those who are stuck using very general office class solutions because that's the only choice in their world. We have a clean sheet to design lightweight services that "do one thing well" which is the paradigm in the UNIX world. If we were designing word processors, exchanging text and it's metadata, XML would be the tool of choice. For exchanging a limited array of precisely defined primitive data types, we don't have a problem that needs to be solved. Everyone understands integers and floats. Everyone understands sockets. There might be some debate as to UDP or TCP/IP (I favor the latter) but anything with a TCP/IP stack can directly deal with what is showing up across the wire. This could even be handled by software that would fit in a "real" PLC. IFF anyone wanted to do so :^) I feel that can be our edge and a far simpler path to interoperability. True, we will probably have to deal with OPC and XML and the like. This just doesn't seem to me to be an appropriate place to use them. Maybe I'm just crazy.

All of course, IMHO

Regards

cww
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K
On Sun, Feb 10, 2002 at 10:25:29AM -0600, Curt Wuollet wrote:
>
> Jiri Baum wrote:
> >
> > Curt:
> > > Or we could go for buzzword compliance and use XML or something
> > > and send an order of magnitude or two more data to accomplish the
> > > same task while invoking 100 times more code.
> >
> > > Those last two statements were jokes.
> >
> > Perhaps, but at least for sending, XML would probably be a good idea
> > and not all that difficult to implement.
> >
> Well, if the rest makes sense, I'll certainly ponder the cost/benefit.
> I do think that this tranparent IO would be a big feature compared to
> what you have to do with existing products. I do lean towards a low
> level implementation to save resources and silence the "Ethernet is
> too non-deterministic" crowd. With any reasonable dataset, on a cheap
> switched 100mb topology, it would be too fast to worry about. Give the
> demon an address and let it fly. ...

(Gratuitiously reconstructed quoting order.)

As an early voice for XML and long-time lurker on this list, IMHO XML might be useful as a verbose protocol carrying point names, types, etc., as well as values, and therefore allowing looser coupling between information sources and sinks. If operating at wire speed is needed, or if relatively low speed processors are used, then it probably would make more sense to use a leaner, more compact, even binary, protocol, at the cost of tighter coupling between participants. The average desktop-class machines and networks are mostly spinning their wheels anyway, so there's plenty of room for verbosity. A single-board or -chip PLC might be too taxed for such a luxury, particularly if operating at high efficiency, low power, low resources, etc.

Sorry, but I just cringe to hear XML equated with Microsoft products, or programs, or reduced to mere buzzword status. Granted, it's certainly a top buzzword, but there's more (and less) to it, really there is ;) .

On the topic of developing a workable protocol, the archives ought to contain some mention of the beginnings of such an effort. I think it was monikered OIC or the like, for Open Industrial Communications, or was it OIP... I wonder what happened to that?

Ken

> Or as Ron Popiel of Ronco fames says, "set it and forget it".
> Is Ronco strictly an American phenomena?

--
Ken Irving <[email protected]>

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

Curt Wuollet

Hi Ken

Please forgive me. I recognize XML as being separate and distinct and very useful for applications level programming and possibly a bit below. I did try to clarify my somewhat harsh joke in a later post. And I'm glad you can see the efficiency angle. And I was merely using OPC as an example of driving tacks with a sledgehammer. I've been trying to get through the day without pissing anyone off. We agree mostly.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

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

Peter Wurmsdobler

Curt,

> word processors, exchanging text and it's metadata, XML would be the
> tool of choice. For exchanging a limited array of precisely defined
> primitive data types, we don't have a problem that needs to be solved.
> Everyone understands integers and floats. Everyone understands
> sockets. There might be some debate as to UDP or TCP/IP (I favor the
> latter) but anything with a TCP/IP stack can directly deal with what
> is showing up across the wire. This could even be handled by software
> that would fit in a "real" PLC.

I totally agree with you. XML and OPC are overshoots (or do you call it over kills) for exchanging some bits and bytes (floats at a device level is something I do not understand either as most measurements are at max 16 bit, and all digital control can be mapped to u16, IMHO). On a higher, enterprise level, XML and OPC might me more appropriate. Since, however, people in the controls industry were struggling for a common interface, they seemed to have adopted a void container with a label on it promising to be the solution for everything, on all levels. Divide et impera. One thing they forget however: XML is a markup language, and tags etc have to be defined and agreed upon. This is alos true if you define structures to be shipped over a TCP/IP socket. Is there some agreement how it looks like? peter::

--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
D

David Nimmons

How about a usage example.
I am developing a web based HMI to communicate with Allen Bradley PLC's. One of my design goals was to use only open standards and to not need anything special on the client browser. SVG (an XML application) provided a way to do graphics. At present SVG requires a plugin or Java, but, will be native in Mozilla soon. Now that I have my pretty graphics, I need a way to communicate with my PLC's to provide the basic HMI functionality. Once again, the criteria is; open standards and nothing special required on the client browser. The solution I found was XML-RPC (or SOAP as Harald pointed out). With XML-RPC the client browser only needs standard JavaScript and on the server I can use any language I want. This is the only solution I found that matched my criteria. If you know of another way, I would love to hear about it.

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

Curt Wuollet

Hi Peter

I am just counteracting the trend you mention. I agree xML has a place for EDI and perhaps even SCADA. For systems programming, well...... My position is that if we do things efficiently and rationally we can compete much more favorably than those who use the latest buzzword no matter how awful it be in the application. Transparent comms, at this stage is not a general mechanism so I would like to keep close to the hardware and as efficient as possible. The reason for XML is as a common language between applications that need descriptive metadata. That's great and fairly high level. And I see a place for that as a general informtion exchange toolbox. If we do that; let's make it general and try to encompass all the needs we can think of. I would just as soon not group virtual register mapping into that or vice versa. It needs to be fast and it needs to consume minimum resources as it will run continuously in the background. We have no conflict. Jiri had mentioned that he was simply going to send 32 bits for each point. And a count so we can detect out of sequence or dropped packets and call it good. This does imply that both sides know what's going on ahead of time. Beyond that I have not heard, although I am grateful that folks won't be exposed to my coding:^). I'm sorry if I came across as crabby. I've got a concept in mind and would like to see proof of concept before it gets too complex.

Regards

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

Curt Wuollet

Html? Doesn't require a plug in.
Actually that's fine. And there may be no other way to deal with a closed system. That doesn't imply that it's the same way I should do things on an Open System where we _have_ choices. AB and the rest have worse than no qualifications to be our guide on what to do on Open Systems. I don't
understand why we want to copy their approach, tools, methods or anything else they do, as they are all intended to lock in users. I don't have a particular problem with interfaces to iffy or outright proprietary protos. Should we use them internally, IMHO No. Should we depend on them, IMHO No. I fully realize that we will have to communicate with the outside world. The inside world I would hold to a higher Open standard. XML is on the verge of being de facto enough where it can't be manipulated by commercial interests. SOAP is quite a ways from that status. And neither is even relevent, again IMHO, to writing a protocol at this low level. I realize that my view of Open vs Closed is far more binary than the popular view. You can't be just a little closed or a little proprietary, again IMHO.

My choice would be to replace the AB PLC's with ours:^)
Regards::

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

David Nimmons

This has nothing to do with Allen Bradley. It is about developing dynamic, interactive, data driven web graphics. The problem is the same whether I am talking to a closed AB or to the open Linuxplc. The problem is getting data to the browser from the PLC for dynamic graphics and getting commands from the browser to the PLC to provide interactive control. HTML does not provide this capability. XML-RPC is the only open solution that I have found. Mozilla includes an XML-RPC client, and there are JavaScript XML-RPC clients available for that other browser. The XML-RPC server can be written in any language on any operating system. That makes it about as open as you can get. In my particular application, I am using Ron Gage's Allen Bradley Ethernet Library to develop the XML-RPC server. This same technique would work just as well with the LinuxPLC or any other. As I said, if you know another way, I would love to hear about it.

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Dave

Write what you will. I would be very careful about RPC's in general on control systems. That doesn't mean you have to be. I am very much
concerned that we stay as far from proprietary influences as possible. Again, that doesn't mean you have to be. Producing simply another way to extend the status quo isn't very remarkable, it is however much easier than providing an example of an all open platform using all open protocols. As things are embraced by the Linux community as open they become candidates. Things that are championed only by commercial interests remain suspect. I could very well be misinformed or uninformed on some developements and some are unique enough to our situation that there is no community guidance available. But, I have a finely tuned BS detector. Claims for example, that OPC is free and open produce a deafening clangor. Things in any way associated with .NET being a good idea for free projects produces a similar din. From a strictly pragmatic viewpoint, many of these will be good things for interoperability. However, from a strictly pragmatic viewpoint, we should all load Windows and buy a bunch of stuff from AB to do our control. I prefer to retain my idealism wherever possible and hope that it will be enough to produce something exemplary.

Regards

cww

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

David Nimmons

This conversation is becoming very frustrating! It started when you stated that XML was pure hype and had no possible application in control. I responded with an example of where XML related technologies provide very real application possibilities. Then you respond, that because my application is talking to Allen Bradley PLC's, it was not relevant to the conversation. I respond that the technique I am talking about would be the same whether I was communicating with AB PLC's or with the LinuxPLC. You respond with something about proprietary influences and commercial influences, yada yada yada. In my project, I am using only free software, i.e.; Linux, Apache, gcc, Mozilla, Eric Kidd's GPL'd XML-RPC C/C++ library. I, like you, am committed to free software and am trying to make a contribution. The reason I am talking to Allen Bradley PLC's, is because that is what we have in place. The reason I am using XML-RPC instead of SOAP is mainly because of the commercial interest that you mentioned. The reason I am using XML-RPC at all is because it is the only thing I found that matched my criteria of being an open standard and not requiring anything other than a standards compliant browser ( read Mozilla). As I have said on several occasions now, if you know a better way I would love to hear it, but, "talk is cheap, show me the money!"

PS. You say you have a finely tuned BS detector, I think you have your head buried in the sand.

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Dave

I may very well have my head buried in the snow, not much sand around here. Let's sort this out a little.

David Nimmons wrote:
>
> This conversation is becoming very frustrating! It started when you
> stated that XML was pure hype and had no possible application in
> control.

Apparently it started when I got cranky about people inserting buzzwords while I'm brainstorming. I did not say that XML was pure hype, I said it was inappropriate for the low lwvel programming that I am still trying to sort out. I did mention buzzwords in general with predjudice.

> I
> responded with an example of where XML related technologies provide
> very real application possibilities. Then you respond, that because my
> application is talking to Allen Bradley PLC's, it was not relevant to
> the conversation. I respond that the technique I am talking about
> would be the same whether I was communicating with AB PLC's or with
> the LinuxPLC.

I responded to the effect that it would not be the approach I would take on a machine where I had a choice. I would very likely not be interested in dynamic web pages for control. I may have misread and concluded that you were interfacing with what AB provided. I have since heard that you are using Ron's stuff to get the stuff out and rehosting it to a browser client. Is that accurate? I wouldn't do it that way. I don't have any need for that compelling enough to do two way through a browser. I do apologize for the rash assumption that you were doing that because you had to. I now know that you are doing it that way because you want to. I would not do it that way because I haven't seen a browser stable enough for control purposes. It'a a cool enough idea, but I have changed variable with a browser before so I assume there is another way to do it. I wouldn't do that in production either because I haven't seen a browser stable enough. I took great pains to explain my view on XML but for some reason you want me to study the issue enough to tell you another way to do it. I would probably simply write an HMI to do what I need on top of Ron's library.

> You
> respond with something about proprietary influences and commercial
> influences, yada yada yada. In my project, I am using only free
> software, i.e.; Linux, Apache, gcc, Mozilla, Eric Kidd's GPL'd XML-RPC
> C/C++ library. I, like you, am committed to free software and am
> trying to make a contribution. The reason I am talking to Allen
> Bradley PLC's, is because that is what we have in place. The reason I
> am using XML-RPC instead of SOAP is mainly because of the commercial
> interest that you mentioned. The reason I am using XML-RPC at all is
> because it is the only thing I found that matched my criteria of being
> an open standard and not requiring anything other than a standards
> compliant browser ( read Mozilla). As I have said on several occasions
> now, if you know a better way I would love to hear it, but, "talk is
> cheap, show me the money!"

I have no desire to either piss you off or converse about soap, XML , XML-RPC or related topics. I have stated that when it is widely embraced by the community and accepted as meeting the open test, it becomes a candidate in my mind. I have stated that XML is on the edge of that now. If you want me to endorse what you're doing, it's not neccessary. I don't neccessarily agree with all the directions we have taken. When you have been messing with computers as long as I have you tend not to chase after each and every new thing because about 80% of the buzzwords go away in a year or two and after accumulating a certain amount of non-reusable knowlege at great expenditure of effort it's hard to get as excited about buzzwords as I used to. You must remember that everything in computing gets reinvented frequently. There are at least 200 "better" languages than C and dozens of new methodologies, Hell, I was doing stuff before they invented methodologies. I've survived Ada, Modula2, 4GLs, 5GLs, CASE Client-server, data warehouses and dozens of other buzzwords that were gonna make the world safe for democracy. 20 years ago I was in your mindset. 20 years from now you'll be closer to mine.

> PS. You say you have a finely tuned BS detector, I think you have
> your head buried in the sand.

Let's check again in a couple years, If I've ignored vital technology, I'll be the first to admit it.

Or, if you prefer, you're right, I'm wrong, it's only software.

For now can I please talk to Jiri about getting a few bytes from point a to point b with a couple hundred lines of code?

Regards

cww

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