Convergence

C

Thread Starter

Curt Wuollet

Hi all

I've had other demands on my time, but I've been reading the mail, (quite a bit of mail :^) ) and I have been amazed at the interest and enthusiasm. Perhaps it's premature, but I've sensed some fall off in the last couple of days. So I was trying to assess "Where Are We?". as a focusing tool.

I haven't seen anything that really upsets the apple cart although there is quite a diversity of opinion. Here are some attempts to draw concensus on various points.

What's a PLC: When I say PLC it's possibly more general than some people. I take it literally to mean a processor that acquires data, performs definable operations on it and uses outputs to control a task or process. I don't see it in the sense that it has to be restricted to relay replacement or any dogmatic role.

USER Languages: In my original attempt at herding cats, I deliberately stayed away from this as a religious issue. I have seen everything from ladder only to control by extra sensory perception. The question that I ask is, who is going to code all this? To answer fears that your particular favorite might be left out, I doubt that anyone who delivers a working language that doesn't require a complete rewrite of the project will be turned away. What we're missing, and I don't want to discourage those who have done so, are the people who are willing to say, "I will write a ladder language for this project" or "I have the experience and skills to write to order" These will be the players who ultimately determine what happens when.

System Language: For the core, C. I have listened to the buzz and this I get as a consensus. It is also a pragmatic matter. All the languages I have heard of will interface
to C, and most likely, not to each other, so C will be required to provide the diversity that
seems to be desired.

I/O: Everything we can get legally. As a practical matter, I lean towards good fieldbus support but, everything except the most popular will probably be "you want it, you write it" Unless we get a team of really committed programmers who are willing to write to order,
this will probably be expanded piecemeal as the need and means arise. I am going to do Modbus/TCP
because that's what I need. I am hoping that someone who has a lot of (put FB name Here)
will see fit to write it or get it written and share it.. No matter what we might want, there is no means to get it except to write it and you need to have some I/O around to do that. So if you want it, figure out how you are going to do it. Joining together in interest groups can
help here.

Logic: Here, I am of the opinion that conflicting requirements will mean more than one logic engine. The best one for the first pass will be one that provides the information and experience to make the second pass better. Since we know very little at this point about the nagging little real world problems that will profuondly affect what we can and can't do,
to theorize at length at this point and debate about methodology is entertaining but not
remarkably fruitful. Since it seems that everyone agrees that ladder is a must, even in the 21st
century, I suggest that we cruelly limit the first pass to a conventional PLC model and set
definitaly achievable goals in the short term as a test bed for I/O drivers.

General: While I know the project will just die a horrible death if we don't design in everything
everybody wants from the very start, from what I am "hearing" I doubt that IBM and Microsoft
put together could do that. And I'm fairly sure the result would work exactly like some of their products do. And that is totally unacceptable in an automation controller. I believe that, since
the constraints are unknown, the resources are unpredictable, and we have few people with
carnal knowlege of Linux internals that an incremental approach would be best. Do what it
takes to get something basic working and build on that.

Process: I have read a lot of discource that doesn't reflect the Open Source collaborative
model of development. Incremental development is the rule, not the exception. It isn't like commercial development where you decide on the features you want and a team of people build it that way. Instead, many projects come about in stages. One person will code a basic program that does something he wants. Someone else will take that and add what they want. Features are strongly tied to the coder. There are some big
projects where a team of people is assembled and code to order, but even there it's usually
split up by interest and ability. As for the remarks that it's entirely useless if it doesn't
have X from the start, Linux started out as a program that printed "A". While commercial
development is often coded to a final result in one fell swoop, the sucess rate for large
projects is abysmally low. I think the final product will be much better if it is an "interesting hobby" or "niche product" until we have a lot more questions answered and
establish what works. It is almost certain that little of the original code will be final code
and much is thrown away along the way, but, that is why the model produces high quality software.
To use the model, Let's forget about the commercial viability for the time being. When
it begins to get to the point where people might think about actually using it for real work,
we will still have plenty of time for commercialism before it's release quality.
If we don't want to use the model, we should pool all the money we want to risk, hire the best team
available and file for a Billion dollar IPO before anybody knows if it's gonna work.;^)

I personally don't care if it ever runs on a MS platform and I really doubt that a good low
level design for one will ever be a good low level design for the other because they are
totally different as far as scheduling and priority are concerned. The higher level stuff
should be much better in this regard. The folks who want MS may want to build an interface compatible core.

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

Curt Wuollet

Simon Martin wrote:
>
> I volunteer for writing this. Looks like fun...

