Where are we?

C

Thread Starter

Curt Wuollet

Hi all

Wanted to pose some questions to you all. It seems we have dropped to 0 development just
lately. I need to fix that. How do I do it? I have been too busy lately to do much more than a
cursory skim of my mail, but, I have noticed the lack thereof from this list.

I want to know whatever someone will tell me about why interest is lagging so badly.
Are we heading in a wrong direction?
Have we gotten too technical, to the point that keeping up is too difficult?
Is there another project? (We're jealous)
Is the automation world simply not ready for a public project?
Is there pressure from vendors?
I am in serious need of clues, folks and it's kinda like we're the last one to know.
We are still able to change anything we want, even complete direction. I'm willing to continue the bonehead C version with full commentary if that's what it takes.

This is _your_ project, I am expendable if for example, my biases are turning people off.

If there are comments you would rather keep private, mail me off-list and I will maintain strict confidentiality and objectivity. I am not doing this to argue, but to hear.
Is this project possible in this environment or does the proprietary world win this round?

Regards

Curt Wuollet
[email protected]
Wide Open Technologies.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I am surprised that there has been not much said here in regards to Hugh's LPC project. Gosh, he has made great progress towards a viable controller running on Linux. This is one man and with the progress he has made, I am really impressed.

Maybe efforts should be directed towards getting additional I/O working with the LPC and a java ladder interface. The I/O drivers are fine in C. I know that some people may be resistant to using C++, but I think that a project of any complexity is only augmented by an OO approach such as his. I know that in looking through his code, his modular approach makes understanding the code much easier.

I guess what I am saying is that there is already a Linux PLC ( Hugh's LPC) and why duplicate the effort? The approach of emulating (generally) an AB PLC5 lends credibility to the LPC as a replacement to a real PLC because many people are familiar with the AB file based memory view. Most users don't care much what it is written in - just that it is relatively familiar to what they are used to.

It seems that the Puffin PLC has turned into a CS exercise. I don't think that a 'bonehead c' approach with a few hundred lines of code is going to get it either. It may be fun to play around with, but...

Just my opinion...

Phil


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

Gunther Wenzel

Hello all,

I am an electronics engineer who has worked for five years in system integration and industrial automation, using largely Siemens PLCs.

I have also been lurking in this list since it began in the automation list at control.com with Curt's great motivational email.

I am not a professional programmer, but I have done what I believe is some extensive system level programming in C and assembler and several
other languages.

And, I definitely agree with Phil. I have no doubt that Jiri and Mario are brilliant computer science experts (along with all the other people
who contribute regularly to this list), but as far as I am concerned, I quit trying to understand what they were doing months ago.

Of course this just sank me deeper into lurk mode. I never really tried to contribute myself mainly because I have very, _very_, little
experience with Linux. At office I work with Wintel platforms, and I have a Mac at home (although recently I purchased LinuxPPC and will
definitely try to delve deeper into Linux - that is, once I get it going :).

Anyway, what I am trying to say is: Where are we? Well, I'm waiting for Jiri et al. to finish whatever it is they are doing, because I
certainly can't help them.

On the other hand, I have closely read all of Jack Hugh's emails, and roamed around his LinuxPLC, and seriously wondered why nobody has
publicly said anything about it. Are we jealous? Don't we believe him?
Why don't we realize that he has gotten along much farther on his own than all of us together (well, maybe he started earlier...)?

I believe that we should gain a second wind and try to help Jack finish and add all the missing features (if he'll allow us to). At least, in
the effort we might learn something that we could use in our own (sorry for claiming to be a part of it) LinuxPLC.

***
I wrote this to sum up all the mixed feelings I have about this project since its inception. If anyone has taken offence to anything I have
written, please accept my apology, because it is surely not my intention.
***

Back to lurk mode,

Gunther Wenzel

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

David Nimmons

Hello Curt

I am in the same position as Gunther in that I don't feel I have the skills to contribute. I have done a little assembly and C programming, but, that was in years past and even then my programs were pretty minor. Since then my programming has been limited to ladder logic and DCS configuration. What I am saying is that I am a hacker wannabe. I am trying to contribute in the
user interface area though, as I am currently working on a web based HMI. I hate to hear that you think the project is floundering because I think it is an important project. Maybe we need to do some brainstorming as how to attract some more help. In fact, I will start it off with an idea: Solicit help from College engineering departments around the country. It could
possibly be done in the form of a contest, with teams from each College competing to come up with the best solution. Just an idea to get the
discussion started.

PS: I was also surprised by the lack of response to Jack about his LinuxPLC even though I understand the distaste for a Java based solution.

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

Curt Wuollet

Hi All

Just a note to explain that my (unusual) silence is not dismissal of the comments and the issues raised. I want to remain in Listen mode. I have
filed the comments on list and off list and will comment on them in aggregate when everyone has had a chance to comment. Early on, there was
some "shouting down" of individuals which wasn't very democratic. We need input, we need concensus. The project needs to be a lot stronger to attract support from the community. There _are_ people who are ready to help if we
can only enable them. We have a huge number of lurkers who are interested in the project.
I can't believe that they have nothing to say, especially when everything is open for consideration. This is an RFC, that is, Request For Comment, stage to draw from the community what they want the project to look like and it is
important. Even the people I work for are getting discouraged. For my part, I obviously think it's still a great idea. I want to hear your comments,
gripes, ideas, and especially what you think we can do to get moving.

Back to listen mode, I've spoke too much already :^P


Regards

cww

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

I have followed the comments with interest, and I would like to say that I would rather see at least TWO Linux PLCs, and I would hate to see the
Puffin project abandoned. In addition, the approach I have been using in the LPC is fundamentally different, so I don't even see the projects as competing, but more complementing. There shouldn't be an us-or-them approach to open source projects, or else you end up like the gnome vs. kde camps.

Remember, overall, if there are more choices for control using Linux, it will attract more users. If there is only one, then potential users
would feel trapped, and remain in the traditionally safer proprietary world.

Hugh

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
F
I am also a lurker who has been pushing our company to adopt an open architecture PLC replacement. With over 40 years in control design I still prefer Boolean equations since they worked for relays, early (Struthers Dunn) Programmable Logic Controllers, RTL, TTL, and the latest PLCs. Ladder logic follows almost automatically from Boolean so I also like it. I
have programmed in binary, octal, & hex, BASIC, C, C++, but never mastered much beyond assembly. Presently trying to master Python in hopes that I can contribute something to this project. I have (I hate to use the word played) with some of the downloadable packages that have been posted and
like what I see. Keep up the good work all, I'm back to lurking.

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

SILVESTRI Marco - Computes

Well, here I am, another lurker.
I'm a mechanical engineer which at the moment is employed as C++ programmer for a 3D cad project.
Soon I'll go in the automation/robotics field and, since I love linux, I've started to lurk this list.

I've got some experiences in C and C++ coding, and I hope I can help this project to restart. It would be great to program PLC using something I've
contributed to do.

But I don't understand how far are we from an usable product.

Thanks to all

Marco

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

Kevin Hodges

I have been lurking for a while and have been impressed with the concept thus far. I would have to say that I agree with Gunther statements.

I program a little, but do not consider myself an expert (especially with linux) so I thought I would leave that to the experts.

In my opinion, the project seems to have lost some steam as the programming details have gotten in the mix. Don't get me wrong, details are the difference between dreams and an end product, but details always seem to take some of the initial excitement out of projects (maybe because the work tends to overshadow the dream).

I got into the project after it had already started, so I had some catching up to do. I think it would be worth while to have some intro material for late comers, so they don't lose interest deciphering what's happening.

That's my 2 cents. Resuming lurk mode......


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Gunther Wenzel wrote:
> And, I definitely agree with Phil. I have no doubt that Jiri and Mario
> are brilliant computer science experts (along with all the other people
> who contribute regularly to this list), but as far as I am concerned, I
> quit trying to understand what they were doing months ago.

Oops, our fault for not keeping up with the documentation.

I'll try to write a documentation-style e-mail or two to try and explain how to use our code.


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
 
M

Mario de Sousa

Jiri Baum wrote:

> Oops, our fault for not keeping up with the documentation.
>
> I'll try to write a documentation-style e-mail or two to try and explain
> how to use our code.
>
> Jiri

I very much apreciate your help in trying to explain the workings of what we currently have. I don't want to put you off, but maybe it would be more productive if you started off with a higher level explanation of how the whole plc works and inter-connects, i.e. explain the vision of what we
expect the LPLC to become, and what it is right now.

I could try to do it if you wish, but I get the feeling you are better at it than I am, so please, do correct my first attempt.


******************************************

The PuffinPLC (a.k.a. LinuxPLC)
-------------------------

The PPLC is an attempt to produce a working PLC-like program runing on Linux, with GUI for configuring and viewing its current state. The GUI will not be limited to Linux, but hopefuly also run on Windows, Web browsers, etc...

We intend to take advantage of the fact that we have an underlying Operating System (OS) and therefore we will use its features to try and make
the PPLC modular, allowing for parallel code development.

A running PPLC consists of modules runing in an infinite loop, and accessing the common PPLC memory/state. The common PPLC memory/state is
limited to points that can be from 0 to 32 bits wide. One module could be a PID loop, using two points for its inout, and a third point for its output. Another possible module could be a plc5 emulator, that executes plc5 code, but using PPLC points as it variables. Yet another possible module would be an I/O board driver, that would copy the state of some PPLC points to its outputs, and copy the state of its inputs to other PPLC points.

As already stated, taking advantage of the underlying OS, each module will run as an independent process. This means that each module can be developed independently of each other, in whatever programming language the coder chooses. Access to the common PPLC memory/state is done through a linuxplc.a library of functions, written in C, and with C header files available. The plc_set() function that Jiri has just explained, falls into the group of functions that give access to this common memory/state.

The linuxplc.a library currently also supports synchronisation between modules. For example, say we have an I/O module and a PID module running.
For the PID module to produce correct results, it must run in lock-step with the I/O module. With the synchronisation between modules, we can guarantee that the PID and I/O modules will run their scanning loops intermingled (i.e. I/O - PID - I/O - PID - ...). This is achieved without any explicit programming effort on the part of the module programmer, other than calling a specific plc funtion at the begining of the scan, and another at the end.

Although not yet implemented, we intend to support online changes to the PLC, such as adding a module, removing a module, replacing a module (and guaranteeing that the new module will only start executing once the module being replaced has finished its scan), etc... This has not yet been completely thought out, so the supported semantics may change compared to what I have described.

As you may have already noticed, for the PPLC to work it requires common resources so the modules/processes can communicate and synchronise between them. This is done using shared memmory and semaphores. The use of these IPC (inter-process communication) mechanisms is hidden from the module coders by the linuxplc.a library. The shared memories and semaphores need to be setup
before any module can start executing. This is done by a utility (currently named smm-mgr due to its origins) with the -g parameter. To shutdown the PPLC (i.e. delete the common shared memmory and semaphore resources) use the -s parameter. If you want to exercise the PPLC at a very low level, you may use the plctest utility.


The structure of the cvs server:
-----------------------
/demo - this is where demos reside. Currently we have two.
/demo/basic
/demo/basic_synch

/doc - where the documention should be... ;-)

/drivers - Linux device drivers required to access I/O modules, etc...

/io - PPLC I/O modules

/logic - PPLC logic engine modules (interpreters, compilers, ...)
/logic/il - A basic instruction language compiler, that generates a PPLC module. Written in perl.
/logic/iec - The beginings of an iec language compiler. Does not yet produce working PPLC modules.
/logic/dsp - A digital signal processing module. Currently I only have the main framework implemented, and a very basic PID function. Hoping other more PID knowlegeable people are willing to help me out with this. I have some well defined header files you can write standard C (OS independent code) for this. Please email me if you are willing to help out.

/mmi - man machine interface PPLC modules. Currently we have a very simple curses based interface.
/mmi/curses - home of the vitrine curses based mmi PPLC module.

/lib - this is where the linuxplc.a library and source code reside. Please read the README and check the header files to better understand this code. The smm-mgr and plctest utilities are also here, waiting to be moved to a better location.
/lib/log - the common logging services library
/lib/conffile - the configuration file parse library
/lib/cmm - the configuration memory manager library
/lib/gmm - the global memory manager library
/lib/synch - the synchronisation library
/lib/misc - miscelaneous libraries used without the other libraries (shared memory, internet sockets, semaphores, string handling,
data structures, ...)
/lib/util - the smm-mgr and plctest utilities.

Cheers,

Mario.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario de Sousa:
> I very much apreciate your help in trying to explain the workings of what
> we currently have. I don't want to put you off, but maybe it would be
> more productive if you started off with a higher level explanation of how
> the whole plc works and inter-connects, i.e. explain the vision of what
> we expect the LPLC to become, and what it is right now.

I figured I'd just get straight into it... many of the best-told stories start `in media res'.

> I could try to do it if you wish, but I get the feeling you are better at
> it than I am, so please, do correct my first attempt.

Actually, it's pretty good.

One comment - the synch library is fairly young, and we'll be trying to simplify the configuration. So while the programming interface is probably basically set, you may notice it's a bit hairy to configure at the moment. Should be backwards-compatible, though.

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
 
P

Pete Buechler

I am yet another lurker. I have been working on a small project, the Open Distributed Data Acquisition System ( http://oddas.sourceforge.net
). There are so many similar projects that I have considered that perhaps I should ditch ODDAS and work on another project aiming at the same thing. But I do not have experience in using industrial PLCs, all my work in control and data acquisition has been on custom systems build from scratch, usually in aerospace. So I do not understand a lot of the PLC lingo.

So to tell you the truth, I am not sure what direction the Puffin project is heading in or where it is now. Or where I can find out.
--
Pete Buechler
Developer, SuSE Labs
[email protected]
http://www.suse.com/~peterb

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I have almost zero coding ability. I work on industrial equipment (AC and DC drives to be exact) and am troubleshooting PLC's frequently. I
am a huge Linux geek. I am lurking with intent to help where I can, but I realistically don't think that my contributions can be much larger
than beta testing.

Blue skies... Todd
--
Most traditional Pee-Cee user groups, I've noticed, function mainly as commiseration societies for people who've bought lousy hardware, are struggling and wasting time trying to deal with it, and want to exchange coping-strategy tips with others in the same boat. -- Rick Moen

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

Pierre Desrochers

Hi all-

I am new to this Linux "religion" and am willing to believe (learn). I am an independant system integrator and am nozing around Linux based SQL
servers(with very little source code knowledge). I am a system integrator in Instrumentation and control system. I deal day to day with integration of different PLCs / SCADAs / ERP systems and specialy the way to make such
systems more user frendly. I to am willing to beta test any part of this project. Would need coaching and would participate in establishing the
basic needs.

I am french and would translate technical docs if needed

Lucky Pete :)

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Pete Buechler:
> But I do not have experience in using industrial PLCs, all my work in
> control and data acquisition has been on custom systems build from
> scratch, usually in aerospace. So I do not understand a lot of the PLC
> lingo.

Please, do ask - we (or I at least) would like the project to be accessible to people who don't have much of a PLC background, too.

> So to tell you the truth, I am not sure what direction the Puffin project
> is heading in or where it is now. Or where I can find out.

That's a rather general question :)

Right now we have a common data area for all the modules, so if you have some data acquisition you want to contribute, you can put it in. It should
run as a separate process (at least for now) and post the data to the rest of the lPLC using the plc_set()/plc_update() functions.


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
 
M

Mario de Sousa

Ciau Marco,

Sorry for taking so long to respond. Your mail was sent to my file server before I had a chance to read it, and then the file server crashed.... (It is now up, and the backups restored)

There are several programs you can help out in coding. What kind of background have you got on Linux? If you have some Linux background then maybe you could write a simple program that reads the state of the keyboard and maps it onto the linuxplc state. But maybe you were expecting to write GUI? I don't know.

In short, can you give us an idea of what type of programming you would like to make. I'm sure we can acommodate you.


Cheers,

Mario.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> I have almost zero coding ability. I work on industrial equipment (AC
> and DC drives to be exact) and am troubleshooting PLC's frequently. I
> am a huge Linux geek. I am lurking with intent to help where I can, but
> I realistically don't think that my contributions can be much larger
> than beta testing.

I'm a near opposite. I have lots of coding ability and am quite comfy in C++, python, and have done perl and all the usual suspects. I'm
really happy to try to get involved, but just don't know where to start.

I'm really pretty new to industrial stuff and also to PLCs. I've never written function block or ladder logic in my entire life.

Tim

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Years ago I had some Modicon Concept (?) Demo software which allowed me to write in several of the PLC languages and run the program in an emulator on my (Windows, of course) PC. If you want to play around with function block or
ladder logic, I would guess that (these days) many PLC makers now have this kind of Demo/Trial software available.

If you are "comfy" in C++, you know everything else is a walk in the park by comparison. Especially if you wrote for Windows.

(It's been a while, but I think the following sums it up)

Think of :

IL (Instruction List) as assembly language for PLC's

ST (Structured Text) as PASCAL or BASIC for PLC's

SFC (Sequential Function Chart) and FBD (Function Block Diagram) as kind of Flowchart programming for PLC's. (roughly speaking, SFC handles program flow, FBD handles program formulae)

RLL doesn't really have another software equivalent that I know of. Its ancestry is old contact/coil relay diagrams. It's kind of graphic binary program for PLC's.


Rufus

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

Philip Costigan

> Years ago I had some Modicon Concept (?) Demo software which allowed me
> to write in several of the PLC languages and run the program in an emulator on
> my (Windows, of course) PC. If you want to play around with function block
> or
> ladder logic, I would guess that (these days) many PLC makers now have this
> kind of Demo/Trial software available.
>

http://www.schneiderautomation.com

On this site is a demo for concept 2.2. It can be downloaded and run on that other operating thingy.

Check under "support & services" and then under software is the hyperlink called "Concept". Then look in the "Trial Versions" and then select
"Software demo & Trial" Finally you get to download the trial version.

It might pay for some of our coders to have a look at it just to get a feel for what people are using in the field. It also simulates the program that is developed so people can actually commission a machine long before the I/O is
allocated or the machine is built.

I don't think that copying their interface is the right thing to do but I believe that IEC61131-3 is not a standard but more of a recomendation so we can realy create our own look and feel at the top level. If we make it super simple for engineers and maintenance then we're in.

--

Regards

Philip Costigan

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