Contributing, was System Architecture ??

P

Thread Starter

Peter Whalley

Hi Mario,

I think there is probably a simple answer to why so few people are contributing code. It's because they can't.

My suspicion is that maybe 90% of the people lurking on the list have no substantial experience coding in C or anything similar. Most of us are system engineers not software developers. Those that do software development do it in LL or FBD etc and not C.

As a result there might be only 10 or 20 people lurking that have any real C programming skills and many of these are too busy to contribute
significantly. So that leaves about 2 people who are actually able to contribute real code.

Most of us are used to telling suppliers and contractors what we want and not actually coding it from scratch. I know that doesn't help you very much but we do appreciate what you are trying to produce.

Regards

Peter Whalley

Peter Whalley

Managing Director
Magenta Communications Pty Ltd
121 King Street,
Melbourne, VIC 3000
Australia.

e-mail: [email protected]


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

Campbell, David (Ex AS17)

Peter wrote:

> My suspicion is that maybe 90% of the people lurking on the list have no
> substantial experiance coding in C or anything similar. Most of use are
> system engineers not software developers. Those that do software
> development do it in LL or FBD etc and not C.

I am aiming to fix that with an IEC 61131-3 translator to "C". Unfortunately I have just been hit by an overseas job for 3 weeks so that puts a delay in my efforts.

Umm... Could someone write a three paragraph section of how to install the Puffin "out of the box" so I can place it into the FAQ. eg:

* What hardware is required
* What software is needed
* Follow these instructions and you will have a PLC.

> As a result there might be only 10 or 20 people lurking that have any real
> C programming skills and many of these are too busy to contribute
> significantly. So that leaves about 2 people who are actually able to
> contribute real code.

The people who can code often are good trouble shooters which make them "very desirable" people to have around for systems support. The term "zombie" tends to describe their appearance.

> Most of us are used to telling suppliers and contractors what we want and
> not actually coding it from scratch.

You forgot the bit about not passing on the required info on time (because the end user doesn't know what he/she wants) and forcing the end contractors to work double time for no extra money to maintain schedule. (I've have been on both sides of this one).

David Campbell

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

Curt Wuollet

Hi Peter

Thanks.

In the very beginning I had to choose between doing this in the Linux community with lots of hackers, few of whom know automation, or the
automation community, few of whom are hackers. In the end I did it here because these are the users it would serve. I do sometimes wonder what would have happened if I'd gone the other way. It was interesting to read about SquareD and RedHat working together. I think keeping the Open Software idea fresh in the minds of the automation crowd is of greater value than getting the Linux community to think about automation. I just hope when everybody's doing it they adhere to the Linux community ethics.

Regards

cww

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

David Wilson

"Campbell, David (Ex AS17)" wrote...
>
> Peter wrote:
>
> > My suspicion is that maybe 90% of the people lurking on the list have no
> > substantial experiance coding in C or anything similar. Most of use are
> > system engineers not software developers. Those that do software
> > development do it in LL or FBD etc and not C.

Actually I would venture a guess that quite a few on this list program in several different languages or on several different legacy PLC
platforms. I have done some coding in everything from C to a few dozen flavors of ladder logic (with Karel, Automarker, Perl, Basic, Pascal, Assembly NESP-R and a few other things thrown into the list). (standard disclaimer... I forgot most of them yesterday :) ).

One of the good, and bad points about the possibility of using Linux as a PLC is the enormous number of different ways that control logic can be written. My biggest concern about the interface is very simply that I have been out there on the floor when things break, and when
your talking about a few thousand dollars a minute for lost revenue, one of the most important things about debugging a problem is having an interface that is simple enough that you can quickly troubleshoot problems when you have 20 people looking over your shoulder. Another important point is to make it as simple as possible for someone to do that that is not a Linux or computer guru.

>
> I am aiming to fix that with an IEC 61131-3 translator to "C". Unfortunately
> I have just been hit by an overseas job for 3 weeks so that puts a delay
> in my efforts.
>
> Umm... Could someone write a three paragraph section of how to
> install the Puffin "out of the box" so I can place it into the FAQ. eg:
>
> * What hardware is required
> * What software is needed
> * Follow these instructions and you will have a PLC.
>
> > As a result there might be only 10 or 20 people lurking that have any real
> > C programming skills and many of these are too busy to contribute
> > significantly. So that leaves about 2 people who are actually able to
> > contribute real code.
>
> The people who can code often are good trouble shooters which make
> them "very desirable" people to have around for systems support.
> The term "zombie" tends to describe their appearance.

