C
To all would be coders,
There appears to be a number of people on this list who have the following skills:
a) Average programming skills, mostly at device level
b) Interest in PLC devices
c) Specific areas of interest in industrial control and automation
If the above list describes you then you could make a significant contribution to the Puffin/LPLC project(s).
Here is the proof...
My background is Chemical Engineering (I was taught Fortran at University, I learnt "C" as a hobby). While I was writing my thesis I bought a parallel port ZIP drive as a floppy disk was not big enough to carry the files between university and home.
I found that there was a ZIP driver for Linux but the transfer rate was extremely slow, there was an experimental driver but that was unstable. I kludged around the source code for the two drivers and eventually made it more stable and reliable.
While this development work was underway there were a couple of "hot headed" computer science students (they have since graduated and found paying day jobs) discussing the theoretical method of sharing a parallel port. This went on for several days (about 10-15 emails/day to the parallel port devices list) before I asked them
either to write a header file of the routines required or to go elsewhere.
One of the two people quickly hammered out a two page header file with a rough description of what each function should do. After two days (it was a weekend) I had the first pass of the "parbus" (early version of the parport code) working which allowed the ZIP drive to be used with a printer attached to the pass through port. The code very quickly evolved into what we see today (approx 4 weeks).
Credit where credit is due, the CS guys knew theoretical solution to the problem but they were not prepared to commit to code. I had no idea of how to go about parallel port sharing. Once the
framework was established (the commented header file) then other people could step in and "fill in the blanks".
I am afraid that Jiri and Curt find the Puffin project a little close to their hearts and are somewhat afraid to let go and allow others to hack at their precious code. [Jiri & Curt, see PS at bottom]
Probably the best thing that can happen now is that the current coders step back and take a hard look at the current code and figure out where could they slice the code into approximately five sections and clearly document how these sections fit together (eg: data structures and function calls).
I take the example of the parallel port ZIP driver which is fundamentally a SCSI driver, I did not need to know the inner workings of the Linux SCSI system but I did know that the driver
would be called with a SCSI request which the driver needed to process and return the appropriate value. Why can't the Puffin/LPLC
do the same?
Next question is where do you split the code? Some suggestions:
a) Hardware interfaces
b) Data point pool (tagname => driver:instance:device:address)
c) Control algorithms
d) Data collection (historian)
e) Management tools
Currently I see the code archives as one monolithic program.
Summary:
========
I believe that the LinuxPLC project currently is:
a) Lacking clear vision (what is our ultimate objective?)
b) Not structured to allow people to work in small areas
(currently you need to be aware of every change in LinuxPLC as it
may impact your code)
Thats my 5 cents worth (2 cent coins have been withdrawn from circulation in Australia).
David Campbell
PS: It is quite normal for technical people have difficulties with new starters. The new starters come in looking for something to do but there is no work that you can apparently offer them.
My experience with a graduate assigned to me was to slice off a small chunk, clearly define what is expected and normally they will complete the task quickly and efficiently. The hardest part of this is learning how to "outsource" the work, the is very difficult for highly technical people.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
There appears to be a number of people on this list who have the following skills:
a) Average programming skills, mostly at device level
b) Interest in PLC devices
c) Specific areas of interest in industrial control and automation
If the above list describes you then you could make a significant contribution to the Puffin/LPLC project(s).
Here is the proof...
My background is Chemical Engineering (I was taught Fortran at University, I learnt "C" as a hobby). While I was writing my thesis I bought a parallel port ZIP drive as a floppy disk was not big enough to carry the files between university and home.
I found that there was a ZIP driver for Linux but the transfer rate was extremely slow, there was an experimental driver but that was unstable. I kludged around the source code for the two drivers and eventually made it more stable and reliable.
While this development work was underway there were a couple of "hot headed" computer science students (they have since graduated and found paying day jobs) discussing the theoretical method of sharing a parallel port. This went on for several days (about 10-15 emails/day to the parallel port devices list) before I asked them
either to write a header file of the routines required or to go elsewhere.
One of the two people quickly hammered out a two page header file with a rough description of what each function should do. After two days (it was a weekend) I had the first pass of the "parbus" (early version of the parport code) working which allowed the ZIP drive to be used with a printer attached to the pass through port. The code very quickly evolved into what we see today (approx 4 weeks).
Credit where credit is due, the CS guys knew theoretical solution to the problem but they were not prepared to commit to code. I had no idea of how to go about parallel port sharing. Once the
framework was established (the commented header file) then other people could step in and "fill in the blanks".
I am afraid that Jiri and Curt find the Puffin project a little close to their hearts and are somewhat afraid to let go and allow others to hack at their precious code. [Jiri & Curt, see PS at bottom]
Probably the best thing that can happen now is that the current coders step back and take a hard look at the current code and figure out where could they slice the code into approximately five sections and clearly document how these sections fit together (eg: data structures and function calls).
I take the example of the parallel port ZIP driver which is fundamentally a SCSI driver, I did not need to know the inner workings of the Linux SCSI system but I did know that the driver
would be called with a SCSI request which the driver needed to process and return the appropriate value. Why can't the Puffin/LPLC
do the same?
Next question is where do you split the code? Some suggestions:
a) Hardware interfaces
b) Data point pool (tagname => driver:instance:device:address)
c) Control algorithms
d) Data collection (historian)
e) Management tools
Currently I see the code archives as one monolithic program.
Summary:
========
I believe that the LinuxPLC project currently is:
a) Lacking clear vision (what is our ultimate objective?)
b) Not structured to allow people to work in small areas
(currently you need to be aware of every change in LinuxPLC as it
may impact your code)
Thats my 5 cents worth (2 cent coins have been withdrawn from circulation in Australia).
David Campbell
PS: It is quite normal for technical people have difficulties with new starters. The new starters come in looking for something to do but there is no work that you can apparently offer them.
My experience with a graduate assigned to me was to slice off a small chunk, clearly define what is expected and normally they will complete the task quickly and efficiently. The hardest part of this is learning how to "outsource" the work, the is very difficult for highly technical people.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
