Questions on my mind

C

Thread Starter

Curt Wuollet

Hi all

Since we don't have a problem with overtaxing the list server and the progress of the project has been on my mind a lot lately and the Ethernet I/O I ordered has not arrived so I can't push it out of my mind by hacking. I thought I'd bring up some
of the questions that bother me as a way of checking their relevence. It's mostly philosophical, but I am interested in how the group feels.

Big question: Can we do this? The automation crowd doesn't seem to care much about Open Source and the Linux crowd has few members who care about automation. Is there a large enough intersection to support the project ? And, yes I know you guys are that intersection.

Does the why and how matter? Should it be anything goes? Am I being too idealistic in rejecting MS ip and upholding the GPL? In trying to stick to traditional *nix principles and methods? Free tools? Community ownership? The C langusge?

Below I am referring to the Automation List members, this list is a selected

Is this the right place to find people? Obviously the wealth here is in automation knowlege. Like most groups of technical folks, the group is highly opinionated. Made up, for the most part, of
highly competitive people who pride themselves on doing it better than the other guy. Can you build a team from that population or will it be like the industry it reflects? Examples::
Failed consensus on fieldbus, extreme commercialism. Could we find a niche with less cooperation and more competition?
Was starting it here a bad idea?

Those are the ones that are upmost on my mind. I'll share my answers later.

Regards

Curt Wuollet.



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Absolutely we *can* do this. The unfortunate things are most of us have jobs that don't allow us the luxury of doing "side projects" in our spare time. For example, in my position, I am almost never able to do ANY coding. Mostly
pushing paper (and lots of it - of late). Then once we get home, there are things that "compete for resources". For an example in my case, please see http://home.att.net/~rongage/pics/p0000148.jpg

If I had to guess, with the notable exception of Jack Hugh's contribution, I would expect something workable in about a year from now. Not a finished project, but something demonstratable "from the project".

> Does the why and how matter? Should it be anything goes?
> Am I being too idealistic in rejecting MS ip and upholding the
> GPL? In trying to stick to traditional *nix principles and
> methods? Free tools? Community ownership? The C langusge?

Speaking personally here, I see the MS/GPL thing as largely irrelevent and possible a hinderance (as far as GPL is concerned). While traditional *nix principles and methods are valid and respectable, using the GPL is kind of like
forcing those principles and methods down someone elses' throat. This is an idea I am not tremendously thrilled with personally (and the primary reason why my code doesn't use it). People should share because they *want* to, not
because they are *forced* to.

As for the "language wars", my personal opinion is that the code should be readable by anyone, experienced or not. Yes, things can probably be done better and more efficiently in C++, but it helps raise the "barrier of entry" by making the code harder to understand to the beginners. I consider myself one of those "beginners" - I find c++ extremely hard to follow/understand.

> Below I am referring to the Automation List members, this
> list is a selected

You would be surprised how may people are "lurking" in the list. Besides, doesn't Ken (Crater) have posting to the list show up on the web page at www.control.com? We have a larger audience than we may realize. They are all just waiting at the side lines.

> Is this the right place to find people? Obviously the wealth here
> is in automation knowlege. Like most groups of technical folks,
> the group is highly opinionated. Made up, for the most part, of
> highly competitive people who pride themselves on doing it
> better than the other guy. ...<clip>... Was starting it here a bad idea?

As long as you have people involved, you will have ego/opinions. Enough said there.

The point should be that the project needs to start "somewhere". Someone needs to take the lead and just say "here is what we are doing *first*." Other things can grow from that one thing but the start must occur first. We also
need to be careful not to overdesign the thing in the beginning. While it would be nice to have a PLC-5 or a 984 in software, maybe we should settle for a plc-2 or a 484 just to get the ball rolling...

Enough of my babbling for now, time to go visit my sister for the day.

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

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

Ralph G. McDonald, P.E.

