Status?

C

Thread Starter

Curt Wuollet

Hi all you lurkers,

Is the idea dying? Do we need to start over? Has the vision that this can be done gotten lost in the discussion about how to do it? Have enforcers from the establishment been threatening people? :^) What's the deal? I am concerned by
the total lack of interest as of late. I am searching for what turned this very busy list off like a switch. Is the Automation List the wrong forum for an Open Source development project? What turns you off about the idea?

Regards,

Curt Wuollet


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

Davis Ray Sickmon, Jr

Something to consider the is the whole "Cathederal and Bazzar" concept when it comes to Open Source projects. The first stage of almost any Open Source project is the Cathederal (where proprietary software resides on a permenant
basis). In that time, someone comes up with the whole fundamentals for the project, design it, get it working to a degree, without other people
involved. That ranges from a tech demo or proof of concept to a fully working system. The next stage, after getting to that point, is to move to
the Bazzar, which is where everyone has thier own input, and the project moves off in varying directions as peer-review determines the worthness of additions to the design.

The point is - someone has to somewhere start off with a concrete design, and at least a semi-functional proof of concept or somethign similar to work from. That never happened in this group - more time was spent debating even the most minor low-level implementation concepts. Unless someone breaks down and does the work, this are probably going to remain as they are - a
big discussion area, with lots of people in it, and everytime someone mentions "Let's do it!" everyone is going to discuss what's being done
again, and disagree on it all. What should probably happen is 1 to 5 people who all share the same 'vision' of the low-level implementation of LinuxPLC should get together, develop to the point where people have something to look at, and release it.

Granted - this is just my opinion based on having observed a couple of these projects. I know one that's STILL stuck in the 'lets discuss it' stage for most of it's implementation - after 4 years!

Davis Ray Sickmon, Jr


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
Curt asked:
>What's the deal?

My take on it (as a mostly-lurker, but one with a great interest in the project):
We had lots of (mostly very good) input from a number of people whose role will either be users or contributors of application-level code. This is a good thing -- although these people may not represent the critical resource to launch the project, they *do* represent the ultimate critical resource to make it successful (i.e., accepted and put into broad use).

