Neil said:
Just out of interest - which tecan robot were you interfacing
to - every Tecan robot that I've ever programmed comes with a high level
API (Toolbox, Gemini, Logic, WinWash, Magellen).
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.
I would think however
that controlling a tecan robot in the environment that it is typically
being used in (life sciences R+D) is not industrial control (its my job
BTW!). It's not like making milk....
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).
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.
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.
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...
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.
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.
Not using good testing procedures would be a real sign of carelessness
or sheer incompetence. I hope no one would subcontract for industrial
control software with anyone who would actually produce software of
the sort you describe above. Of course, I recommend and use test-driven
development for my code, and don't suffer from the problems you
describe. And did I mention that the software worked flawlessly the
first time it ran, and has had no bug reports in the month or two
of use it has seen since then? ;-)
Note also that these problems have nothing to do with Python,
and everything to do with poor programming practices.
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...
The serial module is good but I
think that a model of input and output streams with listeners/observers
would make far more sense, currently I have to make a polling loop to
receive the data,
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).
Good to see that you didn't use ActiveX (if one more company _boasts_
that their equipment comes with 'industry standard' ActiveX I think I'm
going to cry)!! Believe it or not I still have to interact with some
equipment using DDE!!!!
Actually, we *did* use ActiveX, unfortunately, because that's what
the customer wanted to use to interface LabVIEW to the driver. It
does work, and works reliably, but in the end it's the use of
LabVIEW for this stuff to which I object more strongly than I
object to the use of ActiveX. (Without LabVIEW in the picture,
however, ActiveX would also have been unnecessary, as we would
have gone pure-Python.)
-Peter