Issues for discussion

R

Thread Starter

Rob Martin

I'd like to contribute the following suggestions for discussion:

Design:

1. P-Code. We may wish to totally separate the execution environment from the development environment by coding a control engine that runs from p-code generated by whatever tools we desire and create. Then, we can independently create the development tools and compilers to suit our fancies. This of course gives us performance somewhere in between compiled code and
interpreted code, while offering the flexibility to cross platforms and port control applications to other environments more easily. I don't think this will entail a performance hit, unless we're seriously expecting the final executable program to be compiled to machine language.

2. Driver prototypes. Forgive my weaknesses in programming and kernel theory here, but can we create a meta-driver that runs at the kernel level
(I think it's scheduled under SCHED_FIFO or SCHED_RR; isn't that how RTLinux does it?), but expect driver developers to provide a "Wrapper" to the prototype, which might be restricted (or optionally restricted) to UserMode? Regardless of whether I got the kernel parts right, applying modularity here will make driver development faster and easier. If we start with the
meta-driver and wrap Ethernet and serial on that as a start, I think we're doing great. Maybe then some of us with hack a few proprietaries and create open drivers for them.

Administration:

1. Specification. Is a draft specification started, or must one cull through the discussion threads and guess what has been -- at least
tentatively -- adopted? Can we provide a web page highlighting what we know we know, what we think we know, and what we have to decide?

2. Structure. Has anyone in this group participated heavily in an widely distributed open-source project? Does anyone "know the ropes"? Perhaps we should acquire/invite an experienced mentor to help guide us through? He/she doesn't have to run the show, but it'd be nice to be able to consult with a well-informed advisor.

3. To-Do list. Yeah, I know the "to-do" list would be comprehensive :) and the "done" list is skimpy (but definitely not empty!) But we do need a master list of what needs to be done, who's committed to working on items, and what's the status of each item. This should include development items as well as administrative items (plus docs, testing, etc...) Should we organize
with milestones?

4. Participation. Anyone we should specifically invite? Two names come to mind: Tim Hohmann of AutomationDirect.com and Robert Oglesby of Host Engineering. These companies come as close to open source as I've seen among
big controls companies. (After all, isn't AutomationDirect's motto "Almost Free PLC's"? And, they have PC stuff too. And, they have a habit of facing off against the kind of companies that probably won't embrace an open sourced control system.) I don't work for these companies, but I suggest they might be good friends to have. Anyone else we should invite from the controls industry? How about the commercial Linux people. Does anyone thing
that Bob Young might want to see discrete manufacturing in a Red Hat? What about VA Linux Systems? Should we invite anyone at all?

5. Commercialism. I plan to sell my "on-the-clock" participation to my boss (who's personal approach has been closed-source) by pointing out that the trade for writing free code is early and frequent market exposure. This is not to say spam, so much as reputation. We're not creating a hobbyist package, or something for the scientific or academic markets. We have the potential to create a top-notch family of products that could ultimately reform industrial control much as Linux has reshaped IT and to a lesser extent, the desktop. Although we are not necessarily looking to sell code, some of us will want to sell products and services complementing this project. We will want to leverage our involvement commercially in industry. Rather than "checking our commercialism at the door", can I propose that we ask Ken for a "coat room": a database of member-participants, where we can identify who we are, what we're doing, and where we work?

Personally, I spent too much time watching Linux (5 years) and not enough time jumping in and doing it (6 months). Hence I still haven't plied much of my admittedly weak C skills to Linux specifically, and I'm far from expert at the inner workings of the OS. However, I've been doing embedded and industrial controls programming for the last ten years and I know how to program both PC's and PLC's. I also spend a good deal of time with customers, from sales and specification to training. I don't know if I'll
have much to offer in coding, but we'll need a repository of documentation very soon, and I want to be involved.

One final note: The enthusiasm shown in the last 25 days is astounding. It says a lot about the viability of this project, and about the people
involved. I think the LinuxPLC project is off to a great start!

Regards,

Rob Martin
[email protected]

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