My Observations

D

Thread Starter

Dave Pryor

Rick,

I'm not sure if I agree or disagree. You make some valid points that I don't think I can address. If you are saying let's start over it's a long road back there. If you are saying let's sort it all out and define the direction we need to go in this century, I agree.

Dave Pryor

The Flame suit is yours, but the day ain't over YET!

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Rick

I would like to second Dave's comments about raising our level of professionalism. I have sniped out the ones that were worth repeating.

In addition, I would like to point out IMHO there is far too much noise about what are likely non issues. These discussions are mostly centered
around implementations of 20 year old technology. Most commercial PLC implementations presume that memory, and I/O are expensive, that
commercial micro-processor cpu's are relatively slow, and that application programmers/engineers are relatively inexpensive compared to
the cost of hardware. None of these presumptions are true today so why would we allow them to constrain our design.

I would like to clear the air and ask everybody to take a breath of fresh air. Lets start thinking about what we really want and need in a modern PLC design instead of punishing ourselves for the sins of the past. Simply
put what are our requirements?

Dave, may I borrow your flame suit?

rickj
Mitek


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

Let's sort it out. I am just trying to point out that we should choose our destination before we choose the route.

rickj

"...if we don't know where we are going we probably won't get there"
- Groucho Marx (I think)
 
J

Jack Gallagher

It would be nice to have one centralized document that has all of the decisions that may have been made up to this point. Or at least one person's view of the decisions to start the conversation. From here we can identify what requirements are implied by these decisions. That way we don't lose anything. Am I way off?

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

That is an excellent idea. Something that can be used as a reference instead hunting the list archives. Stan seems to have been involved in the majority of the discussions and seems to have a good overall grasp of where the various threads have gone. Maybe he would be willing?

Dave Pryor
 
M
I am not pretending that it is any where in line with the consensus of the most vocal list members, it is in fact a parallel project that it deals with, but that is at least in part what my statment of requirements document is about.
 
S
Sorry, I have to decline.

I'm on my way out. i have reached the unfortunate conclusion that anything that my result from the current direction of this will not be anything that I am likely to have any use for, or want my name associated with.

I wish you all good luck.

Q for outpts? Wanders away scratching head. & taking .sig with him

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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

Phil Covington

Wow, you really do live in Allen Bradley World, don't you?

It is unfortunate that you feel this way and that you are leaving, Stan. From your activity on this list it's obvious that this LinuxPLC project was
important to you. But, unfortunately, we can't always have our way and your farewell post comes off as a immature "I'm taking my toys and going home" kind of exit. I personally have a different view as to the need for real time extensions to linux, but I am not going to give up on the whole idea because others disagree. Some people feel like they need to have complete
control over a project and their way is the only correct way - but the reality is that people on this group are not your employees or subordinates
and have their own views as to implementation and use of a project like this.

I hope that you will reconsider your decision to leave.

Phil Covington
vHMI



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ahh, Stan, No, Please......
It is my opinion that you are one of the main "powers" here. Your points are always valid and make the coders think a bit more even though some of them seem firmly routed in making things difficult for themselves (and possibly others). I think you will find the project will gell into
something usefull when the "new toy syndrome" wears off around version 0.6.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


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

Davis Ray Sickmon, Jr

Not to sound stupid here, but...

Most projects end up having to meet the needs and desires of many - that is VERY true. No one person runs the project. I also am in an administrator function for another Open Source project (an Operating System) and typically
do things in a very democratic fasion - everyone gets a say on the topic, and we take a general concensus, and that's how direction is decided.
Sometimes that's not enough, and we have someone who's considered the 'head' of the project (Project Lead) who is a tie breaker in case of real problems (or, sometimes, just to set a deadline for when the conversation about it is
going to be over. Otherwise, things can rage on for months over a single small topic.)

But there is yet another option - We'll Do That Later. And one more - Make It An Option. WDTL and MIAO both go along ways to solving debates. The question isn't how to do it, the question is - how to do it NOW, and later, someone can incorporate the optional part later if it's still a relevant issue.

Somethings are too fundamental to be put off or made an option. But, lets face it - Q or O? That's a matter of representation of data, not the hard data it's self. Internally, the Logic Solver is going to be handling bytecode, so, it's not going to care if you see it as Q or O in the ladder diagram, STL, whatever language you choose to produce the PLC program in.

In fact - you can do yourselves one better - make IEC standard an option. IEC says it's Q, among many other things. Screw it - allow the programmer to disable IEC standard, and do it his way. (That's one of the major debates with some people anyways - they want to do it thier way, not nessisarily the IEC way.) You are already discussing allowing the project to support
multiple PLC programming methologies (Ladder Diagram, etc...), so it seems pretty damned reasonable to me.