This input ran its course, to where there may not be much more to chew on until code starts to appear. But (and it's a major *but*), once code
appears, we will have a group of people assembled to play, critique, and perhaps suggest modifications, including a large number of people with hands-on application experience in the PLC domain. This is critical (IMHO), due to the unique nature of automation control -- there are safety and reliability considerations that have been embodied in existing design practice, and we will need to insure that these characteristics are
maintained in our project as well. Further, these concerns vary across industries, so a broad-based source of input and experience is ideal to get a sound perspective on the problem space.

This, of course, leaves the matter of how to get things rolling. As Davis Ray Sickmon, Jr. notes, most successful projects start in the "Cathedral"
(or some semblance thereof), since the initial architectural design of a product really doesn't lend itself to committee processes. A person,
company, or small group decides to put something together, and *then* throws it out for comment (and/or actual use). With our project, bits and pieces have been thrown on the table, but nothing really approaching a full architectural description of the product (perhaps complete with a reference implementation <grin>).

Granted, this is a BIG job. Control.com is willing (and eager) to play a role in the process. I'd go so far as to say we're committed to its success. This means that we will move to fill any vacuums that exist for specific skills, components, resources, roles within the project. We may even play Cathedral, if that's what is required to move things forward. Given Control.com's formative stage, we have a few other things on our plate at the moment -- however, I have to say that support for this project has become a key component in our plans and a major and frequent topic for discussion internally.

I guess what I'm saying is that, one way or another, the project will happen. If someone pops up with a working system to poke at, great. If not, you can be pretty sure of seeing something from Control.com. In the meantime, this forum remains a locus for discussion of what the ultimate product should look like, and the CVS remains ready to receive the result of
anyone's individual efforts.

More to follow over the next few weeks -- probably much more <grin>.

Ken Crater, President
Control.com Inc.
[email protected]



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

Simon Martin

Hi Curt,

I'm working on the SMM and API. I still don't have anything useful, apart from definitions, as my day job has taken precedence lately, but to improve things I have bought myself a laptop and am working on that whenever/wherever I can. I had to install linux and am having a few problems
with the LCD display so I won't be able to upload with CVS, I'll post a tarball when I can.

Simon

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

Jack Gallagher

Hello all,

I am still watching to see what happens. My day job has taken a lot of my free time lately so I have not been able to contribute anything. Although as for what I am here for is some coding, code walkthroughs, design influence (if I can help), and general interest to see this important open source project succeed.

********************************************
Jack Gallagher
SES CO Inc.
3 Vision Drive
Natick, MA 01760
Phone: (508) 650-9147
Fax: (508) 650-9310
e-mail: [email protected]
********************************************

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
I'm a dedicated lurker, and will continue to follow the list, but don't have the means or need to work on the project currently. I look forward to the potential outcome(s) of the Linux PLC project, and I think things will likely pick up when some code is contributed.

The initial flurry of activity had a lot of ideas and directions, and hopefully some actual code with eventually come out of that. I think the scope of the project was hashed out, and hopefully narrowed down somewhat to something attainable.

I don't think there's anything wrong with the concept or timing for the project, but it all may depend on a few productive folks getting the
thing working, and that may take some time.

--
Ken Irving
Trident Software
[email protected]


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

Rick Jafrate

Hi Everyone

Let me toss out some issues:

UML/XML: In Curt's design document he mentions that UML (Universal Modeling Language) will be the output of his programming tool and the
input of his execution engineer. I was thinking on using XML for this purpose. Since UML is a form of XML Curt and I are probably mostly in
agreement. I received a UML CD in the mail from Rational today which I want to explore. What need does XML/UML serve? There needs to be a common PLC source code format that is easily extendable. This will allow for the simultaneous development of the various programming tools and execution engine(s). Comments please?

SHARED MEMORY: I was very impressed by the work being done at AACHEN University that Harald Albercht was kind enough to bring to our attention in an earlier post to this list. I have been pursuing very similar ideas in my work over the past 15 years. The weakness I see in
their work is the real time performance they are able to achieve. I think it is possible to do better performance wise by using a Linux
environment and keeping everything simple and tight from the get go. This kind of infrastructure would provide so many benefits that I don't see how we afford to not use it on this project. Any/every imaginable goal concerning diagnostics, online programmability, usability, development and maintenance tool implementation, execution implementation,
Scalablity, modularity, etc., etc., etc., become some much easier. Comments please?

REAL TIME LINUX: The real time group have developed a means of running an application as a normal user task or as a hard real time task. It is my understanding that it is no necessary to change any of the application code when it executed one way or the other. The only
difference that occurs is that the user space task is subject to the same scheduling and priority constraints as any other user space task. This means that the programming tool could have a check box to select user space or hard real time. In addition a couple of the real time
group have worked out a basic scheme for allocating shared memory that is accessible from user space and kernal space. I think we should plan on being able to use the real time extension. Comments please?

I have been relatively silent and late in producing my initial proposal because I am recovering from a cold that caused me to loose my hearing. I am feeling better but still not hearing very well. I apologize for my absence.

regards

rick jafrate


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

Jack Gallagher

It is my understanding that UML and XML have no relation. UML is a language used to express analysis and design of software. XML is a language for creating web pages. Am I missing something?

The rest of your comments I agree with.

********************************************
Jack Gallagher
SES CO Inc.
3 Vision Drive
Natick, MA 01760
Phone: (508) 650-9147
Fax: (508) 650-9310
e-mail: [email protected]
********************************************


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

XML is a generic markup language. It is extensible and it is used to identify information content. It would easily lend itself to our needs. There is a lot of activity going on around XML therefore there are a lot of tools and source that we could take advantage of. Below are just a few places where XML is being used.

O XML/CORBA (www.omg.org and www.xml.org)
O GNOME
O IEC-61499
O DOCBOOK

Yes, XML could also be made to produce web pages as well as hard copy documentation. Here is the cool thing. If we do it right we could make the PLC source code be self documenting in hard copy and HTML formats.

I am currently researching UML. It was my understanding that XML is used to implement UML but I haven't been able to verify this. Perhaps Curt could shed some light on this as he is more knowledgeable about UML. From reading Curt's document I can't tell if his intention is to be UML compliant or to borrow relevant portions of the UML specification.

When I learn more about UML I will form an opinion and share it with the list. For now I have an open mind.

If we are to succeed we must agree on a source code format and structure that is flexible enough to accommodate future needs and that is easy to
parse and decode. XML is already invented.

regards


rickj

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

Jack Gallagher

Rick,

I come from the other side. I have knowledge of UML but not of XML. The only thing I have read is that it is a replacement for HTML. It obviously has more application than I originally thought and I will spend some time reading up on it. As for UML, it is a specification for a language to express object oriented designs (something I believe the LinuxPLC still needs :) ). I am currently using (and struggling with) UML to design a control center for a Light Rail Transit system.

Thanks for the links. Now I need to find some time to read.