> Big question: Can we do this? The automation crowd doesn't seem to care much about Open Source and the Linux crowd has few members who care about automation. Is there a large enough intersection to support the project ? And, yes I know you guys are that intersection.

>> **Yes it can be done, but it may reqire small bites at first. If you can break it down into digestable chunks. The first PLC that I used was a Texas Instruments 5TI with 256 words of user RAM. It had a small programming panel that allowed you to enter the programm. Load, Store, And, Or, Not and Timer and Counter if my memory is correct. It still saved my employer $12K over 20 years ago. Currently most of my PLC experience is in Water and Wastewater with some Chemical Plant Process Control. I will make a modest proposal based on that experience as a specifier/designer/PLC & HMI programmer.

If you would start with a small core program that inputs from a input image data table, correctly processes the control logic, and outputs to an output imiage data table and repeats the cycle.

then add the modules to take the output image and write to actual outputs and read actual intputs and copy to the input image table. Things like programable input contact debounce could reside here if required. This could be done with driver modules for local (RS-485?) or remote (TCP/IP) I/O.

Add ability to handle simple analog I/O and we have a system that can handle small water/wastewater pumping stations.

Add a module (TCP/IP?)to allow remote monitoring and modification of data tables and we can start to add HMI. With a simple serial port driver we can use small local operator interface to monitor / set items like pump on/off levels

I could go on with recommed modules untill you have a system that could handle a major metro water or wastewater system with HMI, local and remote control and data collection, etc but I think you need to start small and work up. Use intermodule communications that allow the modules PLC core / I/O processing / Comm / HMI / Database / etc to reside on the same processor or different local or remote processors. This gives the designer/specifier/user the ability to pick the right combo for a giver project.

> Does the why and how matter? Should it be anything goes? Am I being too idealistic in rejecting MS ip and upholding the GPL? In trying to stick to traditional *nix principles and methods? Free tools? Community ownership? The C langusge?

> > I am afaid I can't comment here because 12 months ago Linux was only a word to me until my oldest son introduced it to me and I am still learning in my "spare" time. My lanquage of 1st choice for a contol application would be forth. I think that the idea of free tools etc is great. I am afraid that I am a old dog (53) still learning new tricks but it sometimes takes a while.

> Below I am referring to the Automation List members, this list is a selected
>

> Is this the right place to find people? Obviously the wealth here is in automation knowlege. Like most groups of technical folks, the group is highly opinionated. Made up, for the most part, of > highly competitive people who pride themselves on doing it better than the other guy. Can you build a team from that population or will it be like the industry it reflects? Examples::

> Failed consensus on fieldbus, extreme commercialism. Could we find a niche with less cooperation and more competition?

> Was starting it here a bad idea?

>> No, but I just found it here last week by doing a Google search with Linux & PLC

> Those are the ones that are upmost on my mind. I'll share my answers later.

> http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Gilles Allard

I would add a third dimension to your model. Age. I'm from a generation where good workmanship would bring pride and quality was a goal. In the
actual generation, "time to market" and "return on investment" and "stocks" are the goals.

An engineering supervisor will prefer a system that will not crash while the young engineer (or programmer) will prefer nice icons, 3D sound and
other gadgets. Since they were educated with MSoft model, rebooting twice a week is a normal annoyance. (I'm referring to Ziff-Davis Lab
report where they say that Win95 would crash every 2 days (average) while NT has to be rebooted every 5 days).

The big problem is that mature engineers are not active coders; they probably all know C and possibly C++ but are not proficient (in
programming) anymore.

It would be interesting to know the age of the most active participants in this group.

I'm 48 and I think pride is more important than short-term profitability.

Gilles
ps: My employer is a system integrator specialized in industrial automation. Our applications are running 365X24 (almost). We have some some clients still running applications designed 15 years ago.


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

Jack Gallagher

