System Architecture ??

K

Thread Starter

Ken Emmons

Hello Again,

I just want to comment on the system architecture. Everyone is busy trying to promote languages, interfaces to the PLC (telnet, XML, etc.), and even trying to document APIs and function calls.

I am new to this discussion, so take this with a grain of salt, but I see absolutely no real published Ideas for how the system is to be
structured. Where are the block diagrams, where are the rough draft specs (or at least proposed specification ideas??)

I have a lot of experience designing hardware and software systems (That is a PLC isn't it??) :eek:) and any good design starts with a good design
specification .... Having said that, even a good design spec is not perfect and needs to be modified as you go by careful communication of
ideas and concepts.

It is my understanding from reading the discussion threads that most people in the open source world seems to despise specifications and, to some extent, I can understand this. My fear is that this project is not going to be engineered, but that it is going to be pieced together with
the system architecture coming in as an after thought. If this is the case then this project will never really work the way it was intended.

BTW, Everybody who reads this needs to take a look at what Steeplechase software is doing.

http://www.steeplechase.com

They have an Excellent product that performs Hard Real time with a very elegant and powerful graphical front end that supports RLL and Flow
chart (Mainly flow ... RLL is for backwards compatability) It is fast as well. When the PLC portion is finished it still leaves enough time to
run Windoze NT as a Task. This is it's shortcoming, Windoze. It's structure and architecture should be considered as a model. (Look at the White Papers) I have worked with the folks who created the software (former AB employee) and they are top notch Software Engineers. I like the software, but like I said, it requires Windoze in order to load programs and to have a GUI. (Once it runs it is independant of Windoze, but a lot of windoze problems occurr when booting anyway!!)

Another concern of mine is that EVERYONE seems to try and divert the primary goals of this project. Simple. PLC. IO Driver interface. Basic HMI. All the fancy stuff can be added as long as the basic structure here is solid.

Thanks for bearing with my gripes. My intent is not to offend, but to promote this great project.

~Ken

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

Mario de Sousa

Ken Emmons wrote:

> I just want to comment on the system architecture. Everyone is busy
> trying to promote languages, interfaces to the PLC (telnet, XML, etc.),
> and even trying to document APIs and function calls.
>
> I am new to this discussion, so take this with a grain of salt, but I
> see absolutely no real published Ideas for how the system is to be
> structured. Where are the block diagrams, where are the rough draft
> specs (or at least proposed specification ideas??)
>

Did you read my email explaining the structure of what we currently have? I am not a CS, so I don't know what else you want. How about coming forward
with some proposals instead of asking for the spec.? That is what I feel is wrong with this project. Everybody is willing to give their 2 cents, but not more. That is, everybody is willing to say what the could should do,
what it should be like, what should be done, but very few people come forward with actual specifications, and above all, code. In the end, that is what counts!


> I have a lot of experience designing hardware and software systems (That
> is a PLC isn't it??) :eek:) and any good design starts with a good design
> specification .... Having said that, even a good design spec is not
> perfect and needs to be modified as you go by careful communication of
> ideas and concepts.

Great. It is nice to see we have reached a point people are asking for the spec. In the beginning nobody could agree on what the structure of the code should be, so the only way forward was to start writing code. It will probably all be thrown away, but at least we now have a working base to argue about. If we hadn't started writing code without a spec, we would still be in the same place, without a spec and without any code.


> It is my understanding from reading the discussion threads that most
> people in the open source world seems to despise specifications and, to
> some extent, I can understand this. My fear is that this project is not
> going to be engineered, but that it is going to be pieced together with
> the system architecture coming in as an after thought. If this is the
> case then this project will never really work the way it was intended.
>

Once again, did you read my email explaining the structure of the current code? (it is also on the introduction to the FAQ)What else do you want? I
really want to know. As I said, I am no CS, so if you think you can do better, please jump in and make some sugestions. But come with a spec, not
with some more arguments about what the spec should be like!

I started contributing code to this project when I didn't like the way Jiri coded the Great Namer. Heck, I didn't start emailing the list saying the
code wasn't good, I wrote some code to substitue the Great Namer and emailed it to Jiri. He seemed to like it and inserted it into the cvs. Why
don't more people do the same, instead of just emailing the list saying what they would like to see in the project?

>
> Another concern of mine is that EVERYONE seems to try and divert the
> primary goals of this project. Simple. PLC. IO Driver interface. Basic
> HMI. All the fancy stuff can be added as long as the basic structure
> here is solid.
>

I agree. Would _you_ like to help out making the solid basic structure, or are you waiting for others to do the hard work?

> Thanks for bearing with my gripes. My intent is not to offend, but to
> promote this great project.
>

It is I who must apologize for this email. Its just that I am getting tired of contributing code, and just seeing a whole bunch of other people just speaking out, and not doing any real contributions.


Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

Curt Wuollet

Ken Emmons wrote:

> Hello Again,
>
> I just want to comment on the system architecture. Everyone is busy
> trying to promote languages, interfaces to the PLC (telnet, XML, etc.),
> and even trying to document APIs and function calls.
>
> I am new to this discussion, so take this with a grain of salt, but I
> see absolutely no real published Ideas for how the system is to be
> structured. Where are the block diagrams, where are the rough draft
> specs (or at least proposed specification ideas??)

Very early on we had a diagram or two. The problem is that strong personalities vary on the details and it degenerates. I am confident and I assure you that the people writing code have a clear vision. At the moment I have only a vague understanding of that vision, but this is not abnormal in OSS projects. I would say we have a virtual white board, some parts get saved, some get wiped and redone as insight and inspiration occur. We have been given gifts that must be grafted in and serendipity also has its place. It is an entirely different mode of development, but I am not at all concerned at this stage. So far,
there are very few developers and they communicate. That the rest of the world is in a relative vacuum is discouraging, but I don't think
it hurts development. If you want to know bad enough you can read the code and if you want something, write it. I confine myself to making comments on overall goals that the developers consider more or less irrelevent. I can't keep up so I am getting out of the way, the project comes first. We have plenty of egos, we're still short on code. The inmates are running the asylum and it seems to be working fine.

> I have a lot of experience designing hardware and software systems (That
> is a PLC isn't it??) :eek:) and any good design starts with a good design
> specification .... Having said that, even a good design spec is not
> perfect and needs to be modified as you go by careful communication of
> ideas and concepts.

Exactly, only more so.

> It is my understanding from reading the discussion threads that most
> people in the open source world seems to despise specifications and, to
> some extent, I can understand this. My fear is that this project is not
> going to be engineered, but that it is going to be pieced together with
> the system architecture coming in as an after thought. If this is the
> case then this project will never really work the way it was intended.

Disagree, it may not work as expected but it will work as intended.

> BTW, Everybody who reads this needs to take a look at what Steeplechase
> software is doing.
>
> www.steeplechase.com
>
> They have an Excellent product that performs Hard Real time with a very
> elegant and powerful graphical front end that supports RLL and Flow
> chart (Mainly flow ... RLL is for backwards compatability) It is fast as
> well. When the PLC portion is finished it still leaves enough time to
> run Windoze NT as a Task. This is it's shortcoming, Windoze. It's
> structure and architecture should be considered as a model. (Look at the
> White Papers) I have worked with the folks who created the software
> (former AB employee) and they are top notch Software Engineers. I like
> the software, but like I said, it requires Windoze in order to load
> programs and to have a GUI. (Once it runs it is independant of Windoze,
> but a lot of windoze problems occurr when booting anyway!!)
>

This type of "all in one" product is one of the ultimate goals. We can if we wish, have better integrated realtime than the Steeplechase product.
Basic RTLinux would be a rough equivalent. We now have several other flavors of Realtime Linux that provide hard or soft realtime or both. This
area is growing so fast that it's a good idea to watch for a while yet.

> Another concern of mine is that EVERYONE seems to try and divert the
> primary goals of this project. Simple. PLC. IO Driver interface. Basic
> HMI. All the fancy stuff can be added as long as the basic structure
> here is solid.

Very much agree, too bad it's not quite that simple.

> Thanks for bearing with my gripes. My intent is not to offend, but to
> promote this great project.

It's your project too.

regards

cww

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

Mario de Sousa

Curt Wuollet wrote:

> Easy there, Mario, I'll run interference and handle PR if you'll let me.

Quite right there, Curt. I must apologize for losing my head.

But I am seriously considering scaling down my contributions. Maybe it is I (my coding style, my temper, my ...?) who is getting in the way of having more people contributing.

> We agree completely on this issue. It's a lot easier to talk than to do.

Sometimes it is not all that easy to talk either... ;-)

> If I can't stay current, at least I'll support you guys to the max.
>
> Regards
> cww

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
hey guys.
i dont see the original post, but looked to see if i could contribute. you see i only found this site a couple of months back and read everything.. now only pop in on occasion.

i am a C programmer etc. and do have a feel for what your talking about, i too had a headache before i came.

i write plc software for ab in rockwell, and use their rs linx sdk.. siemens up to s7-300

and too many others to even try to remember, mainframes pc's proprietary.. this and that HMI..

then there is the big MS picture and not meaning to remind you all of your headaches.. i will get to the point..

we need the specs.. but usually have to revise..
we need communications.. there is little..no i wont write the book.. maybe i have the code, but i forget..read the tech data sheets on every processor..a straight out click here for instruction set would be awesome...dont get confused by the guys who write lots and lots of things on 'standards'.. and know that the whole point is if ever, i say if ever, someone will help you.. all the reusable code should be stripped by nature and stored in a repository...

back to it..
heather.
 
C

Curt Wuollet

Please folks (and me), let's try to keep it constructive. I have been kinda critical myself and for that I apologize. One of the reasons I
proposed changes is so that I can let go of the philosophical burden and just let it happen.

I am going to do my best to find ways to use the skills and time of everyone who wants to contribute. I don't know how just yet but we
should be able to get some more parallel efforts going. I'm open to suggestions. Do we have anybody who would like to start on a graphical
Ladder Logic editor? I seem to recall someone mentioning that they had a start.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ken Emmons:
> I just want to comment on the system architecture. Everyone is busy
> trying to promote languages, interfaces to the PLC (telnet, XML, etc.),
> and even trying to document APIs and function calls.

Ah, structure...

Each part (module) of the lPLC runs as a separate process, each linked against the linuxplc.a library[1].

Example modules might be: logic (RLL) program, HMI, http-server, I/O [2], bus I/O/comm. Any particular installation will run only a few of the
available modules.

The linuxplc.a library provides various services, perhaps the most important being config, data map and synch. In turn:

- config - provides for the configuration of various lPLC
parameters from a single file, by default linuxplc.conf. There
are private sections for each module (there is provision for
several of a given module to run simultaneously), as well as
sections used by all modules, eg [PLC] and [SMM].

- data map - provides the familiar data points, corresponding to
PLC inputs, outputs and internal coils/registers. Points of 0 to
32 bits are supported, 1-bit points corresponding to simple coils
or relays.

As in a standard PLC, the data map is buffered so that changes to
a point do not appear on the outputs (or HMI screen, or to other
modules) until the end of the cycle.

Unlike a standard PLC, no distinction is made between inputs,
outputs and internal coils. It is recommended that the user adopt
a naming scheme that avoids confusion.

- synch - this provides for (optional) synchronisation between the
cycles of the various modules. By default each module runs free;
synchronisation can lower CPU usage and provide more uniform
latencies.

Some modules (eg PID) require that they be synchronised to
certain of their inputs, as they calculate deltas.


[1] This should be linuxplc.so, but I've no experience creating shared libraries and neither, it seems, has anybody else. So linuxplc.a for now.

[2] There is some argument whether there should be one I/O module or many, but in practice I think the point is moot as most installations will only use one kind of I/O anyway, and hence only one I/O module.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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