Bring it on, I'll try to adapt to your code, at least we'll have something concrete to discuss. I'm kinda swamped with day job problems.

>
> ----- Original Message -----
> From: Mark Bayern
>
> <snip>
>
> >OK. We need someone (clearly not me) to write whatever it is I need to
> >access these shared memory tables. Then I could write code to do modbus
> >to/from the io-tables, or ProMux (for Opto22 style 'brain boards'). Ken
> >(or was that Jim ... Ron?<g>) could stick his AB Ethernet data into the
> >shared memory, etc.
> >
> >The shared memory 'core' and the routines to get data in to and out of
> >them, probably do need to be written by a linux hacker.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
Excellent response Curt. I basically agree with everything you said, especially the plan of a simple first pass aimed at getting a testbed and
feedback.

Dan Pierson, Control.com
 
T

Tom Reinecke

I like the idea of a phased/incremental approach.

1. controller featuring one IEC-1131 language (RLL)
2. one reference IO interface, one MMI
3. remaining IEC languages
4. sans-frontiers

It is my observation in open source code development, that you do NOT need up front committment of contributors. Just specify
exactly what (programming) you need done when the need arises, and there will always be someone volunteering, if the goal is rewarding.

Up to #3 it seems like we just reinvent the PLC.
However, PLC functionality is not the limit of what can be done. Once we have established a framework and reference model, this will take-off like crazy with add-on type of development (other languages, IO, fieldbus, MMI, SCADA, ISA-S88 models and structures). Direction is only needed during phases #1 through #3.

Tom

_______________________________________________

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

Curt Wuollet

> I like the idea of a phased/incremental approach.
>
> 1. controller featuring one IEC-1131 language (RLL)
> 2. one reference IO interface, one MMI
> 3. remaining IEC languages
> 4. sans-frontiers
>
> It is my observation in open source code development, that
> you do NOT need up front committment of contributors. Just specify
> exactly what (programming) you need done when the need arises, and
> there will always be someone volunteering, if the goal is rewarding.

Yes, but, most have the advantage of a chunk or prototype that someone has built that forms the keystone of the project. We need a basis that will enable individual developers to work. We need some coding going on soon to focus the project. The stone for the stone soup, so to speak.

> Up to #3 it seems like we just reinvent the PLC.

Guilty as charged, but with an important purpose.
We need the experience and to establish the
working relationships. For example, Many who want
to contribute have never done UNIX programming.
It's not the same as C application programming on
other platforms. This is not a Linux hackers group (yet ;^) )
Cooperative development is an adjustment also. I'm not hearing ioctl's, pipes, processes, IPC's and the stuff that system code is built from on *nix. Many probably don't even have a Linux box yet. Plus, we all can agree that it's one of the goals.

>
> However, PLC functionality is not the limit of what can be done.
> Once we have established a framework and reference model, this will
> take-off like crazy with add-on type of development (other languages,
> IO, fieldbus, MMI, SCADA, ISA-S88 models and structures). Direction is
> only needed during phases #1 through #3.

Exactly

Curt W


_______________________________________________
LinuxPLC mailing list
[email protected]inuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
OK. We need someone (clearly not me) to write whatever it is I need to access these shared memory tables. Then I could write code to do modbus to/from the io-tables, or ProMux (for Opto22 style 'brain boards'). Ken (or was that Jim ... Ron?<g>) could stick his AB Ethernet data into the
shared memory, etc.

The shared memory 'core' and the routines to get data in to and out of them, probably do need to be written by a linux hacker.

That 'core', as you correctly point out is the 'stone'.

Mark


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

Curt Wuollet

Hi Mark and all;

That is what I'm trying to do now . I am writing a first pass driver to grab
Modbus/TCP regs and stick them in the map. Actually Fred's paper shows pretty much what I'm
gonna do for the interface. The code for non RTLinux access will be more or less lifted. Then I do a quick hack to display the page and I've got something to show. This doggone work thing has been slowing me down lately though. I thought
about simply doing a $24.00 DIO card as an example because not too many folks have an Opto rack around, but, the way I got some resources was to do the Opto 22 rack for my day job. By the way, Opto22 mailed me a Linux userland bootp server so I don't need W9X to set the IP any more. They had some encouraging words also. Thanks guys, if you're watching. If we have an I/O scanner running, filling the map, someone could start with a logic section. If someone has PC I/O that would be easier or faster to get going, we can certainly do that.

Regards

Curt W.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
D Process Control 0
W General Automation Chat 0
Top