> <snip>
> I would add a third dimension to your model. Age. I'm from a generation
> where good workmanship would bring pride and quality was a goal. In the
> actual generation, "time to market" and "return on investment" and
> "stocks" are the goals.
>
> An engineering supervisor will prefer a system that will not crash while
> the young engineer (or programmer) will prefer nice icons, 3D sound and
> other gadgets. Since they were educated with MSoft model, rebooting
> twice a week is a normal annoyance. (I'm referring to Ziff-Davis Lab
> report where they say that Win95 would crash every 2 days (average)
> while NT has to be rebooted every 5 days).

First I want to make it clear that I am not overly upset about this comment, but I do feel very strongly about my point. I take exception to this age biased comment. I am not a preacher for political correctness. I just want people in general to stop stereotyping! I obviously grew up with this "model" that you speak of, but I absolutely do not believe that systems should need a re-boot. Systems should mature over time and become easier to use, even if this means adding an icon here and there. Do we really need to type on the command line for the rest of our lives for something to work properly?

As for the argument about C and C++, I feel both have value. For small projects, like a utility, C is great. For large projects that must support
scalability, C++ is a better choice. Of course, as a few have stated before, C is more widely known. I don't really have a concrete opinion on
which is better for this project (although I may have stated at least one before :)). I can say that my preference is C++. At this point I don't
care anymore, I would just like to see some more progress on a design document. I also think a bigger issue that I see with programmers is that
most (not all) of the self taught ones do not have a good knowledge of data structures. Data structures are more important to robust programming than the language used. I hope I am not offending anyone. I am merely stating
an opinion.


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

Phil Covington

<snip>

> An engineering supervisor will prefer a system that will not crash while
> the young engineer (or programmer) will prefer nice icons, 3D sound and
> other gadgets. Since they were educated with MSoft model, rebooting
> twice a week is a normal annoyance. (I'm referring to Ziff-Davis Lab
> report where they say that Win95 would crash every 2 days (average)
> while NT has to be rebooted every 5 days).

I use software as a tool to get things done and I put stability high on my list of requirements. While I might believe that Win95 needs to be rebooted every two days on average, we run WinNT4.0 systems 24x7. I just did an uptime check on my W2K box here at home and it has been up 37 days, 6 hours, 9 minutes, 33 seconds and I program heavily on this system with daily use...
I think the last time I shutdown or rebooted is when I downloaded BeOS and installed it to try it on this machine. Of course, my Linux machines all
are stable too and I am happy with them also.

I personally know a few young engineers (they work for me) that would consider having to reboot as often as you suggest totally unacceptable.
Your generalization of young engineers (or programmers) as somehow having less interest in workmanship and pride in a job well done is simply hog wash! (Sounds like something a grumpy old fart would say.)

> The big problem is that mature engineers are not active coders; they
> probably all know C and possibly C++ but are not proficient (in
> programming) anymore.

Here you go making sweeping generalizations again!
I also know of a few "mature" engineers that *are* active coders and can still run rings around the younger guys ( one also works for me )...

> It would be interesting to know the age of the most active participants
> in this group.
>
> I'm 48 and I think pride is more important than short-term
> profitability.

I don't know why this make any difference, but I am 35...


Regards,

Phil

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

Phil Covington

<snip>

> As for the argument about C and C++, I feel both have value. For small
> projects, like a utility, C is great. For large projects that must
support
> scalability, C++ is a better choice. Of course, as a few have stated
> before, C is more widely known. I don't really have a concrete opinion on
> which is better for this project (although I may have stated at least one
> before :)). I can say that my preference is C++. At this point I don't
> care anymore, I would just like to see some more progress on a design
> document. I also think a bigger issue that I see with programmers is that
> most (not all) of the self taught ones do not have a good knowledge of
data
> structures. Data structures are more important to robust programming than
> the language used. I hope I am not offending anyone. I am merely stating
> an opinion.

I agree with Curt's argument that by having C as the "official" language of the LinuxPLC it will open development to the widest group of programmers. But I don't think that someone should be discouraged when he contributes
code to the effort that happens to be in C++ ( ie. Hugh Jack). It is not like C and C++ are all *that* different when it comes to C coders trying to figure what is going on in a C++ program. About 30 minutes of reading will clear up most confusion.