********************************************
Jack Gallagher
SES CO Inc.
3 Vision Drive
Natick, MA 01760
Phone: (508) 650-9147
Fax: (508) 650-9310
e-mail: [email protected]
********************************************

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
XML (extensible markup language) provides a language for defining markup languages, which might be used for many purposes. XML encloses (textual) content between bracketted tags, which may also contain attributes. The specific tags and attributes can be formally defined and verified according to a DTD (document type definition), and the XML document can be parsed, transformed, or otherwise manipulated using various tools. It is perhaps not intrinsically superior to other arbitrary data formats, but it is standard and very flexible, and supported by a wide range of tools. XML is under very active development, but the base standards are well defined and stable.

A couple of introductory links:

Frequently Asked Questions about the Extensible Markup Language:
http://www.ucc.ie/xml/
The most superior FAQ. Everyone seriously interested in XML should start here.

Extensible Markup Language (XML):
http://www.oasis-open.org/cover/xml.html
A useful and authoritative overview of the technology; another good place to start.

As an example, the Dia project, a diagram drawing program for Linux/Gnome which can be used to draw UML diagrams, uses compressed XML as its native
file format. This allows Dia to use standard library routines for parsing its data, and potentially allows that data to be used by other programs.

--
Ken Irving
Trident Software
[email protected]


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

It's a case of mistaken identity, I did not mention UML as an IL. We will probably need some form of intermediate language that the various
languages compile to. I thought the concensus was to use something like instruction list language as the others can be described in that.

Curt Wuollet

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
IMHO, here's the nub of it.

We are in a re-group/consider and develop stage. We've had intense discussions, some of which no doubt put some people off, but which, hopefully have left others with a few thoughts about the direction in which they should go. It is to be hoped that there are a number of us who are
producing at least some code as we speak.

The other point, raised somewhat by Simon, is caused by one of the weak points of Open Source. Unless you are independently wealthy we all have to make a living. At the moment few, if any of us are going to make it from the project (hopefully this will change).

I have done very little work on my project since being laid off, initially opting to spend all my time looking for paid work - and latterly spending
all my time travelling to work and back (I am currently on a short term contract work for ten hours travel for four, sleep for five, study for
three, eat for half an hour, sss for an hour, look for more permenant work for two - er! hang on a minute still not enough hours in the day).

The point is that, hopefully, interest will take off again when there is more to look at. It wont happen overnight but if we are persistent enough
(and I get the feeling that at least some of us are) it will happen.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello Simon Martin,

> I'm working on the SMM and API. I still don't have anything useful, apart
> from definitions, as my day job has taken precedence lately,

Fair enough, would you like me to take over?

> but to improve things I have bought myself a laptop and am working on
> that whenever/wherever I can. I had to install linux and am having a few
> problems with the LCD display so I won't be able to upload with CVS, I'll
> post a tarball when I can.

If you are reasonably sure of your definitions, it might be useful to just post them - even if they don't do anything, others can code to them
(especially if there's enough stubs to compile).


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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

Johan Bengtsson

If I remember previous posts correct XML is in some way related or similar to HTML. To have that as a source format is fine by me but I think the logic interpreter (or whatever) have to have a
byte code format too for faster interpretion and faster/easier online changes. This may however be done by the logic interpreter itself.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Your are right I am mistaken about who had mentioned UML. UML is mentioned my Mark Hutton in his Java PLC design document which is now
accessible from www.linuxplc.org. I would like to apologize to you, Mark, and everyone else for this most egregious error. I will in the future try to be more careful. Thanks everyone for your patience.

Rick Jafrate

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

Harald Albrecht

Hello Rick,

> I am currently researching UML. It was my understanding
> that XML is used to implement UML but I haven't been
> able to verify this.

UML and XML are two different shoes. UML is a modeling language, featuring class, instance and collaboration diagrams, behavioral things, structural things and many other pieces more or
less useful when developing models as representation of aspects of the real world.

XML is a markup language -- and not a modeling language. Nevertheless it can be used to represent UML models in textual form. The Meta Object Facility (MOF) specification, also
maintained by OMG, comes to mind. The meta part of MOF is used to describe meta models, that is, the models behind models. You can use MOF to define your understanding of the concept of a
"class", etc. The UML is one meta model the MOF can represent. So a XML file can now reference the UML -- described in term of MOF "things" (meta classes, etc.) -- and describe your particular PLC class model using UML semantics.

> XML is already invented.

It's a tool but it's not the solution. Has anyone any pointers to tools for handling literate programming using XML? (Reminds me somehow of D. Knuth's "literate programming"...)

Regards,
Harald

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

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