Re: [Qscada-developers] the XML-DA protocol

[Jovan K. <cho...@gm...>]

Hi All,

On 11/15/06, Ivan Vavrecka <iva...@ya...> wrote:
> I am a new suscriber, not a programmer, just looking
> for some general knowledge about these topics.

It's nice to have you here. It doesn't metter if you're programmer
or not, we need some people to remind us of some similar
useful projects and promote usage of QScada as well. ;)

> ...PyOPC is a framework for rapidly creating OPC
> XML-DA compliant clients and servers....A Python
> Framework for the OPC XML-DA 1.0 Standard...

I've just read the docs for PyOPC, seems fine to me, but
i don't know if we should introduce another programming
language in our project. I think it would be better if we are
using one programming language and avoid forcing heterogeneous
system (I'm thinking of prog. langs).

On the other hand our project will depend on another which
can be bad sometimes. What will happen if the PyOPC project
is not upgraded in time when new OPC specification is published?
We'll have to do it our own, so someone of us will have to work on
PyOPC as well.

The third thing is the python programming language it self, its nature.
It is a script language, and it takes longer time to execute
(through the python iterpreter). Because of that, we can experience
some delays in message sending/receiving which can cause some
problems in responese times and if we are dealing with processes whose
process paremeters (measurements, alarms...) change very fast and
fast response from the SCADA operator is needed.

In real life SCADA systems where the SCADA center and the remote
plant are on different locations connected with some kind of network,
wired or wireless (radio, wifi) there are delays because of the communication.
Think of a radio link in bad weather conditions... Delays will varay and
we will only know some maxiumum delay that is the limitb of what we call good
communocation. We must not introduce some not necessary extra delays
because of the
structure of the system and the nature of script programming languages.

But these things doesn't stop us to use some good ideas from PyOPC.

I've written one seminar paper on OPC when I was at college, about 15 pages.
I'll translate it to english and send it here so we can all be familiar with the
concepts used in OPC.
The unpatient can check:
http://www.opcfoundation.org  - the organization that takes care of
OPC standards
http://www.matrikon.com - company that has many examples of OPC
clients/servers mostly for M$ windowz
http://www.opcconnect.com/ - links to OPC software solutions

We are planning to use XML-RPC for  QScada so it will probably be implementation
of OPC-XDA to conform the trends and standars in authomation control.


> I also found full compabillity of qt designer with
> phyton.

Yes I know, pyQT library. I've never used it though.

"PyQt is a set of Python bindings for Trolltech's Qt
application framework and runs on all platforms supported
by Qt including Windows, MacOS/X and Linux.
There are two sets of bindings: PyQt v4 supports Qt v4;
and the older PyQt v3 supports Qt v3 and earlier. The bindings
are implemented as a set of Python modules and contain over
300 classes and nearly 6,000 functions and methods."

Copy/Paste from http://www.riverbankcomputing.co.uk/pyqt/
the developers of PyQT.

Bindings means more delays :(
We can use python for some parts of QScada that are not
time critical, but for the OPC servers/clients I think that's
bad idea.

As I saw in these two tutorials:
http://www.cs.usfca.edu/~afedosov/qttut/
http://www-128.ibm.com/developerworks/linux/library/l-qt/

PyQt is used to connect a python script to a Qt GUI.

So once again I'm against using python in QScada,
but the majority desides :)


> Qscada is a new encouraging project that will sure
> help a lot.

We hope it will. Spread the news and find more
people to join us ;)

GREETZ, Jovan