«

Hello,

Comments beneath :

Peter L Hansen <> wrote in message
news:<AcadnZxtQPvH9cDcRVn->...
<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 wrote:
> Peter L Hansen <> wrote in message
> news:<AcadnZxtQPvH9cDcRVn->...
> <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.

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 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

In article <opmdnfljLrvGPf3cRVn->,
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.

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

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:

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

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 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