You point about data structures is very true... understand them and then pick your programming language. (I think that programming languages, like operating systems, should be chosen for the particular job you are trying to do. Not *one* programming language or *one* OS is good (or applicable ) to everything.)

Regards,

Phil

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

Alex Pavloff

> An engineering supervisor will prefer a system that will not crash while
> the young engineer (or programmer) will prefer nice icons, 3D sound and
> other gadgets. Since they were educated with MSoft model, rebooting
> twice a week is a normal annoyance. (I'm referring to Ziff-Davis Lab
> report where they say that Win95 would crash every 2 days (average)
> while NT has to be rebooted every 5 days).

I've been lurking on this list because the idea of a Linux-based PLC is a good one. and really take exception to this. I'm a young (22) programmer, and quite honestly, I think your stereotype is just plain wrong and demeaning.

Firstly, I'm surprised that you didn't use the oh-so-witty M$ tag that many people seem to use, because it sure would apply here.

Secondly, you say "educated with the MSoft method". What method is that? In all the classes in college that I took, only one (a graduate level course dealing with COM) had anything to do with Microsoft. It was all done on flavors *nix. (Side note: the people who talk about the free and open nature of Unix really need to check history books -- Linux is free and open, other *nixes less so). Maybe you're referring to the fact that we're a generation that have grown up with computers that were finally simple enough
for non-technical types to use, and have been "spoiled" by this.

I will not argue that there are those that think that "more flash" will make their program better. They're probably the same people that will use those new translucent windows that Windows 2000 will let you do (has anyone seen t
hese? What the hell are they good for?)

These people are all ages though. We've all heard the stories about managers making programmers put flashing bells and whistles in their software. The entire industry has this problem, not just the "young" programmers.

Alex Pavloff
Software Engineer
Eason Technology


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> I will not argue that there are those that think that "more flash" will make
> their program better. They're probably the same people that will use those
> new translucent windows that Windows 2000 will let you do (has anyone seen t
> hese? What the hell are they good for?)
> Alex Pavloff
> Software Engineer
> Eason Technology

Alex:

Believe it or not, this is Window's copying a "feature" from a Linux program - specifically e-term. Check it out - http://www.eterm.org/pics/careys.jpg
Eterm allows you to have a graphic image as a background that scrolls with your text. It also has a "transparency mode" where you can see through the eterm window.

I agree though, it's neat, but of very limited practicality.

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

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

Sheldon Gill

I just thought I'd wade in here and make a couple of points.

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.

Secondly, the real idea of translucent windows in a GUI is to visually show child/parent modal relationships. Child windows, like dialog boxes, which prevent entry into the parent window should be translucent so that it's immediately apparent to the user that the parent window is blocked and that the child window must be dealt with first. The translucency also helps overcome the issue of a window popping up and obscuring the context in which it appeared.

It is a HMI feature which, when used intelligently, can improve usability.


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

Gilles Allard

Jack Gallagher wrote:
I take exception to this age biased comment.

Phil Covingtlon wrote:
Your generalization of young engineers (or programmers) as somehow having
less interest in workmanship and pride in a job well done is simply hog
wash! (Sounds like something a grumpy old fart would say.)

Alex Pavloff wrote:
I'm a young (22) programmer, and quite honestly, I think your stereotype is just
plain wrong and demeaning.

I reply:
I'm sorry for those who are offensed. English is not my primary language so I may make mistakes. Where I used "age", I should have used "cultural generation" and when I used "Cultural Generation", I should have used "trends".
My point was not that young people are not serious. It's more that modern trends are not serious.
Sorry
Gilles


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I am afraid, that usage of quasi "politically correct" terminology makes little difference Gilles. You will have to learn that values - interest in workmanship and pride in a job well done - are independent on age(=generation). I have seen all types of trends in all age(=generation)
groups.

Petr Baum

another lurker (58)

