Re: Python in Process Control?

Discussion in 'Python' started by Neil Benn, Oct 3, 2004.

  1. Neil Benn

    Neil Benn Guest

    Hello,

    Comments beneath :

    Peter L Hansen <> wrote in message
    news:<>...
    <snip>
    > I meant to mention, but only barely implied, that the source is
    > actually available, on Engenuity's project page. It was a
    > Cavro RSP9000 robot.


    Oh, how long ago was that as far as I know that model was discontinued a
    long time ago. I skipped a few of them myself (there's nothing wrong
    with the machine - it's just an old model and not up to today's standards).

    <snip>
    > I use the terms "industrial control" and "automation" rather
    > interchangeably, along with "laboratory robotics" and other
    > terms. It's all the same thing, regardless of the end user,
    > except when regulatory issues get involved (aeronautics, FDA
    > approvals, etc).


    Hmm, not sure about that - you need to look at the process it is being
    used in and the cost of downtime. In addition you also have to consider
    the end users and the cost of a lost unit - this is why people talk
    about industrial automation in a lab setting with no concept of what
    they mean, in the field of laboratory automaiton industrial automation
    is typically used as a marketing slogan!!

    In life science unit cost is an awkward indicator as it is very
    difficult to put a cost on a lost unit - it could be nothing, it could
    be billions!! If you are interested in this field then there is an
    active mailing list on laboratory automation, you can access it trhough
    the american link of www.lab-robotics.org or the European link
    www.elrig.org.
    >
    > > IMHO, I think that Python is not a suitable piece of software for
    > > industrial control as it has poor support for bytes (a string

    shouldn't
    > > be used to store bytes!) and also bit twiddling is difficult

    (people who
    > > ask about his on the Python newsgroup are usually shouted at).

    >
    > Well, let me see how to answer this politely. :) What you *think*
    > and what is reality are not necessarily the same thing. ;-) No,
    > the more polite answer is really that this is an area where perhaps
    > it's more a matter of opinion than anything else, and mine differs
    > from yours.


    Yep, that's why I put IMHO - don't get me wrong, I have used python
    for control and it has good sides and bad sides - like everything in
    life! I j

    >
    > Python certainly has *excellent* ("perfect"?) support for manipulating
    > bytes, and if you consider that a string is not a string, but is
    > actually a sequence of bytes, then other than being misnamed for
    > this application area, a string provides great support for bytes...
    > certainly *in practice* it works wonderfully, and I guess as someone
    > who has used Python very successfully for industrial control I'm
    > somewhat qualified to say so.


    I've also got python running controlling a bunch of kit - as for byte
    support, sorry but a byte array should not have the ability to be
    changed into upper case unless it represents characters - which bytes
    patently do not. I know it works in python but it's an incorrect
    metaphor. In the same way that a string is not a bunch of 8 bit chars
    (encoding.decoding etc). Although yep, if you ignore the fact that it
    is a string, with the string stuff tagged onto the side then you can go
    ahead and use it with gay abandon.

    >
    > As for bit-twiddling, it's rarer than you might think to have to
    > do more than the odd shift, OR, and AND masking, and maybe an
    > exclusive-OR or two for spice, and Python is well enough suited that
    > this isn't really an issue. Performance-wise, if you have to do
    > such things to a very high-bandwidth stream of data, it might run
    > into troubles, but (a) there are options, and (b) it hasn't bothered
    > me yet...


    If I can't twiddle bits correctly - I'm a bit stuck if I need to make a
    check sum from the bits in a byte array. The RSP9000 doesn't require
    that sort of thing (or so I thought but I controlled the RSP9000 using
    the Turbo Pascal interface supplied with the machine rather than direct
    RS232 commands) but other kit does. Also in my experience (~1 decade
    controlling and managing lab autoamtion) bit twiddling is something I've
    had to do a few times - it just depends on the interface supplied by the
    manufacturer. Java's not much better at this either - I ended up
    writing a bit twiddling class to handle this - it's just that most
    business apps don't need bit twiddling so it's fallen out of popularity.
    >
    > I was going to show an example from the Cavro code mentioned above,
    > but all it took was a few | and & operations and it's too boring
    > to show.


    Nope I'm a geek!! I couldn't find it on your website though.

    >
    > > The
    > > other thing that is a problem for python in this is that it is very
    > > difficult in python to make your your client is aware of all the

    errors
    > > that you can throw and as you know, when controlling equipment

    there is
    > > a lot of things that are out of your control (an exception that is
    > > rarely thrown will often not be caught if the programmer never sees it
    > > running and gets lazy).

    >
    > Absolutely! Uncaught exceptions would be a real pain to a customer.
    >
    > So would untested code.
    >

    By client - I mean client calling my code; not a customer - a checked
    exception is an excellent way of making the client calling code writer
    think about these errors. People who are unused to controlling machines
    are often unaware of the lack of control you have over yuor environment.
    However, test driven development is a tool that is used in many
    languages - not just python. Certainly in the control of machines you
    must test and test again - however test driven development is a tool
    that can be used alongside a variety of other tools such as UML, checked
    exceptions and stress testing (that's what I call playing Doom3 while
    controlling the robot with your code). TDD is not a magic wand, it's
    just common sense (to me anyway).
    >
    > > apps a little easier to write - although I still spent about 2 days
    > > trying to work out how to make a variable volatile (culminating in
    > > understanding the threading module!).

    >
    > All variables are "volatile" in Python, at least in most senses of
    > the word. I don't understand what you were doing...


    Exactly, because python has a GIL and can only run in one processor a
    variable will never need to be marked as volatile. In other systems
    this is something I would need to be concerned about - not in python!
    <snip>
    > You might want to investigate the use of Twisted's serial module,
    > which wraps around PySerial and effectively provides this, instead
    > of doing the polling loop approach (which, by the way, I also used
    > in the Cavro code but might change to Twisted in a later version).


    Cheers, I wrote a wrapper around PySerial to implement
    listeners/observers (that's what the polling loop does, Twisted probably
    does the same) - although if there is a published and supported
    implementation then I'll use that.

    <snip>
    > Actually, we *did* use ActiveX, unfortunately, because that's what
    > the customer wanted to use to interface LabVIEW to the driver <snip>

    LabView isn't a bad tool, the use of wiring metaphors appeals greatly to
    engineers (as you'v probably expereicend) - also it is (again IMO) one
    of the best graphical programming tools out there. I don;t use it
    because I can program and flow control in LabView is a pain but that
    doesn;t stop me having an a look in every now and then.
    >
    > -Peter


    This is my second attempt at a response - so if you get two mails back
    then please forgive me!

    Cheers,

    Neil
    Neil Benn, Oct 3, 2004
    #1
    1. Advertising

  2. Neil Benn wrote:
    > Peter L Hansen <> wrote in message
    > news:<>...
    > <snip>
    > > I meant to mention, but only barely implied, that the source is
    > > actually available, on Engenuity's project page. It was a
    > > Cavro RSP9000 robot.

    >
    > Oh, how long ago was that as far as I know that model was discontinued a
    > long time ago. I skipped a few of them myself (there's nothing wrong
    > with the machine - it's just an old model and not up to today's standards).


    The project was only a couple of months ago. I have no idea how
    old the robot itself was, but that wasn't my concern. The customer
    had a robot and needed software... maybe he got it on Ebay. :)

    > <snip>
    > > I use the terms "industrial control" and "automation" rather
    > > interchangeably, along with "laboratory robotics" and other
    > > terms. It's all the same thing, regardless of the end user,
    > > except when regulatory issues get involved (aeronautics, FDA
    > > approvals, etc).

    >
    > Hmm, not sure about that - you need to look at the process it is being
    > used in and the cost of downtime. In addition you also have to consider
    > the end users and the cost of a lost unit - this is why people talk
    > about industrial automation in a lab setting with no concept of what
    > they mean, in the field of laboratory automaiton industrial automation
    > is typically used as a marketing slogan!!
    > In life science unit cost is an awkward indicator as it is very
    > difficult to put a cost on a lost unit - it could be nothing, it could
    > be billions!! If you are interested in this field then there is an
    > active mailing list on laboratory automation, you can access it trhough
    > the american link of www.lab-robotics.org or the European link
    > www.elrig.org.


    No idea what you are talking about, really. When I use the terms
    I used above, I mean nothing either more or less than "using a
    computer to control other equipment". Even talking to a
    spectrum analyzer while controlling a signal generator falls under
    the rubrik "industrial control" as far as I'm concerned. Unit
    costs? Downtime? Orthogonal issues which don't affect the term.

    Hey, if anyone has a nice catch-all title that covers what you
    call laboratory automation and what you call process control
    and what you'd call the example I just gave, but which isn't
    "industrial control", please offer it here. I'd much rather
    use a term that covers the whole spectrum rather than have to
    list each subcategory of an unnamed general category each time
    I try to talk to someone about it...

    > > Python certainly has *excellent* ("perfect"?) support for manipulating
    > > bytes, and if you consider that a string is not a string, but is
    > > actually a sequence of bytes, then other than being misnamed for
    > > this application area, a string provides great support for bytes...
    > > certainly *in practice* it works wonderfully, and I guess as someone
    > > who has used Python very successfully for industrial control I'm
    > > somewhat qualified to say so.

    >
    > I've also got python running controlling a bunch of kit - as for byte
    > support, sorry but a byte array should not have the ability to be
    > changed into upper case unless it represents characters - which bytes
    > patently do not.


    I haven't encountered any of my byte arrays accidentally ending
    up with the alphabetic characters upper-cased on me... maybe you
    need to do more testing. <wink> :) Really, who cares if the
    data type used happens to support some functionality that doesn't
    apply to the area you use it for? Nobody is forcing you to put
    ..upper() in your code...

    > Although yep, if you ignore the fact that it
    > is a string, with the string stuff tagged onto the side then you can go
    > ahead and use it with gay abandon.


    I guess that's exactly what I do. Yippee-kay-yay!! ;-)

    > Nope I'm a geek!! I couldn't find it on your website though.


    http://www.engcorp.com/main/projects/FrontPage under the name
    CavroCom...

    > By client - I mean client calling my code; not a customer - a checked
    > exception is an excellent way of making the client calling code writer
    > think about these errors. People who are unused to controlling machines
    > are often unaware of the lack of control you have over yuor environment.
    > However, test driven development is a tool that is used in many
    > languages - not just python. Certainly in the control of machines you
    > must test and test again - however test driven development is a tool
    > that can be used alongside a variety of other tools such as UML, checked
    > exceptions and stress testing (that's what I call playing Doom3 while
    > controlling the robot with your code). TDD is not a magic wand, it's
    > just common sense (to me anyway).


    No real disagreement there...

    > Cheers, I wrote a wrapper around PySerial to implement
    > listeners/observers (that's what the polling loop does, Twisted probably
    > does the same) - although if there is a published and supported
    > implementation then I'll use that.


    As I commented (I believe) in an offline reply to your earlier email,
    I don't think the way Twisted does this is likely to be a close
    enough fit to the architecture of your app to bother, but feel
    free to investigate. I haven't yet attempted to convert the
    stuff that I wrote on PySerial to use Twisted, but I plan an
    experiment soon.

    > This is my second attempt at a response - so if you get two mails back
    > then please forgive me!


    No problem. I believe I got and replied to an offline query(*) with
    some of the same content, but in any case I'm much happier carrying
    on such discussions "in public" where others can contribute, flame
    us as the idiots we are for not knowing about project X on Sourceforge
    (which they just started last week) which will do exactly what
    we want, and so on. ;-)

    -Peter

    (*) But it's equally possible either your or my spam-filter dropped
    a message and we never saw it. ;-)
    Peter L Hansen, Oct 3, 2004
    #2
    1. Advertising

  3. On Sun, 03 Oct 2004 18:59:41 -0400, Peter L Hansen <>
    wrote:

    >No problem. I believe I got and replied to an offline query(*) with
    >some of the same content, but in any case I'm much happier carrying
    >on such discussions "in public" where others can contribute, flame
    >us as the idiots we are for not knowing about project X on Sourceforge
    >(which they just started last week) which will do exactly what
    >we want, and so on. ;-)


    I think that python could be very useful in a lot of
    areas of industrial control (often there's no
    hard-realtime constraint and you can use a consumer
    PC for the software).

    The only thing that scares me a bit about using python
    is that industrial control is (at least for the part
    I'm seeing for my job) terribly closed-source.
    I see for example that its very very common to use
    even hardware locks for the software.

    I'm not my boss, and could be hard to explain that it's
    not a problem using an interpreted language that is
    easily decompilable and using modules with licenses
    that are basically nonsense in this context.
    To a very specific question I was answered here that
    the best thing to do before using e.g. pygame in a
    closed source product is consulting a lawyer; and
    that obtaining a clear answer would have been a sign
    that the consulted lawyer isn't a good one.

    Andrea
    Andrea Griffini, Oct 4, 2004
    #3
  4. Andrea Griffini wrote:
    > The only thing that scares me a bit about using python
    > is that industrial control is (at least for the part
    > I'm seeing for my job) terribly closed-source.
    > I see for example that its very very common to use
    > even hardware locks for the software.


    That's true, and sadly so. It's also one of the things
    which Cameron and I and others are keen to see change,
    and which change we believe would have a significant
    and positive impact on the industry in a variety of ways.

    Having companies always rewrite their own copy of something
    from scratch is a stupid, stupid way to do business, when
    their business is not supposed to be writing drivers for
    obscure pieces of hardware.

    Having those companies wake up and smell the coffee --
    which in this case is their competition, companies like
    mine, which are accelerating many times over their
    productivity by using modern tools and techniques
    and by *sharing* non-core stuff -- is one of the goals
    we've been talking about here.

    > I'm not my boss, and could be hard to explain that it's
    > not a problem using an interpreted language that is
    > easily decompilable and using modules with licenses
    > that are basically nonsense in this context.


    This sort of thing is ultimately not an issue with
    Python per se, or is only slightly more an issue with
    Python than with some other languages. I've yet to
    see a library that couldn't be used in spite of its
    supposed hardware or software copy protection. Better
    to try to find reasons for customers to keep paying
    you (support, access to improvements) than to worry
    that you might have missed some revenue from a few
    that are unethical crooks...

    > To a very specific question I was answered here that
    > the best thing to do before using e.g. pygame in a
    > closed source product is consulting a lawyer; and
    > that obtaining a clear answer would have been a sign
    > that the consulted lawyer isn't a good one.


    It's an answer, and in some ways a good one, but in
    other ways it passes the buck to someone who is in the
    business of telling people what they already know and
    fear is true: there are no guarantees, nothing you can
    do can actually *prevent* you from getting sued, and
    by the way please pay my last invoice for $400/hour...

    I'd say the "best thing" to do would be to start by
    collecting the various licenses involved and actually
    looking them over. I haven't done that with PyGame,
    but unless it includes GPL stuff, there's a decent
    chance that there's no real impediment to using it
    in a closed source product, except perhaps your guilt
    at attempting to profit from the hard work of many
    others without even a token attempt to contribute
    something back to the community. ;-)

    -Peter
    Peter L Hansen, Oct 4, 2004
    #4
  5. In article <>,
    Peter L Hansen <> wrote:
    >Andrea Griffini wrote:
    >> The only thing that scares me a bit about using python
    >> is that industrial control is (at least for the part
    >> I'm seeing for my job) terribly closed-source.
    >> I see for example that its very very common to use
    >> even hardware locks for the software.

    >
    >That's true, and sadly so. It's also one of the things
    >which Cameron and I and others are keen to see change,
    >and which change we believe would have a significant
    >and positive impact on the industry in a variety of ways.
    >
    >Having companies always rewrite their own copy of something
    >from scratch is a stupid, stupid way to do business, when
    >their business is not supposed to be writing drivers for
    >obscure pieces of hardware.
    >
    >Having those companies wake up and smell the coffee --
    >which in this case is their competition, companies like
    >mine, which are accelerating many times over their
    >productivity by using modern tools and techniques
    >and by *sharing* non-core stuff -- is one of the goals
    >we've been talking about here.

    .
    [more of the same]
    .
    .
    Peter does a fine job of speaking for both of us. On the
    off chance that my words will be meaningful to a few readers
    his haven't already reached, I'll say this for myself:

    I recognize that our approach is surprising and even alarming
    to many in process control. I'm cranky enough to think that
    history's on my side, in this case: eventually it'll be ac-
    ceptable for process control vendors and customers to act
    rationally (in a technical sense I claim I can make explicit),
    rather than in their anachronistically territorial current
    habits. Rather than worry much about how to get there, I'm
    just going to act as though high productivity and high
    reliability are as important to others as they are to me. I
    leave it to others to figure out what laws and licenses will
    make sense of all this.

    Wake up enough, and you can smell the roses, too.
    Cameron Laird, Oct 4, 2004
    #5
  6. On Sun, 03 Oct 2004 20:59:07 -0400, Peter L Hansen <>
    wrote:

    >Having companies always rewrite their own copy of something
    >from scratch is a stupid, stupid way to do business, when
    >their business is not supposed to be writing drivers for
    >obscure pieces of hardware.


    Actually I've observed that the "closed" behaviour is
    not only from companies; but even in the research field.
    For example on 3D graphics you can find a plethora of
    documents on the internet down to the level of the
    smallest detail and paper *sold* from universities
    are the exception.
    I saw this being the opposite (a lot of papers are sold,
    a few are free and they don't get to the details) even
    about problems that have been probably solved a jillion
    times like "good" path computation under dynamic constraints
    or motor control.

    In my case I preferred solving the problem myself for
    the context I faced instead of buying docs about the
    solution (after all I don't expect the quality of them
    to be terribly high... I wonder for example if researchers
    in this area buy each other papers to know what others are
    investigating in and what results they got).

    In this field seems to me that really people try to
    get above by standing on each other feet instead than
    on each other shoulders; but this doesn't look to me
    like just a software problem.

    May be there are reasons for this being the status quo...
    for example research in this area is terribly more
    expensive than in the pure software field where you
    can get quite far just with a $500 PC and some pizza.

    ....

    >I'd say the "best thing" to do would be to start by
    >collecting the various licenses involved and actually
    >looking them over. I haven't done that with PyGame,
    >but unless it includes GPL stuff, there's a decent
    >chance that there's no real impediment to using it
    >in a closed source product, except perhaps your guilt
    >at attempting to profit from the hard work of many
    >others without even a token attempt to contribute
    >something back to the community. ;-)


    A problem is the LGPL licensing that requires you to
    allow your users to re-link the program with a newer
    version of the library. This is IMO both basically a
    nonsense in this field (I can't think to a customer
    even *wanting* to change the library version in a NC
    machine he bought, often the investments are rather
    high and the approach I see is "if it works just don't
    dare to think about touching it") and annoying.
    Also I don't understand what is required if a new
    version of the library for example changes part of
    the interface ... does this imply you're forced to
    leave the source code so that it can be adapted to the
    new library interface (even if may be not the rights
    to use it past the re-linking requirement) ?

    For pygame I've rewritten (mostly as an exercise in
    writing python extensions) the part that I really
    need that is just a little part of the screen and
    surface handling as a C module ... after all I'm
    not going to need sounds or other fancy things
    present in pygame like CD, joystick, or movies.

    I don't know if this trying to be opaque to competitors
    is really the root of all evil... but even if this is
    the case I'm not in the position to decide about those
    issues. My impression is that being forced to be
    transparent if using python would simply mean wiping
    python out from the option list.

    Andrea
    Andrea Griffini, Oct 5, 2004
    #6
  7. On Tue, 05 Oct 2004 06:10:17 GMT, Andrea Griffini <> wrote:
    > In this field seems to me that really people try to
    > get above by standing on each other feet instead than
    > on each other shoulders; but this doesn't look to me
    > like just a software problem.


    Nice definition.

    > ... (I can't think to a customer
    > even *wanting* to change the library version in a NC
    > machine he bought, often the investments are rather
    > high and the approach I see is "if it works just don't
    > dare to think about touching it")


    I think you've nailed the root of the problem (or at least one of the
    roots). For the most part, customers tend to be careful, and they
    approach solutions in this area as true 'black boxes'. It may be
    because they're afraid of the unknown, or because bugs in control
    software can be really costly, and they don't want to be held liable
    for it (at least they can say, "I never messed with it, if it's
    broken, it's not my fault").

    Put in other words: In many cases (not all, of course), the people who
    buy this stuff are not engineers -- who in some cases are not even
    involved with the process --, but the money guys. It's expensive, it
    will save the company money, so the money guys sign the bill... but
    only if someone else (the vendor) takes full responsibility for it.
    It's a recipe for close solutions, in my opinion. The money guys also
    tend to buy the same stuff other companies bought, which makes this
    behavior self-sustaining, in a way.

    Keeping with the same reasoning line, why don't the engineers that
    work in the company take more responsibility? Because they were never
    in such a position. They don't have a choice. They have to keep things
    running, period. The one who messes up with stuff is fired. And doing
    development is not their company business, anyway. Want to do it? Go
    working for a vendor.

    BTW, this kind of behaviour can't last forever. It's inefficient, and
    it's doomed to death, sooner or later.

    --
    Carlos Ribeiro
    Consultoria em Projetos
    blog: http://rascunhosrotos.blogspot.com
    blog: http://pythonnotes.blogspot.com
    mail:
    mail:
    Carlos Ribeiro, Oct 5, 2004
    #7
  8. On Tue, 5 Oct 2004 12:12:39 -0300, Carlos Ribeiro
    <> wrote:

    >On Tue, 05 Oct 2004 06:10:17 GMT, Andrea Griffini <> wrote:
    >> In this field seems to me that really people try to
    >> get above by standing on each other feet instead than
    >> on each other shoulders; but this doesn't look to me
    >> like just a software problem.

    >
    >Nice definition.


    I liked it too... it's not mine.

    I don't remember where I read it (probably in a site about
    (against) software patents).

    >Keeping with the same reasoning line, why don't the engineers that
    >work in the company take more responsibility? Because they were never
    >in such a position. They don't have a choice. They have to keep things
    >running, period. The one who messes up with stuff is fired. And doing
    >development is not their company business, anyway. Want to do it? Go
    >working for a vendor.


    Well... in our case we have customers that didn't probably
    see an engineer in past 10 years. Still they can buy and use
    rather hi-tech machines from us that cost several tens of
    thousands of dollars. It doesn't come as a surprise to me they
    don't want to take the responsibility for them being functional.
    A sad part is that sometimes our customer support has to
    spend time to explain people what does it mean to copy a file
    from a floppy disk to a certain directory; but I've to say
    that the users that create more troubles are actually the
    "expert" ones. I would actually refuse to provide any support
    to anyone relinking my application with a newer versions of
    a library... you really wanna do it ? You're welcome, but
    don't call me if something doesn't work and you've something
    urgent to do with the system... unless you really like being
    insulted over the phone. Luckily this doesn't happen often...
    It's much more common (and a bit annoying) to see someone
    fearing updates...

    In the software development we're IMO still at the barbarian
    level. Anyone can write anything, and no one takes any
    responsibility for what has done. In our world you can buy
    a spreadsheet and read in the disclaimer that if putting 5
    in a cell, and 5 in another and asking for the sum you get 11
    then you can't even ask for a refound; let alone the payment
    for consequential damages. Try to imagine people building
    airplanes using the same spirit.

    Andrea
    Andrea Griffini, Oct 5, 2004
    #8
  9. On Tue, 05 Oct 2004 21:51:31 GMT, Andrea Griffini <> wrote:
    > On Tue, 5 Oct 2004 12:12:39 -0300, Carlos Ribeiro
    > <> wrote:
    > >Keeping with the same reasoning line, why don't the engineers that
    > >work in the company take more responsibility? Because they were never
    > >in such a position. They don't have a choice. They have to keep things
    > >running, period. The one who messes up with stuff is fired. And doing
    > >development is not their company business, anyway. Want to do it? Go
    > >working for a vendor.

    >
    > Well... in our case we have customers that didn't probably
    > see an engineer in past 10 years. Still they can buy and use
    > rather hi-tech machines from us that cost several tens of
    > thousands of dollars. It doesn't come as a surprise to me they
    > don't want to take the responsibility for them being functional.


    I was afraid that my experience would not reflect the state of the art
    elsewhere. Seems it wasn't any far from truth :)

    > A sad part is that sometimes our customer support has to
    > spend time to explain people what does it mean to copy a file
    > from a floppy disk to a certain directory; but I've to say
    > that the users that create more troubles are actually the
    > "expert" ones. I would actually refuse to provide any support
    > to anyone relinking my application with a newer versions of
    > a library... you really wanna do it ? You're welcome, but
    > don't call me if something doesn't work and you've something
    > urgent to do with the system... unless you really like being
    > insulted over the phone. Luckily this doesn't happen often...
    > It's much more common (and a bit annoying) to see someone
    > fearing updates...


    When the market finally awakes from the stone age, you'll surely start
    to get more calls like this. Not only from people relinking, but
    patches, and *real* bug tickets found by your very customers. Get used
    to it. You can't complain this way once the market is open.


    --
    Carlos Ribeiro
    Consultoria em Projetos
    blog: http://rascunhosrotos.blogspot.com
    blog: http://pythonnotes.blogspot.com
    mail:
    mail:
    Carlos Ribeiro, Oct 5, 2004
    #9
  10. Neil Benn

    Neil Benn Guest

    Carlos Ribeiro wrote:

    >On Tue, 05 Oct 2004 21:51:31 GMT, Andrea Griffini <> wrote:
    >
    >
    >>On Tue, 5 Oct 2004 12:12:39 -0300, Carlos Ribeiro
    >><> wrote:
    >>
    >>
    >>>Keeping with the same reasoning line, why don't the engineers that
    >>>work in the company take more responsibility? Because they were never
    >>>in such a position. They don't have a choice. They have to keep things
    >>>running, period. The one who messes up with stuff is fired. And doing
    >>>development is not their company business, anyway. Want to do it? Go
    >>>working for a vendor.
    >>>
    >>>

    >>Well... in our case we have customers that didn't probably
    >>see an engineer in past 10 years. Still they can buy and use
    >>rather hi-tech machines from us that cost several tens of
    >>thousands of dollars. It doesn't come as a surprise to me they
    >>don't want to take the responsibility for them being functional.
    >>
    >>

    >
    >I was afraid that my experience would not reflect the state of the art
    >elsewhere. Seems it wasn't any far from truth :)
    >
    >

    Engineers working at a user site need to be multi skilled (external
    facing, internal facing, technically competent) and therefore
    expensive. If you have an engineer who you want to do development,
    cha-ching add in some more salary. I would much much prefer to have no
    engineer that an incompetent one and a competent one costs a lot of
    money - something that some companies may not be able to afford.

    To the money men thing - if that is your experience then the company
    was run incorrectly - most people I speak to - a purchase decision is
    made between the user, on -site engineer, finance and managers. Any
    company in which the finance department purchases equipment without
    consulting the people involved in the process is bad, bad - bad!

    >
    >
    >>A sad part is that sometimes our customer support has to
    >>spend time to explain people what does it mean to copy a file
    >>from a floppy disk to a certain directory; but I've to say
    >>that the users that create more troubles are actually the
    >>"expert" ones. I would actually refuse to provide any support
    >>to anyone relinking my application with a newer versions of
    >>a library... you really wanna do it ? You're welcome, but
    >>don't call me if something doesn't work and you've something
    >>urgent to do with the system... unless you really like being
    >>insulted over the phone. Luckily this doesn't happen often...
    >>It's much more common (and a bit annoying) to see someone
    >>fearing updates...
    >>
    >>

    >
    >When the market finally awakes from the stone age, you'll surely start
    >to get more calls like this. Not only from people relinking, but
    >patches, and *real* bug tickets found by your very customers. Get used
    >to it. You can't complain this way once the market is open.
    >
    >

    Yes you can, if you open something up you will _still_ get people
    screwing things up. Suppose a customer smashes a new machine up because
    he or she 'had a play' with the machine using the low level code (if I
    wasn't meant to use this code then why did you give it to me?). The as
    the vendor what happens next; the customer will either lie - leading the
    vendor to determine whether or not to pull the customer up and charge
    them; they could tell the truth and beg/insist on not paying for the
    repair or they could pay up - which will sour the vendor/user
    relationship. Personally, I _never_ take a machine apart unless I've
    been trained to do it. I also set out the terms of what happens if I
    screw up with the vendor before I accept and they give me the control
    codes. If you open-source this stuff then you lose this control and
    people will smash your machines up - the only thing you can count on is
    people making mistakes!!

    I agree that the industry is behind but open-sourcing an industry
    will not immediately remove all the problems and issues - that's too
    simplistic a view point.

    Cheers,

    Neil

    --

    Neil Benn
    Senior Automation Engineer
    Cenix BioScience
    BioInnovations Zentrum
    Tatzberg 47
    D-01307
    Dresden
    Germany

    Tel : +49 (0)351 4173 154
    e-mail :
    Cenix Website : http://www.cenix-bioscience.com
    Neil Benn, Oct 6, 2004
    #10
  11. Just a few clarifications:

    On Wed, 06 Oct 2004 10:32:37 +0200, Neil Benn <> wrote:
    > To the money men thing - if that is your experience then the company
    > was run incorrectly - most people I speak to - a purchase decision is
    > made between the user, on -site engineer, finance and managers. Any
    > company in which the finance department purchases equipment without
    > consulting the people involved in the process is bad, bad - bad!


    For "money men", I meant non-techies looking at the bottom line, not
    only the finance department. Upper management in general -- they're
    not comfortable looking at the tech details, but they know how much
    does it cost, and how much they can save with a new control/automation
    system. It's a reasonable decision-making procedure, in economic
    terms. But it still leaves out a lot of technical-related aspects --
    that's where a good in-house engineer could make a difference.

    > >When the market finally awakes from the stone age, you'll surely start
    > >to get more calls like this. Not only from people relinking, but
    > >patches, and *real* bug tickets found by your very customers. Get used
    > >to it. You can't complain this way once the market is open.
    > >
    > >

    > Yes you can, if you open something up you will _still_ get people
    > screwing things up. Suppose a customer smashes a new machine up because
    > he or she 'had a play' with the machine using the low level code (if I
    > wasn't meant to use this code then why did you give it to me?). The as
    > the vendor what happens next; the customer will either lie - leading the
    > vendor to determine whether or not to pull the customer up and charge
    > them; they could tell the truth and beg/insist on not paying for the
    > repair or they could pay up - which will sour the vendor/user
    > relationship. Personally, I _never_ take a machine apart unless I've
    > been trained to do it. I also set out the terms of what happens if I
    > screw up with the vendor before I accept and they give me the control
    > codes. If you open-source this stuff then you lose this control and
    > people will smash your machines up - the only thing you can count on is
    > people making mistakes!!


    I meant to say that 'you can't complain that way', in the sense that,
    once open, you can't just refuse to support a customer that just broke
    up your machine. In fact, it's *never* a good idea -- but in a closed
    market, one can get away with it, while in an open market, people will
    have more freedom to look for the better *service* they can find.
    Customer service will be *more* important then than it is now.

    > I agree that the industry is behind but open-sourcing an industry
    > will not immediately remove all the problems and issues - that's too
    > simplistic a view point.


    Fully agreed. It's also interesting to remark that the LGPL, or the
    BSD licenses allow for a mixed environment with open source &
    commercial licenses, so it's not like everything will be open. There
    will be closed apps -- only that the closed apps will make use of open
    source libraries. Hopefully, even the closed apps will have open
    interfaces. That's a nice mix.

    --
    Carlos Ribeiro
    Consultoria em Projetos
    blog: http://rascunhosrotos.blogspot.com
    blog: http://pythonnotes.blogspot.com
    mail:
    mail:
    Carlos Ribeiro, Oct 6, 2004
    #11
    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,596
  2. walala
    Replies:
    3
    Views:
    738
    Allan Herriman
    Sep 9, 2003
  3. rtm
    Replies:
    0
    Views:
    799
  4. Jerry
    Replies:
    4
    Views:
    5,969
    Marina
    Dec 15, 2003
  5. Jason Kendall
    Replies:
    1
    Views:
    145
    Patrice
    Jun 1, 2005
Loading...

Share This Page