Been there... Wearing the T shirt now :).

>
> > Most of us are used to telling suppliers and contractors what we want and
> > not actually coding it from scratch.
>
> You forgot the bit about not passing on the required info on time
> (because the end user doesn't know what he/she wants) and forcing
> the end contractors to work double time for no extra money to
> maintain schedule. (I've have been on both sides of this one).

Yes, in some cases I can recall completely gutting a new robotic operation and rewiring and reprogramming from scratch due to a job that was not specified properly in the first place. The other side was the vendor that did not know how to do the programming in the first place.

To bring this back on track a bit... it might be a good idea to throw some different user interface / hardware logic ideas onto a site and see what people prefer.

Dave

--
David R. Wilson
World Wide Network Services
Nashville, Tennessee USA
[email protected]



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

Harald Albrecht

&lt;plug>This reminds me of the management conference in Munich, Germany by end of November. It is titled "Free Software and Open Source ... Progressive, Profitable Strategies" and focuses on the Automation Industry. The idea behind this conference is to bring traditional automation and the free software movement together. We will see what will happen at this conference, especially when rms meets automation, like ABB, Bayer or Siemens (grin).</plug>

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

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

Curt Wuollet

I would like to be at that one :^) We can probably do some good by raising the profile of that conference. We should make sure that the
whole Linux community knows about it and and the automation community too. If you can supply What, Where, When, etc. , I'll see if I can get it on Linux Today, Linuxdevices.com and othere relevent
sites. And post it to the automation list. It might even be good to have a running dialog on the automation list. If you are or know somebody who is going to be there, we could use some on-site coverage. This is important! Even if they would like OSS to go away, they don't want to be perceived as MS stooges and may have to actually formulate a public response if the world is
listening. It would be even better if we could get an influencial volunteer like maybe Jim Pinto or Ken Crater to watch this. I am (quite correctly) viewed as anti-establishment or radical :^).

Regards

cww

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

Harald Albrecht

> I would like to be at that one :^) We can probably do some good by
> raising the profile of that conference.

Well, thanks for nothing -- I'm one of the persons in charge of contacting the speakers.

Please note that this conference is not intented to be the usual "free software conference" like all the big and fancy fairs and conference with lots of tech people. Instead it aims at the higher ranks, where a lot of interest has grown over the past year. On purpose I avoid the term "phb" here, as I have met quite some
interesting people in the course of the last years since I work at the Chair, and they showed a real interest in free software. Not least my work was thus made possible and is used in industry.

Thus some of the questions of the conference are:
* Can the development models be transferred into the automation industry, not only in small companies, but also the big players?
* Are all the ideas from the office IT market transferable to the small automation market, which is less than five percent of the office market?
* Patents everywhere -- how to live with them in free software?
* A Free Automation Software Foundation?

> It might even be good to
> have a running dialog on the automation list. If you are or know
> somebody who is going to be there, we could use some on-site
> coverage.

Well, by chance I shall be there (grin). Let's hope that the matter-antimatter contact (automation versus rms) will not result in
penguins getting sucked into Jupiter.

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

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

Curt Wuollet

Well, Harald, Despite my ignorance of Linux affairs in Europe, I mean well :^) Do you want all the PR I can generate or do you think the cause is better served otherwise?

<clip>....
> Well, by chance I shall be there (grin). Let's hope that the matter-
> antimatter contact (automation versus rms) will not result in
> penguins getting sucked into Jupiter.

Let's hope that it results in automation vendors getting dragged, kicking and sereaming into the OSS world where life should actually be much
better for them.

cww


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

Greg Goodman

> In the very beginning I had to choose between doing this in the Linux community with lots of hackers, few of whom know automation, or the
> automation community, few of whom are hackers. In the end I did it here because these are the users it would serve. I do sometimes wonder what would have happened if I'd gone the other way.

I think I can tell you what a control system might look like if built by hackers instead of process engineers.