English is not my primary language too.


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

Johan Bengtsson

YES!
I think it is possible, people will rewrite code that they think they can write better than their neigbour, chances are that the "best" code for each task will "win" (missunderstand me correctly, it is NOT about a winner in some kind of competition, it is about bringing forward a useful tool for controlling machines/processes and such in the real world)

The main key to this (as I think it is at least) is that people start out with writing initial pieces, tries to connect them and are prepered to throw everything in the first attempt(s) away as a test run _n order to learn how to move forward.

The end user (who is the end user anyway) may not care much about open source, but the one in the middle might, that is the one putting everything together. I think open source or not might be an uninteresting topic for most people in the
chain of people having anything to do with the decisions but eventually it will be enough if some of the people say open source, the rest won't actually care as long as someone else guarantees it will work. Ok, I am not actually an end user for this kind of product (I am an educater in this area).

I personally think the biggest problems is:
1. A normal PC is built for desktop use and not suitable for control of anything that need to run at least 245440 hours for the next four years or is even remotely dangerous. A soulution to this would be specialized hardware, nothing I can see prevents someone to build their specialized hardware suitable for this and put linux on it together with this project earn money for the hardware and I/O modules as well as support for the entire thing.

2. This is cut from a mail, I think from automationlist:
Rubbish. You can waste hours sorting out problems with MS techology, and everybody symatises with you......
but block a system for half an hour with a non MS solution
and everybody is saying why didn't you use.......
It's like IBM 20 years ago.......

People tend to not leave something they are familiar with if they don't really have to. And in most cases when it comes to automation they don't have to. If it ain't broken....



----------------------------------------
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
 
J

Jack Gallagher

Gilles,

<< on political high horse>>
I only hope that everyone will avoid making any type of age (or generational) generalizations. There is no room for them in this world and
they only hinder personal and professional relations. Everyone is different and unique.
<< off political high horse>>

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

Curt Wuollet

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.

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 ?

Regards,

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
I think that people are tending to draw too many absolutes in this discussion. The project naturally consists of an unknown number of
cooperating components, and thus cooperating subprojects. There is no reason that all of these pieces have to be written in the same style or language. There ARE good reasons why they need to have common interfaces so that they can talk together. Here are my opinions for a few subprojects in order of core importance (and probably order of implementation):

- Drivers and Core IO: These probably do want to be written in C. Efficiency is important, complexity is moderate at most, cultural familiarity to hard core Linux developers is highly desireable and portability to other OSs would be nice. C is a well understood common language in this domain. How to make it efficient and portable is also well understood. Using GCC extensions when required would be defensible because the Linux kernel already depends on them, but it would hamper portability a bit.

- Logic Engine: Probably also wants to be in C (possibly with gcc extensions) for the same reasons as above. It is possible that a future
logic engine might be kernel mode, so I'd think carefully about library and user space interface dependencies. Others might not choose to worry about this.

- Compilers, comm. utilities, etc.: Doesn't really matter what the language is. There will eventually be a number of these. Getting an initial set working quickly is very important. Programmer productivity and code evolution are very important. Efficiency is not very important initially because initial programs will be small and machines are pretty fast. Portability will matter, but many languages are more portable than C.

- IDE's: Language matters even less than above. GUI toolkit matters, but only for portability and ease of installation -- Tcl/Tk, Java/Swing, and
wxWindows are all decent candidates depending on implementor preference.

In all cases the odds of other people helping out on the piece will be affected by what language and tools you use, you have to trade this off
against your own productivity in getting the thing out there in the first place.

Dan Pierson

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

Alex Pavloff

> I'm sorry for those who are offensed. English is not my
> primary language so I may make mistakes. Where I used "age", I should have
used
> "cultural generation" and when I used "Cultural Generation", I should have
used "trends".
> My point was not that young people are not serious. It's more that modern
trends
> are not serious.
> Sorry
> Gilles

As another person said, its not the words your using. You're saying the same thing.