As for the debate on Real Time handling: some people care if PLC's are deterministic or not. Some people care if the Logic Solver uses RT
extensions, some don't care. So do a code split here. There's a pretty good division of people who want to see it one way or the other. And
garanteed - if you don't do RT extensions, later, someone is going to say you should have. And if you do, someone is going to say you shouldn't have
bothered. This way - you get the Best Of Both Worlds :)

Conceptually, there's going to be very little different between the RT version, and the non-RT version, except for what API's are called.
Secondly, if you only do RT extensions, later on, you can't port it to platform (X) because of them (NT? Mac? Some odd embeded processor that
supports Mobile Linux or Lineo 1.0? Windows Powered? Many of these can easily port stuff to and from Linux these days (With NT, just load up
Cygwin32, and compile that bitch), but don't support the Linux RT extensions. Then you ain't portable, and if you are programming for Linux,
it's always a good idea to keep it portable just to carry on the tradition. Plus, there may be a better library for handling the job sometime off in the future.) And of course, that only really affects the Logic Solver and possibly the I/O services - everything above that (the programming software, the compiler, etc.) isn't going to care if the Logic Solver is running RT or not. And, there's going to be little fundamental difference in design. It's still designed the same way in many respects.

So document it, and add notes as to what applies to an RT version, and what applies to the non-RT version. Then, write the damned thing! <GRIN>

Sorry to interject into something that's pretty fundamental to the project - I'm a newbie on this project, and really don't know what's going on (Ok, that's a lame excuse, but, it's the one that I'm going to stick with at the moment ;-) but I am familiar with Open Source projects (including failures and splits within the group) and alot of times, this is the cool way to fix things up, and get everyone back on track.

Also, I agree with the observation that documentation of your design direction needs to start REALLLL soon. It's a PITA to try and play catch up with everythign that's going on, and even worse, sometimes you end up covering the same territory everytime someone new shows up, plus - sometimes, people actually miss the fact that a concensous was reached at all, or forget what everyone decided to do!

<DONNING FLAME RETARDANT SUIT> Oh, and I'll do one more thing, and probably piss some people off with this one: Smart people tend to have big egos, or just plain strong opinions. <FEELING THE ROOM TEMPERATURE INCREASE> It's
inevitable that conflict happens. When a group of pretty damned sharp cookies get together, there's going to be some head butting. One thing to consider in the direction of a project is how to do it in such a way to minimize the amount of head butting. WDTL and MIAO are two good ways of
letting people with strong opinions go ahead and have it both ways - if they really want to put thier money where thier mouth is, and do the work.

Davis Ray Sickmon, Jr
http://www.midnightryder.com

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

Johan Bengtsson

thanks for writing this one down!

.... and Stan, don't leave for such foolish reasons. If you really feel you don't have any use for the result then of course, but I am not that sure about that...

.... and Dave, pull your feet out of your mouth, or whatever...


/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
 
Stan,

I'm sorry if I have offended you with my post to the group on Tuesday 1/25/2000. I feel badly that you have decided to leave something that you put a great amount of time and effort into. We as a group will have lost a talent, that in my opinion, had much to offer.

I feel personally responsible for that. It was not my intention to flame, embarrass, or belittle you. I have felt that some members of the group had tried to tactfully, and sometimes with humor to get you to tone down some of your remarks. I now look in retrospect that, I myself should have used more tact and not been as blunt and to the point. I should had used more diplomacy instead of defining the meaning. Please accept my apology, and also please reconsider your decision to drop out of the group. We need all the help we can get.

To all the others in this group I also apologize for what I have caused by my poor judgment and blunt words. I see clearly after the fact that it has had a negative affect, and it shows by the lack of message traffic today after 117 messages on Monday. I'm going to back off and put my foot in my mouth where it clearly belongs, and continue to read the message traffic. Hopefully I will continue to learn from this highly diverse and talented group.

My sincere apologies to both Stan and the Group.

Dave Pryor
With foot firmly planted in offending member, cause it won't reach where it belongs.


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

Phil Covington

Dave, no need to apologize... You simply said some things that, I am sure, others that read this group would have like to have said on occasion. For example, your comment about the .sig file... If someone wants to put an
inflamatory statement like that at the end of every one of their messages, then that person better well be able to take the heat... If not - get out of the kitchen!

Not too long ago, I got reminded by someone here that I should be more diplomatic in my posts, so I'll shut up now.

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
J LinuxPLC Project 2
R LinuxPLC Project 3
Top