You'd get an overengineered solution that could be used to do absolutely anything you could imagine, including lots of stuff you'd never want to do. There would be about a dozen ways to accomplish any particular task, and you'd have to be a system guru to evaluate the pro's and con's of various approaches. Any given program would have at least a handful of command line switches, maybe two handsful; some would be for tuning performance (let's specify an event queue size bigger than the default), some would enable alternate modes of operation (do we disallow acknowledging summary alarms, or does ack-ing a summary alarm auto-ack all the contributing alarms?), some would exist purely to aid application developers and trouble-shooters (debug switches, activity logging, verbosity levels). There would be hooks for all sorts of access (SNMP, CORBA, SQL) and bindings for every language anybody ever expressed an interest in ('C', Java, Python, Tcl, Eiffel, Smalltalk) - but no ladder diagramming tool, because what Unix hacker would want to write algorithms (even control algorithms) that way? Every place where a number appears in the code, there would exist a configuration option of some sort to change it. Everywhere any sort of data processing got done, there'd be a hook to allow a programmer to extend the default processing, or override it with a custom routine. There'd be libraries full of utilities like signal processing, fast fourier transforms, and API volume corrections.

I speak from experience. I worked for a software company that built what may have been the first commercial scada toolset for Unix on Intel. (It was first released for Xenix on a 386.) We who developed it were hi-powered 'C' and Unix software geeks, not process control experts. We wrote code optimized for robustness and performance, and implemented features either because a client asked for them, or because they made sense to us from a software standpoint (whether or not a client ever found a use for them).

The product never achieved a huge following because the company never really understood that the product was a sophisticated tool for sophisticated - and well-trained - users. They kept trying to sell it as an off-the-shelf Unix competitor to WonderWare. They offered training, but didn't require it, and ended up providing a lot of "software support" that was really control application analysis and design. The software was built by hackers, and lacked some of the GUI finesse and wizard-like support that integrators have come to expect, and so was perceived as hard to use. The software got a reputation for being the best choice if you had a really knotty problem to solve, because you could do anything with it, but not anybody's first choice for easy-to-use plug-and-play integration.

We developers learned what the company never did: that the best business model for software like that is an open source model, where we give the software away and make money from our expertise in using it, or training other people to use it, or in customizing the code for a client who doesn't have the resources or expertise to do it themselves. That's a great model for a consulting company, or an integrator, but it doesn't work for a company that wants to sell a shrink-wrapped product and make money on the volume.

Regards,
Greg
 
D

David Wilson

I have to agree with Greg, We need an interface that is easy to deal with and allows for easy debugging. I can write all manner of control
structures in a number of languages most people have not seen. Yes, it would be very versatile, and there would be a handful of people that can
debug it. The problem is that it is not going to be used if it is difficult to debug or program in. We don't need that problem. I don't have a problem with multiple user interfaces being available, just don't expect the interface that requires the most amount of knowledge to be the
one that is used the most. People buy control systems with the intent of solving a problem quickly. The actual expenditure for the hardware or the software are inconsequential when downtime means thousands of dollars a minute.

I worked in an auto plant for 17 years, and was one of those that had to fix what broke on the floor. While at that operation I suggested using
Linux for some of the systems that were mission critical. I was damn near laughed at only because the IT guys did not want a new headache to deal with. The decision was made that everything would be done on another operating system that everyone was familiar with. There were several places that Linux would have been better at...

1. Programming interface
(no anti virus software necessary)
2. Monitoring and control
(more stable than most platforms)
3. Old hardware still works, if it is too slow/weak for one task, you can use it for monitoring.

The use of Linux for PLC applications is very workable. It has the stability that is necessary for that. Being able to interface it with other proprietary hardware would be nice.

For control systems the main criteria is reliability. This usually means X windows and many userland applications are not going to be on the control system.

Dave


--
David R. Wilson
World Wide Network Services
Nashville, Tennessee USA
[email protected]



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

Curt Wuollet

Hey now, Dave

The first hacks were done with ncurses. To _UNIX_ hackers tty's are more important than GUI's 8^)

cww
 
P

Philip Costigan

Greg Goodman wrote:
>I speak from experience. I worked for a >software company that built what may have been >the first commercial scada toolset for Unix on >Intel.

Sounds like Macro-View.

--
Regards
Philip Costigan
-------------------------------------
P.C. SCADA LINK PTY LTD
Melbourne Victoria Australia
http://pcscada.com.au
-------------------------------------
 
Top