"Young people, in general, don't have the same commitment to quality that older people do."

Will I argue that there aren't young people that don't care for quality? Of course not. However, all the people that don't care about quality don't
stick around long enough to become "old" (no disrespect intended to anyone <g>). Therefore, a statement like "people that have been around in X
industry for a long time are more experienced/more concerned with quality
than those that are just started" is, well, yeah, duh, valid no matter what you do.

And now, because being on-topic is always a good thing, I want to add my comments to the state of this project.

1) This is a LinuxPLC, but honestly, I don't see anything that this PLC does that would tie it to any specific operating system. Sure, open-source
windows software ain't in vogue yet, but I think that more people would become interested if the platform-independence was pushed a little stronger.

2) Realtime-ness (is that a word) -- is this PLC planned to run under RTLinux or something like that? We do some control in my company's software
(not real time), and while I'm not experienced enough to know what's considered essential, I do know that a Linux PLC talking to hardware devices
ain't going to be able to go much faster than the timer tick, currently defined as 10ms.

3) As someone else mentioned, you've got to start small. My experience with PLCs is writing serial drivers to talk to the things. But trying to make a Linux, open-source version of a top-end PLC is probably a little beyond a first attempt.

Just my $0.03

Alex Pavloff
Software Engineer
Eason Technology


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> 1) This is a LinuxPLC, but honestly, I don't see anything
> that this PLC
> does that would tie it to any specific operating system.
> Sure, open-source
> windows software ain't in vogue yet, but I think that more
> people would
> become interested if the platform-independence was pushed a
> little stronger.

In the long term platform independence is good. In the short term, Linux is the most friendly platform to develop under from the viewpoint of many/most (?) people in the project. This is largely because the OS interface issues are there in plain site instead of hidden in the proprietary code base. Some of us would also argue that the Linux toolset is better for this type of development. Some are also idealogically committed to working on a non-proprietary platform.

>
> 2) Realtime-ness (is that a word) -- is this PLC planned to run under
> RTLinux or something like that? We do some control in my
> company's software
> (not real time), and while I'm not experienced enough to know what's
> considered essential, I do know that a Linux PLC talking to
> hardware devices
> ain't going to be able to go much faster than the timer tick,
> currently
> defined as 10ms.

You're right. However this has been endlessly debated on the list. There are some applications that may be perfectly comfortable with a PLC cycle on the order of 50+ ms who could run on standard Linux. Others with stricter
requirements might be OK with a tweaked scheduler and locked down memory such as KURT. The most stringent requirements will need something like
RTLinux.

The initial question is "can we get off the ground with standard Linux?". The answer is probably yes, however it's important to design for movement to various RT variants later on.

> 3) As someone else mentioned, you've got to start small. My
> experience
> with PLCs is writing serial drivers to talk to the things.
> But trying to
> make a Linux, open-source version of a top-end PLC is
> probably a little
> beyond a first attempt.

Exactly! What Curt keeps correctly proposing is a small testbed that can later grow into a sort of useable PLC code that can later grow into a simple PLC, etc. This is clearly the right approach.

Dan Pierson

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

Jose Fernandez

I agree you Dan about the languages to be used whithin the project, even more, the first thing I would advice to do, is to specify or define those
"unknown components" you have metioned, we would define the scope, model, objectives, stages of the project, etc, then this would bring us to the data structures, protocols, interfaces, SO, languages, developing tools, the code itself and the developers as well, and if for example, we realize in the future that ADA would be a good language for a specific item of our project, and we don't have a ADA programmer within our group, so guys, to study ADA then, and that's it, IMHO.

I think all parts of the IEC 1131 standards would help us a lot, for example the IEC 1131 defines pretty well the basic model of Programmable
controllers, with its basic components and interfaces, among others issues.

Regards

Jose Manuel


> I think that people are tending to draw too many absolutes in this
> discussion. The project naturally consists of an unknown number of
> cooperating components, and thus cooperating subprojects.


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