Questions on my mind

D
There's a danger in trying to overspecify a volunteer project like this. Essentially:

- A lot of people are quite willing to contribute ideas to the spec to ensure that someone else implements their favorite hot item.

- Fewer people are willing to go to the trouble to write or seriously review detailed specs.

- Still fewer are willing and able to do the actual coding :-(

We've already seen a lot of the above on this list...

It's my experience that successful open source projects start with working code. This NOT to say that design is unimportant, just that community design by a committee of the whole tends not to work.

As for a couple of your more specific points:

- While I think that it is important to understand what an initial essential set of components is, I think that it is actively bad to try to define all possible/allowed components at this stage. We don't know all the answers and we don't want to discourage good ideas from people with unexpected answers (this is a set up for my next point). What is important is to develop a genuinely open architecture that will allow these as yet unknown people develop their components and make them work with everything else.
Unfortunately, the best way to develop that architecture is experiment and evolution. Prior specification sounds good but I don't believe it will work in this type of environment. Objectors are invited to produce concrete counter-examples :)

- IEC 1131 has an important role to play in the projects' future. However, it is not central. Implementing the whole thing would be a VERY large
undertaking. I think it will happen over time, but not all at once. Secondly, IEC 1131-3 is a backward looking standard that makes some attempt
to standardize old ways of doing automation control (the PLCopen Portability Level Certification looks like it may finally make this standard useful to end users -- IMO, a "standard" with no defined portability is not a standard
at all). Those ways are very important to many members of this list. Effort should and will be put into implementing them. However, there are
other approaches that some of us feel offer substantially higher productivity than any of the IEC 1131 languages. State based languages are
an example that Curt mentioned recently and that I have some experience with. I hope to see some of these approaches implemented as well as
variants on RLL + function blocks.


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

I disagree a bit here. First of all, I don't think making the project that broad would be a good way to focus the thought train. Second of all, IEC 1131 also has a specification that basically allows flowchart based machine control.
Let me tell you from first hand experience that I wouldn't wish that programming methodology on my worst enemy. Here in the states, there are laws against cruel and unusual punishment.

Ron Gage - Saginaw, Mi
([email protected])

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

Phil Covington

> Thanks Phil,
>
> And I agree with you that no one should be discouraged from contributing.
> My problem is, how do we reconcile the two. If embracing Hugh's code
> would take the project in a direction that discourages C programmers, what
> do we do with it? If you look carefully at my remarks to Hugh, that's all
I
> said. And I still have the problem. In the end, I just tried to be
consistant.
> All C++ programmers can work in C, but, not all C programmers can deal
> with C++. And, more than a coding issue, it's a design issue. I can read
> C++ to some degree, but, I don't think in objects and it's not optional
for
> an OO design. Hugh seems deeply committed to OO. What do you
> suggest? I'm not happy with either choice when we don't have a C code
> base. Perhaps Hugh would like to recode, but, that's too much to ask from
> a volunteer. I also would prefer light, tight, and small so SBC's with
> flash disk are an option where "hardness" is a requirement.

Take a look at io.cpp and io.h of Hugh's code. Right now his I/O is the keyboard and the screen. This is where real world I/O can be attached. Anything that is coded in C that deals with real I/O could be interfaced there. His code does not cover the I/O and memory mapping of the LinuxPLC and is really just one of the many logic engines that could be used. Your code that deals with the digital and analog I/O obviously is the foundation of the system and should definitely be coded in C. The logic engine(s) can be coded in whatever, but one of the implementations could be Hugh Jack's code. That doesn't stop other people from working on implementations written in C. I just think that Hugh's code should be added to the project. I was not proposing that the whole LinuxPLC be based on Hugh's code.

> I too agree about data structures. A lot of the early discussion was
> regarding the map and how it looks. I think that kinda got out of control
> and caused premature confusion (we'll have plenty of time for
> confusion later) What I propose is a simple, extensible, small set of
> structures that everyone can deal with. Adding more members to
> a struct is relatively painless. Let's not worry about replication, forcing,
> volatility, or other "feature set" needs at the moment, just a simple model
> to get the ball rolling with the understanding that it's an incremental
> development process. I have been working with a simple struct of
> arrays of various types to accomodate digital and analog data from
> I/O. I know I can always add to it. PLC's, from what I've seen, like
> to model everything as a register. Would this be a good bridge from
> what most people are familiar with to something better ?

The code that deals with the I/O (digital and analog) is the foundation on which the rest will be built. It is critical that this be coded so that people has something to work to. It would be great just to have a defined way of interfacing to I/O and shared memory. I agree with you that a simple model is the way proceed.

Regards,

Phil

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

Johan Bengtsson

Hey!
SFC is a good thing to use for the types of machines where it makes sense. A lot of machines do NOT fall in this category while other do. The right tool for the problem at hand is always the
best to use, that won't mean other tools isn't useful. You don't need to use it, but I want to be able to in the future... If I ever find the time for it I can do that part... :)


/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
 
Sheldon Gill:
> Firstly, e-term is only one application which provides direct support for
> the feature. There are other apps out there. I believe it's a feature of
> Enlightenment as well. It's a standard feature in Aqua, the MacOS X
> graphics system. The idea didn't originate with e-term.

The traditional use of the feature is a clock which has a round window rather than square. Most X11 analog clocks have that option.

The traditional toy with this feature is xeyes, which has a Cheshire-cat style pair of eyes (just the eyes, though), in a window consisting of two
ovals (left eye and right eye). The pupils of the eyes look toward the mouse pointer.


None of which is really relevant.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Jose Fernandez

I agree almost all with Dan and Ron have written in theirs comments to my e-mail, I have to recognize that it could be misunderstood due to the form I wrote it. But I just was thinking that some guidelines and some scheduling could be done, of course via the convicing not by the imposing, and I think that the IEC 1131's are a good guidelines for our project, of course, we
don't have to read completely all the 1131's, I think it would enough to read a couple of pages and analyze a couple of figures on some parts of the IEC 1131 mostly the third and the fourth, or for example read some introductions as I have found in the PlcOpen.org.

In other hand personally I am interesting a lot in this project and eager to help a little, that's it. How Could I help?, Could some Puffin help me?.

Offtopic:
Please consider this as my excuses to my e-mail, and please don't consider that e-mail as a "cruel and unusual punishement", so I would like to avoid a trial against me due to the violation of the USA "laws against cruel and unusual punishment". I last a couple of "cruel days" thinking which would it be the punishement against me due such felony, might be a "death
sentence"?
BTW: Would it be there in USA "Laws against cruel and unfair charges"?


Regards

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