Process Control Help

Discussion in 'Python' started by tylerca@jeld-wen.com, Jul 27, 2007.

  1. Guest

    I'm attempting to start some process control using Python. I've have
    quite a bit of literature on networking, and have made some tinkering
    servers and clients for different protocols HTTP, FTP, etc... But now
    it's time for the murky web of industrial protocol. I'm looking to
    start with IO and servo controls via Ethernet.

    Questions:

    Is there an existing forum on this already?
    What protocols are the most python friendly? i.e. are transparent
    enough that i can create my own python driver. (or do these drivers
    exist?)
    What ethernet accesible servo and IO industrial devices have people
    had success with?
     
    , Jul 27, 2007
    #1
    1. Advertising

  2. <> wrote:

    >
    >
    > I'm attempting to start some process control using Python. I've have
    > quite a bit of literature on networking, and have made some tinkering
    > servers and clients for different protocols HTTP, FTP, etc... But now
    > it's time for the murky web of industrial protocol. I'm looking to
    > start with IO and servo controls via Ethernet.
    >
    > Questions:
    >
    > Is there an existing forum on this already?
    > What protocols are the most python friendly? i.e. are transparent
    > enough that i can create my own python driver. (or do these drivers
    > exist?)
    > What ethernet accesible servo and IO industrial devices have people
    > had success with?


    What is it that you are trying to do?
    Some of the commercial devices come with their own software, and
    you may not need python or anything else.
    A lot of the industrial connectivity is still RS-485 or RS-422 and not
    Ethernet based - although some of the protocols, have, I think, been ported.

    If you say more, then someone can maybe help you, as there are quite a few
    people on this group who seem to dabble in process control.

    - Hendrik
     
    Hendrik van Rooyen, Jul 28, 2007
    #2
    1. Advertising

  3. Azazello Guest

    On Jul 28, 1:40 am, "Hendrik van Rooyen" <> wrote:
    > <> wrote:
    >
    > > I'm attempting to start some process control using Python. I've have
    > > quite a bit of literature on networking, and have made some tinkering
    > > servers and clients for different protocols HTTP, FTP, etc... But now
    > > it's time for the murky web of industrial protocol. I'm looking to
    > > start with IO and servo controls via Ethernet.

    >
    > > Questions:

    >
    > > Is there an existing forum on this already?
    > > What protocols are the most python friendly? i.e. are transparent
    > > enough that i can create my own python driver. (or do these drivers
    > > exist?)
    > > What ethernet accesible servo and IO industrial devices have people
    > > had success with?

    >
    > What is it that you are trying to do?
    > Some of the commercial devices come with their own software, and
    > you may not need python or anything else.
    > A lot of the industrial connectivity is still RS-485 or RS-422 and not
    > Ethernet based - although some of the protocols, have, I think, been ported.
    >
    > If you say more, then someone can maybe help you, as there are quite a few
    > people on this group who seem to dabble in process control.
    >
    > - Hendrik- Hide quoted text -
    >
    > - Show quoted text



    We're looking to run some industrial machinery from a PC. Starting
    with some basic servo controls and IO port reading for something like
    an XYZ table (just X would be a good start!). Now there is some
    existing software out there for PC control but this software is, to my
    understanding, largely unnecessary and "black box". This "black box"
    creates a problem when trying to e.g. control servos and IO with the
    same program. And if we want to include an HMI like a touchscreen, or
    export the machinery's production into a RSS feed, the web of software
    becomes messy and slow. If we could consolidate this software into a
    single, non "black-box" package, we could see significant improvements
    in development time. Having to program 3 different devices with three
    different languages to control your PLC, Servos, and module X is the
    status quo we face, but it is quite frustrating and limited. Soo....
    I need to find some ethernet friendly IO, serial would be fine but but
    it's a leash in many instances. I know some protocols have been
    ported to ethernet, but I am having extreme difficulty figuring out
    what these protocols entail. ModBus/TCP is the one I'd like to
    choose. I know that people have done this kind of software but it
    seems that industrial python remains a bit taboo because of
    proprietary issues...

    Ty
     
    Azazello, Jul 30, 2007
    #3
  4. Walt Leipold Guest

    Azazello wrote:
    > We're looking to run some industrial machinery from a PC. Starting
    > with some basic servo controls and IO port reading for something like
    > an XYZ table (just X would be a good start!). Now there is some
    > existing software out there for PC control but this software is, to my
    > understanding, largely unnecessary and "black box". This "black box"
    > creates a problem when trying to e.g. control servos and IO with the
    > same program. And if we want to include an HMI like a touchscreen, or
    > export the machinery's production into a RSS feed, the web of software
    > becomes messy and slow.


    > Soo....
    > I need to find some ethernet friendly IO, serial would be fine but but
    > it's a leash in many instances. I know some protocols have been
    > ported to ethernet, but I am having extreme difficulty figuring out
    > what these protocols entail. ModBus/TCP is the one I'd like to
    > choose.


    > I know that people have done this kind of software but it
    > seems that industrial python remains a bit taboo because of
    > proprietary issues...


    It has nothing to do with 'proprietary issues'. A lot of it has to do
    with the perception of support -- who will support Python and custom
    Python code if my plant shuts down? Who will train my developers and
    operators? Who can I sue? The rest of it is because of the way the
    industry evolved, and the kinds of programmers and development teams
    that write industrial control packages.

    > If we could consolidate this software into a single, non
    > "black-box" package, we could see significant improvements
    > in development time.


    You *might* save on development time (although I wouldn't bet on it),
    but you'll lose on testing time. Heck, you'll even lose because you
    have to document your stuff and train people to use it -- what happens
    to your custom system if you get hit by a bus?

    > Having to program 3 different devices with three
    > different languages to control your PLC, Servos, and module X is
    > the status quo we face, but it is quite frustrating and limited.


    I share your frustration with the status quo in industrial automation.
    On the other hand, I've been brought in to customer sites a number of
    time to fix their re-invented wheels, and my advice is not to re-invent
    the wheel.

    Yes, it's a shame that you have to buy three packages to perform three
    functions, and then buy other 3rd-party packages to tie them together.
    Yes, it's a shame that industrial software is expensive, and
    proprietary, and Windows-only, and generally has a brain-dead scripting
    language (when it has any scriptability at all). Still, as much as it
    galls me to say it, if your company's primary business isn't writing
    industrial automation software, don't write industrial automation
    software.

    For reasons of quality, long-term supportability, manageability,
    insurability, and several other -ilities, the sad facts are:

    * Unless you're a hobbyist, if you want to do machine/motion control, do
    it from a PLC. Windows is not reliable, stable, or real-time enough to
    be trusted to control moving pieces of hardware, and custom software,
    possibly with hand-crafted multithreading, is not as reliable or
    predicatable as ladder logic on a PLC. (Look up "Therac 25" for some
    reasons why.) Python is a great language, but it depends on the
    underlying OS for threading, and has a GIL that can bite you too. The
    first time you see twenty tons of machinery move unexpectedly because
    you inadvertently changed one bit in memory, you become very
    conservative about your software platform.

    * Unless you're a hobbyist, if you want to do data acquisition or i/o,
    purchase an i/o server for your particular bus/instrumentation from a
    major manufacturer. You *can* write your own i/o server, especially for
    simple protocols like Modbus, but the commercial versions have been
    tested more exhaustively than you can manage. Also, the most common
    protocol these days is OPC, which isn't a protocol at all in the
    conventional sense -- it's a set of APIs to a Windows DLL, with the
    wire-level details completely opaque -- so you'd have to buy a library
    for that anyway.

    * Unless you're a hobbyist, if you want an HMI, purchase LabView or
    InTouch or RSView or whatever, and use their tools to draw and
    'configure' your screens. (Where 'configure' generally means 'program
    in Visual Basic or some other brain-dead language', but we try not to
    say "program" -- customers and underwriters *hate* "custom" software.)

    I personally think it's a tragedy that every manufacturer bases its HMI
    on Visual Basic for Applications rather than a better (and free and Open
    Source!) language like Python. It's also a tragedy that the dominant
    i/o 'protocol' for industrial automation isn't really a protocol, and is
    Windows-only to boot. It's horrifying that the primary means of
    communication between process control and data acquisition applications
    is via DDE or ActiveX. And I find it incredible that people and
    companies will pay large sums of money for some of the industrial
    automation products on the market. But that's the way the industry
    works, and, as frustrating as the commercial offerings are, using them
    will probably be better for you and your company in the long run.

    (Wow, that was a depressing post to write.)

    -- Walt

    "Eddies in the space-time continuum!"
    "And this is his sofa, is it?"
     
    Walt Leipold, Jul 31, 2007
    #4
  5. Azazello Guest

    On Jul 31, 12:45 pm, Walt Leipold <> wrote:
    > Azazello wrote:
    >
    > > We're looking to run some industrial machinery from a PC. Starting
    > > with some basic servo controls and IO port reading for something like
    > > an XYZ table (just X would be a good start!). Now there is some
    > > existing software out there for PC control but this software is, to my
    > > understanding, largely unnecessary and "black box". This "black box"
    > > creates a problem when trying to e.g. control servos and IO with the
    > > same program. And if we want to include an HMI like a touchscreen, or
    > > export the machinery's production into a RSS feed, the web of software
    > > becomes messy and slow.

    >
    > > Soo....
    > > I need to find some ethernet friendly IO, serial would be fine but but
    > > it's a leash in many instances. I know some protocols have been
    > > ported to ethernet, but I am having extreme difficulty figuring out
    > > what these protocols entail. ModBus/TCP is the one I'd like to
    > > choose.

    >
    > > I know that people have done this kind of software but it
    > > seems that industrial python remains a bit taboo because of
    > > proprietary issues...

    >
    > It has nothing to do with 'proprietary issues'. A lot of it has to do
    > with the perception of support -- who will support Python and custom
    > Python code if my plant shuts down? Who will train my developers and
    > operators? Who can I sue? The rest of it is because of the way the
    > industry evolved, and the kinds of programmers and development teams
    > that write industrial control packages.
    >
    > > If we could consolidate this software into a single, non
    > > "black-box" package, we could see significant improvements
    > > in development time.

    >
    > You *might* save on development time (although I wouldn't bet on it),
    > but you'll lose on testing time. Heck, you'll even lose because you
    > have to document your stuff and train people to use it -- what happens
    > to your custom system if you get hit by a bus?
    >
    > > Having to program 3 different devices with three
    > > different languages to control your PLC, Servos, and module X is
    > > the status quo we face, but it is quite frustrating and limited.

    >
    > I share your frustration with the status quo in industrial automation.
    > On the other hand, I've been brought in to customer sites a number of
    > time to fix their re-invented wheels, and my advice is not to re-invent
    > the wheel.
    >
    > Yes, it's a shame that you have to buy three packages to perform three
    > functions, and then buy other 3rd-party packages to tie them together.
    > Yes, it's a shame that industrial software is expensive, and
    > proprietary, and Windows-only, and generally has a brain-dead scripting
    > language (when it has any scriptability at all). Still, as much as it
    > galls me to say it, if your company's primary business isn't writing
    > industrial automation software, don't write industrial automation
    > software.
    >
    > For reasons of quality, long-term supportability, manageability,
    > insurability, and several other -ilities, the sad facts are:
    >
    > * Unless you're a hobbyist, if you want to do machine/motion control, do
    > it from a PLC. Windows is not reliable, stable, or real-time enough to
    > be trusted to control moving pieces of hardware, and custom software,
    > possibly with hand-crafted multithreading, is not as reliable or
    > predicatable as ladder logic on a PLC. (Look up "Therac 25" for some
    > reasons why.) Python is a great language, but it depends on the
    > underlying OS for threading, and has a GIL that can bite you too. The
    > first time you see twenty tons of machinery move unexpectedly because
    > you inadvertently changed one bit in memory, you become very
    > conservative about your software platform.
    >
    > * Unless you're a hobbyist, if you want to do data acquisition or i/o,
    > purchase an i/o server for your particular bus/instrumentation from a
    > major manufacturer. You *can* write your own i/o server, especially for
    > simple protocols like Modbus, but the commercial versions have been
    > tested more exhaustively than you can manage. Also, the most common
    > protocol these days is OPC, which isn't a protocol at all in the
    > conventional sense -- it's a set of APIs to a Windows DLL, with the
    > wire-level details completely opaque -- so you'd have to buy a library
    > for that anyway.
    >
    > * Unless you're a hobbyist, if you want an HMI, purchase LabView or
    > InTouch or RSView or whatever, and use their tools to draw and
    > 'configure' your screens. (Where 'configure' generally means 'program
    > in Visual Basic or some other brain-dead language', but we try not to
    > say "program" -- customers and underwriters *hate* "custom" software.)
    >
    > I personally think it's a tragedy that every manufacturer bases its HMI
    > on Visual Basic for Applications rather than a better (and free and Open
    > Source!) language like Python. It's also a tragedy that the dominant
    > i/o 'protocol' for industrial automation isn't really a protocol, and is
    > Windows-only to boot. It's horrifying that the primary means of
    > communication between process control and data acquisition applications
    > is via DDE or ActiveX. And I find it incredible that people and
    > companies will pay large sums of money for some of the industrial
    > automation products on the market. But that's the way the industry
    > works, and, as frustrating as the commercial offerings are, using them
    > will probably be better for you and your company in the long run.
    >
    > (Wow, that was a depressing post to write.)
    >
    > -- Walt
    >
    > "Eddies in the space-time continuum!"
    > "And this is his sofa, is it?"


    I really appreciate your post Walt. I started this thread last week
    and I have to admit that in the subsequent days the 'option' of using
    Python for our control solutions is simply not feasible. Although the
    project I wanted to implement was fairly small scale, no 20 ton pieces
    or x-ray machinery, the principle of the matter remains the same,
    especially as a large corporation. As an intern returning to school
    in the fall, the underlying responsibility for a Python system was my
    original concern and discouragement to my employer for persuing this
    path. It became readily apparent that using the crumby software
    packaged with our control devices is surely faster in the long run, as
    we are not involved in software development. (The majority of my
    coworkers' formal programming experience is in FORTRAN) It has been a
    very discouraging few days. There's so much room for improvement and
    yet... My 4-day conclusion is unless you're already involved in
    controls software you must be crazy to join. Are many young engineers
    entering this field?
     
    Azazello, Aug 1, 2007
    #5
  6. Paul Rubin Guest

    Walt Leipold <> writes:
    > The first time you see twenty tons of machinery move
    > unexpectedly because you inadvertently changed one bit in memory, you
    > become very conservative about your software platform.


    +1 QOTW
     
    Paul Rubin, Aug 1, 2007
    #6
  7. "Walt Leipold" <lei...e-net.com> wrote:

    8<--------------- summary of state of the art -------------

    > (Wow, that was a depressing post to write.)


    Cheer up! - The end is nigh!

    Warning:
    The rest of this post is barely on topic for python,
    and contains some shameless self advertising. Its
    probably bad for your health too.

    I have just spent considerable time developing some stuff.

    I call it SDCL - simple distributed control language

    Its a simple scripting language, that is interpreted.

    The HMI bits are python, the "compiler" is python,
    the simulator is python, the interpreter in the PC is
    python. What is not python is the interpreter in the
    PLC - that is a mix of Assembler and C, for speed.

    You can run the code either in the PC, or in the PLC,
    or as a mix of both - obviously fast stuff needs to run
    in the real hardware, but a lot of the control, checking
    and sequencing functions fall naturally into the PC.
    With the PC logging, you get ISO 900x almost
    automatically, as any change to a variable that lives in
    the PC is logged.

    The language is still a bit "brain dead" - it implements a
    virtual Reverse Polish Notation stack machine and reads
    like assembler, with less than 40 instructions to learn.

    A real compiler is planned for some unspecified future time.

    The first app is an injection moulding machine, and it has
    been working for some months now, with crude animation
    of the machine's motions on screen, and everything from
    star-delta timing to thermocouple heating inputs and control,
    as well as screw position and injection pressure sensing on
    the PLC.

    There are just over 3000 instructions in the sequence to
    control this machine, and the "address space" is 64k of
    instructions - so it is aimed at fairly serious control.

    Unfortunately at this stage the "PLC" is Microcorp proprietary.

    But the whole thing is aimed at simplifying the problem of
    putting voltages on wires and reporting the results to a PC.

    I intend to open the spec as soon as I am satisfied that there
    are no fearsome dragons left lurking in the code or the design.

    - Hendrik
     
    Hendrik van Rooyen, Aug 1, 2007
    #7
  8. In article <>,
    <> wrote:
    >
    >
    >I'm attempting to start some process control using Python. I've have

    .
    .
    .
    >Is there an existing forum on this already?

    .
    .
    .
    <URL: http://www.engcorp.com/acf/RecentChanges >

    It's been dormant for a while, but it wouldn't take much to
    restore its vitality.
     
    Cameron Laird, Aug 13, 2007
    #8
  9. In article <>,
    Azazello <> wrote:
    >On Jul 31, 12:45 pm, Walt Leipold <> wrote:

    .
    .
    .
    >> It has nothing to do with 'proprietary issues'. A lot of it has to do
    >> with the perception of support -- who will support Python and custom
    >> Python code if my plant shuts down? Who will train my developers and
    >> operators? Who can I sue? The rest of it is because of the way the

    .
    .
    .
    >> You *might* save on development time (although I wouldn't bet on it),
    >> but you'll lose on testing time. Heck, you'll even lose because you
    >> have to document your stuff and train people to use it -- what happens
    >> to your custom system if you get hit by a bus?

    .
    .
    .
    >> Yes, it's a shame that you have to buy three packages to perform three
    >> functions, and then buy other 3rd-party packages to tie them together.
    >> Yes, it's a shame that industrial software is expensive, and
    >> proprietary, and Windows-only, and generally has a brain-dead scripting
    >> language (when it has any scriptability at all). Still, as much as it
    >> galls me to say it, if your company's primary business isn't writing
    >> industrial automation software, don't write industrial automation
    >> software.

    .
    .
    .
    >> * Unless you're a hobbyist, if you want to do data acquisition or i/o,
    >> purchase an i/o server for your particular bus/instrumentation from a
    >> major manufacturer. You *can* write your own i/o server, especially for
    >> simple protocols like Modbus, but the commercial versions have been
    >> tested more exhaustively than you can manage. Also, the most common
    >> protocol these days is OPC, which isn't a protocol at all in the
    >> conventional sense -- it's a set of APIs to a Windows DLL, with the
    >> wire-level details completely opaque -- so you'd have to buy a library
    >> for that anyway.
    >>
    >> * Unless you're a hobbyist, if you want an HMI, purchase LabView or
    >> InTouch or RSView or whatever, and use their tools to draw and
    >> 'configure' your screens. (Where 'configure' generally means 'program
    >> in Visual Basic or some other brain-dead language', but we try not to
    >> say "program" -- customers and underwriters *hate* "custom" software.)
    >>
    >> I personally think it's a tragedy that every manufacturer bases its HMI
    >> on Visual Basic for Applications rather than a better (and free and Open
    >> Source!) language like Python. It's also a tragedy that the dominant
    >> i/o 'protocol' for industrial automation isn't really a protocol, and is
    >> Windows-only to boot. It's horrifying that the primary means of
    >> communication between process control and data acquisition applications
    >> is via DDE or ActiveX. And I find it incredible that people and
    >> companies will pay large sums of money for some of the industrial
    >> automation products on the market. But that's the way the industry
    >> works, and, as frustrating as the commercial offerings are, using them
    >> will probably be better for you and your company in the long run.

    .
    .
    .
    >I really appreciate your post Walt. I started this thread last week
    >and I have to admit that in the subsequent days the 'option' of using
    >Python for our control solutions is simply not feasible. Although the
    >project I wanted to implement was fairly small scale, no 20 ton pieces
    >or x-ray machinery, the principle of the matter remains the same,
    >especially as a large corporation. As an intern returning to school
    >in the fall, the underlying responsibility for a Python system was my
    >original concern and discouragement to my employer for persuing this
    >path. It became readily apparent that using the crumby software
    >packaged with our control devices is surely faster in the long run, as
    >we are not involved in software development. (The majority of my
    >coworkers' formal programming experience is in FORTRAN) It has been a
    >very discouraging few days. There's so much room for improvement and
    >yet... My 4-day conclusion is unless you're already involved in
    >controls software you must be crazy to join. Are many young engineers
    >entering this field?
    >


    At an anecdotal level, I'd guess that, no, there are few
    young engineers entering this field.

    Mr. Leipold's descriptions of the difficulties involved
    in use of Python are accurate, and I particularly support
    his advice to use whatever commercial I/O you can find.
    I've had success, though, introducing high-level language
    programming, and even Linux, as an alternative to vendors'
    APIs, Labview, and so on. I'm not sure how to summarize
    what went into this; perhaps the best is to emphasize how
    flawed is the software that's typical with vendor APIs.

    While there's more to tell about the errors in commercial
    networking implementations, the horror of ActiveX, and so
    on, right now isn't the time for me to detail it all.
     
    Cameron Laird, Aug 13, 2007
    #9
  10. In article <>, I mused:
    >In article <>,
    >Azazello <> wrote:
    >>On Jul 31, 12:45 pm, Walt Leipold <> wrote:

    > .
    > .
    > .
    >>> It has nothing to do with 'proprietary issues'. A lot of it has to do
    >>> with the perception of support -- who will support Python and custom
    >>> Python code if my plant shuts down? Who will train my developers and
    >>> operators? Who can I sue? The rest of it is because of the way the

    > .
    > .
    > .
    >>> Yes, it's a shame that you have to buy three packages to perform three
    >>> functions, and then buy other 3rd-party packages to tie them together.
    >>> Yes, it's a shame that industrial software is expensive, and
    >>> proprietary, and Windows-only, and generally has a brain-dead scripting
    >>> language (when it has any scriptability at all). Still, as much as it
    >>> galls me to say it, if your company's primary business isn't writing
    >>> industrial automation software, don't write industrial automation
    >>> software.

    > .
    > .
    > .
    >>> * Unless you're a hobbyist, if you want to do data acquisition or i/o,
    >>> purchase an i/o server for your particular bus/instrumentation from a
    >>> major manufacturer. You *can* write your own i/o server, especially for
    >>> simple protocols like Modbus, but the commercial versions have been
    >>> tested more exhaustively than you can manage. Also, the most common
    >>> protocol these days is OPC, which isn't a protocol at all in the
    >>> conventional sense -- it's a set of APIs to a Windows DLL, with the
    >>> wire-level details completely opaque -- so you'd have to buy a library
    >>> for that anyway.

    .
    .
    .
    >>> on Visual Basic for Applications rather than a better (and free and Open
    >>> Source!) language like Python. It's also a tragedy that the dominant
    >>> i/o 'protocol' for industrial automation isn't really a protocol, and is
    >>> Windows-only to boot. It's horrifying that the primary means of
    >>> communication between process control and data acquisition applications
    >>> is via DDE or ActiveX. And I find it incredible that people and
    >>> companies will pay large sums of money for some of the industrial
    >>> automation products on the market. But that's the way the industry
    >>> works, and, as frustrating as the commercial offerings are, using them
    >>> will probably be better for you and your company in the long run.

    > .
    > .
    > .
    >>I really appreciate your post Walt. I started this thread last week
    >>and I have to admit that in the subsequent days the 'option' of using
    >>Python for our control solutions is simply not feasible. Although the
    >>project I wanted to implement was fairly small scale, no 20 ton pieces
    >>or x-ray machinery, the principle of the matter remains the same,
    >>especially as a large corporation. As an intern returning to school
    >>in the fall, the underlying responsibility for a Python system was my
    >>original concern and discouragement to my employer for persuing this
    >>path. It became readily apparent that using the crumby software
    >>packaged with our control devices is surely faster in the long run, as
    >>we are not involved in software development. (The majority of my
    >>coworkers' formal programming experience is in FORTRAN) It has been a
    >>very discouraging few days. There's so much room for improvement and
    >>yet... My 4-day conclusion is unless you're already involved in
    >>controls software you must be crazy to join. Are many young engineers
    >>entering this field?
    >>

    >
    >At an anecdotal level, I'd guess that, no, there are few
    >young engineers entering this field.

    .
    .
    .
    'Just occurred to me that a GREAT thing to do might be for a young
    engineer to catch the SD Best Practices 2007 East in Boston in
    September <URL: http://www.sdexpo.com/2007/sdbp/overview.htm >,
    which is running concurrently with Embedded Systems <URL:
    http://www.embedded.com/esc/boston/ > (as well as RFID World <URL:
    http://www.rfid-world.com/boston/ >). They sell inspiration by the
    half-hour.
     
    Cameron Laird, Aug 13, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rithesh Pai
    Replies:
    1
    Views:
    5,599
  2. walala
    Replies:
    3
    Views:
    743
    Allan Herriman
    Sep 9, 2003
  3. rtm
    Replies:
    0
    Views:
    800
  4. Jerry
    Replies:
    4
    Views:
    5,972
    Marina
    Dec 15, 2003
  5. Jason Kendall
    Replies:
    1
    Views:
    149
    Patrice
    Jun 1, 2005
Loading...

Share This Page