XML SCADA

F

Thread Starter

Fredrik Högberg

Hi!

I'm having some thoughts on how a open source scada system could be built. I just want to hear what you have to say about it. If you have any input i'd be glad to hear it.

I've been looking around and are really impressed with what visual and PuffinScada has accomplished but IMHO there are always some thing that makes it that i cannot consider using them as a professional scada integrator. You might ask why i don't join and help adding the missing features but i believe that starting over, using the recent technologies that are available the workload is reduced.

Here are a few things that i feel is a need for making a customer even consider a open source alternative.

- Windows client
It's a fact that windows is most common operating system.
A linux alternative is always welcome but optional.
- IO Support
The times where i as a scada engeneer is able to chose what PLCs are used is used. A customer is also very seldom willing to accept lack of device support.
- Redundancy
- Configuration Enviroment
Text or XML files are great but a system without graphical configuration possibilities will never be widely spread.

Here's what i had in mind:
A complete modular system where the modules are run as individual processes.
To make a basic scada system the following modules would be required.

DataCollection:
To read and write IO data from devices and make it available to other modules.
OPC Foundation has recently released the XML-DA Specification wich looks
promising. Implementing a client for this is as difficult as implementing a
WebService. I'm expecting this to be about as much work as implementing a single
PLC protocol.
XML-DA to traditional OPC gateways are already available and enables all possible
I/O support.

Alarm:
Input from DataCollection and client (acknowledge, blocking) and output to Logging and
client to display alarm lists.
Hopefully if this project comes to reality the OPC foundation will have released
its XML Alarm & Events specification before any actual work is being done on the
alarm server.

Logging:
Handle log requests from the whole system and returning logs to the client.
OPC is planning historian support with XML aswell.

Client:
Graphic display of data.
the w3 svg standard looks like the best option around.
A standard svg file with a xml transformation definition file to describe
transformation with IO data.
Using svg makes it possible to use a commercial editor until something better is created.

I know you're wondering, You and what army of programmers are going to do this?
Well... Time will show if i'm wrong but i'm planning right now and will soon begin creating a class library for XML-DA.
The big task will be to complete the XML-DA and XML-AE support. If this becomes stable creating a modules for alarms, logging
or a client will be one mans job and would have a resonable chance of being completed.

Right now i'm planning on going .net and c#. I'm confident that mono will provide support for the linux platform and
if so it'll be platform independant.
 
At the top, I should note that I'm involved in the MatPLC project; so my responses are from that point of view. My address is [email protected], if you'd prefer to e-mail me privately.

Fredrik Högberg:
> I've been looking around and are really impressed with what visual and
> PuffinScada has accomplished but IMHO there are always some thing that
> makes it that i cannot consider using them as a professional scada
> integrator. You might ask why i don't join and help adding the missing
> features but i believe that starting over, using the recent
> technologies that are available the workload is reduced. <

Unlikely - there's little in the way of real new technologies; even if there were, creating an interface between them and one of the existing projects would likely be much less work than starting over from scratch.

Another point is that the overall feel at the recent "Linux in Control" workshop was that consolidation of existing code is the important aspect at this stage. There are many separate projects, which don't communicate much (if they know of each other at all), but which between them would make a fairly respectable basis.

If you would contribute to this consolidation - for instance by writing "interfacing between X and Y projects" HOWTOs from the point of view of an outsider - it would probably have much greater effectiveness than simply starting yet another project.

> Here are a few things that i feel is a need for making a customer even
> consider a open source alternative.
> - Windows client
> It's a fact that windows is most common operating system.
> A linux alternative is always welcome but optional. <

At least one of the existing HMI projects has a Windows client. Some others work over the web, and are thus also accessible from Windows.

> - IO Support
> The times where i as a scada engeneer is able to chose what PLCs are
> used is used. A customer is also very seldom willing to accept lack
> of device support. <

This is largely a question of vendor support. If vendors don't release specs, there's not much one can do. Nevertheless, progress is being made as circumstances (and workloads) allow.

> - Redundancy
(Your proposal doesn't seem to address this point either.)

> - Configuration Enviroment
> Text or XML files are great but a system without graphical
> configuration possibilities will never be widely spread. <

Yes; so write a graphical configuration tool for one of the existing projects :)

> Here's what i had in mind:
> A complete modular system where the modules are run as individual
> processes. <

Already done - for instance the MatPLC is structured in this way. Others, for instance OROCOS, are structured as threads rather than processes, but the concept is similar. Very few are monolihic.

> To make a basic scada system the following modules would be required.
> DataCollection:
> To read and write IO data from devices and make it available to other
> modules. OPC Foundation has recently released the XML-DA
> Specification wich looks promising. Implementing a client for this is
> as difficult as implementing a WebService. I'm expecting this to be
> about as much work as implementing a single PLC protocol. <

Excellent! Would you be willing to write such a module for the MatPLC?

> XML-DA to traditional OPC gateways are already available and enables
> all possible I/O support. <

That'd be very good.

> Alarm:
> Input from DataCollection and client (acknowledge, blocking) and
> output to Logging and client to display alarm lists.
> Hopefully if this project comes to reality the OPC foundation will
> have released its XML Alarm & Events specification before any actual
> work is being done on the alarm server. <

Again - when the spec is released - would you be willing to contribute such an alarm module for the MatPLC? (We already have a simple logging module - MySQL - but we're lacking the fancier facilities.) I imagine, also, that it would be important to make a graphical editor for these...

> i'm planning right now and will soon begin creating a class library
> for XML-DA. The big task will be to complete the XML-DA and XML-AE
> support. If this becomes stable creating a modules for alarms, logging
> or a client will be one mans job and would have a resonable chance of
> being completed. <

Indeed, alarms, logging and client are probably better used from one of the existing projects, perhaps with the OPC features added (once the specs are released).

> Right now i'm planning on going .net and c#. I'm confident that mono
> will provide support for the linux platform and if so it'll be
> platform independant. <

Don't do that - nobody in the OSS world trusts .NET, not enough to base anything important on it, not even via mono. How they say, "quidquid id est, timeo Danaos et dona ferentes" (beware of Greeks bearing gifts).

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri
 
M

Michael Griffin

On July 30, 2003, Fredrik Högberg wrote: <clip>
> I'm having some thoughts on how a open source scada system could be built.
> I just want to hear what you have to say about it. If you have any input
> i'd be glad to hear it.
<clip>

> Here are a few things that i feel is a need for making a customer even
> consider a open source alternative.
>
> - Windows client
> It's a fact that windows is most common operating system.
> A linux alternative is always welcome but optional.
<clip>

What about making it platform independent? That sidesteps the entire OS question. This can be considered as being the "safer" choice, since no one would have to make any long term guesses or commitments on what OS to use.

> Time will show if i'm wrong but i'm planning right now and
> will soon begin creating a class library for XML-DA. The big task will be
> to complete the XML-DA and XML-AE support. If this becomes stable creating
> a modules for alarms, logging or a client will be one mans job and would
> have a resonable chance of being completed. <

I've cut out various other comments on XML, but I just wanted to comment that using XML doesn't automatically makes something open and platform independent. While I am not an expert on XML, I am quite sure of this point. XML can help to make data formats "open", but only if that was the orignal design intent and the design was very carefully done. XML is a current "buzz word" in the computing industry and many people look on it as a magic wand. However in many cases it is just used to call a proprietary (and often undocumented) API, making the data format no more open than a "secret" binary format would be.

I must state that I haven't examined the XML schemas you have referred to so I do not know if the above mentioned problem applies to them. However, I would suggest that you examine them carefully for this problem before committing too much work to this subject.

> Right now i'm planning on going .net and c#. I'm confident that mono will
> provide support for the linux platform and if so it'll be platform
> independant.
<clip>

Many people would say that your confidence in Mono is misplaced. Too much of "dot net" is tied back into the Windows API for Mono to ever be more that a small subset of it. The libraries will be a particularly sticky problem. Many people seem to feel that c# will be successful on the Windows platform (especially in rendering Visual Basic obsolete), but it's not a cross platform development system, and it probably never will be. In other words, it isn't an equivalent to Java.

If you really want a cross platform project, I think that "dot net" would be a poor choice. You will likely find yourself continuously debugging and altering code to try to make it work the same way on both "dot net" and Mono, if you can do it at all. You would also likely find yourself writing a lot of code to make up for missing library functionality in Mono.

Other people who are reading this are probably much more qualified than I am to recommend a different development language. However, if cross platform operation is a desirable goal (and I think it is), then I would suggest using a language that is intended to be platform independent, and already *is* on multiple platforms. Java and Python come to mind, but perhaps someone else more experienced in these matters could make a better suggestion.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
H

Higginbotham, Ricky

Not true (that noone in the OSS world trusts .NET). There's a lot of OSS thats available on Windows only actually, contributed by good people who either have to interface with those (win)systems or need/like the ease of use.

It is true that you (Fredrik) are unlikely to recieve any support from the MAT camp for anything involving .NET or Windows, speaking from personal experience. Its too big a project to start from scratch by oneself. Unless you are independantly wealthy and have a few years to spare, I'd concentrate on learning about the existing projects and getting what you need out of them. If you're really interested in getting things on windows and .NET, create wrappers for existing tools. If theres functionality thats missing (and we both know theres lots) work with them to add it. Since its OSS you'll have other people working with you to add functionality you both need, and it won't hurt you that the whole thing wasn't written in C#. Most of whats there now is "library code" and theres no advantage to writing that in C#. I think you'll find the people involved with those projects both very helpful and intelligent, aside from anything involving the great evil ;-). Theres enough things missing theres plenty of work to go around before you need to worry about porting to windows.

As an aside, I still don't like the idea of integrating the display with the plc core. I think they should be run on seperate systems. When my HMI dies (and it does quite often of late), I don't care too much because I know it won't take the entire plant with it. I just submit another bug report to Siemens who will put it in file 13 (wonders of legacy equipment). Too many eggs in too few baskets. Same for alarm logging, etc. Every component you add upon the core logic, introduces more risk into the system. Seperate them via your choice of comm. or distributed objects and you can have them on the same hardware for testing but seperate them for production.

Richard Higginbotham (speaking for me)
 
T

Thomas Hergenhahn

Hello,

> I've been looking around and are really >impressed with what visual and PuffinScada has >accomplished
Thank you.
>but IMHO there are always some thing that >makes...
>
> Here are a few things that i feel is a need >for making a customer even consider a open >source alternative.
>
> - Windows client
> It's a fact that windows is most common operating system.

Yes, it is. With VISUAL you have different options:
1.You can view hmi pages and trend diagrams in any browser that supports JAVA.
2. You can let VISUAL store data to a MySQL database and retrieve it with windows (office)applications via ODBC.
3. You can look at the source of hmiVisualCI.java communication interface and write yourself a windows client or a client dll.
4. You could help in developing an ODBC server for VISUAL/LINUX.

> A linux alternative is always welcome but optional.

It is my experience that LINUX is simpler to handle, needs less resources and is more reliable than windows. So it's my first choice when things need to run 360x7 hours.
If you are not convinced, have a look at what IBM found out:
http://www-1.ibm.com/linux/news/semiconductor.shtml
You may argue that people will still prefer Windows because they have knowledge and experience with it while they have none with LINUX. I suppose that many people who buy and run machinery don't have the knowledge, experience, intention or tools to change any of the comercial SCADA applications. Hence they accept what the manufacturer provided, as a part of the machine. The same could be true for a little -- maybe headless -- LINUX box in the cabinet that delivers data and HTML pages.

> - IO Support
> The times where i as a scada engeneer is able >to chose what PLCs are used is used. A customer >is also very seldom willing to accept lack of >device support.

Yes, I fully agree. But VISUAL already covers some major brands and if somebody needs support for others, I should allways be willing to help.

> - Redundancy

I have to think about that.

> - Configuration Enviroment
> Text or XML files are great but a system >without graphical configuration possibilities >will never be widely spread.

Ok. Personally, I'm quite happy when I can change a configuration in a plain text file instead of clicking menus and boxes. I tend to forget where the point of interest did hide.
As any graphical configuration tool has to store the resulting configuration somewhere, this can equally well be in a plain text file. Once the configuration file layouts have stabilized to a reasonable degree, I will think about writing such a tool. A first step in this direction is the web based hmi designer demo.

> Here's what i had in mind:
> A complete modular system where the modules >are run as individual processes.
In VISUAL it's threads. I'm currently working on a possibility to start, stop and restart them individually. I see no need for this in normal operation, but it will ease testing.
> To make a basic scada system the following modules would be required.

> DataCollection:
> To read and write IO data from devices and make it available to other modules.
This in the PLC driver modules, which are choosen in the main config file.
> OPC Foundation has recently released the XML-DA Specification wich looks
> promising. Implementing a client for this is as difficult as implementing a
> WebService. I'm expecting this to be about as much work as implementing a single
> PLC protocol.
I will have a look into these standards next days.
> Client:
> Graphic display of data.
> the w3 svg standard looks like the best option around.
It may depend on what you want to display.
> A standard svg file with a xml transformation definition file to describe
SVG file and XML definition would have to be parsed and the drawing needs to be carried out each time somebody changes a page.
IMHO, this is overkill when used just to display some numerical values or a pointer position before a fixed dial layout.
> Using svg makes it possible to use a commercial editor until something better is created.

I will have a closer look at SVG and consider it as an option.

>....
Are you planning to publish your class library as open source?

> Right now i'm planning on going .net and c#. I'm confident that mono will provide support for the linux platform and
> if so it'll be platform independant.

Let me join the chorus of those who warned you.

Regards
Thomas Hergenhahn
 
F

Fredrik Högberg

Hi!
Im going to respond to you both in a single mail, hope you don't mind. Sorry for the delay, i've been on a short vacation.

Jiri
I'm sure you have a better overveiw of the open source automation projects then what i've found with search engines and if you want to share them with me i'll be very glad.

I havn't looked in to MAT all that much but from what i've seen it's a great soft PLC project.
There's also possibilities of creating HMI interfaces but i basicly feels that this is two totally different goals.
A SCADA system is something very different from a Soft PLC.

A SCADA should be designed to handle and process large amounts of data. Historic data is the most importent aspect and networking should be native.

I don't agree with you that continuing on existing projects is better then creating a new.
Interfacing two project with different ideas and concepts could some time mean more work then creating a new.

XML-DA is just a structured way of sending data. I don't think it's the fastest but it's object oriented and "human readable".
One great feature of the spec is subscribing.
A client can download a subscription to the XML-DA server and the request updates on his subscription.
The server can be set to store any changes that occur in between client subscription requests so that the client receive a list of timestamped values on a single tag. All neatly packaged in a neat package.

OPC-Foundation has done it once and i beleave this makes it more possible they make it again.
OPC wasn't without gliches but I think we can agree it has become a quite spread standard.
I can't judge V1.0 of the spec but i'm confident that they're committed to complete it.

The most importent reason for me thinking of .net is that i have only limited knowledge of C and C++. Java is an option but i like the idea with .net and it's limited but usefull and (well) documented classes.
What is needed in classes to make the project (without graphics) work is the XML parser, some file IO, tcp/ip socket and a ADO.NET database connection.

I'm going to start some tests and will go with C# for now. This descition can be made later if the project starts to grow.

Fredrik Högberg
 
Ricky Higginbotham:
> Not true (that noone in the OSS world trusts .NET). There's a lot of
> OSS thats available on Windows only actually, contributed by good
> people who either have to interface with those (win)systems or
> need/like the ease of use.


OK; still, it's not the "mainstream" choice of OSS.

> It is true that you (Fredrik) are unlikely to recieve any support from
> the MAT camp for anything involving .NET or Windows, speaking from
> personal experience.
Admittedly, a lot of that will simply be lack of time. If you contribute a C# interface to our project, we won't complain :) However, when it comes to deciding which item on the to-do list to tackle next, most of us will probably tackle one of the other items. As you say, there's plenty of those.

> As an aside, I still don't like the idea of integrating the display
> with the plc core.
Probably best to make it flexible enough to support both options, as you suggest, so that decisions can be made on a case-by-case basis. Besides, this'll allow things like having stepladder logic behind HMI screens, in the non-machine-controlling part.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri
 
C

Curt Wuollet

Hi Ricky

I'll pass on the .NET discussion, people who can't see what's down that road deserve the consequences. Being locked in to MS for another decade or so doesn't even make sense if you love and trust them.

But on the display integration issue, I greatly prefer for it to be distributable. That is to run on whatever box you wish. Sometimes the same box makes sense and sometimes it doesn't. Across a VPN might be handy, and it's also important that the display be optional. And very low resource (ncurses for example) displays should be a firm part of the strategy as well since most GUIs are overkill for all but the most interactive applications.

Several apps and several displays on the same box has even been handy for a cell and doesn't even begin to saturate a Linux box. Especially if you aren't obssessed with mere eye candy.

Also speaking for myself

Regards
 
Michael Griffin:
> if cross platform operation is a desirable goal (and I think it is),
> then I would suggest using a language that is intended to be platform
> independent, and already *is* on multiple platforms. Java and Python
> come to mind, but perhaps someone else more experienced in these
> matters could make a better suggestion.


Python has the advantage that it generally seems to be favoured among open source folks; MatPLC has an interface, I saw a page about comedi and python, and so on. It also ties in with Zope, so you can have your factory floor tied in to your intranet web applications (carefully).

It's also a beginner-friendly language, a bit like BASIC but about three decades more modern, so it doubles as a user-scripting language.

Java would have the advantage that there's a couple of diagram editing toolkits out there that you could use; except they are not particularly mature (DiaGen, Tony Jansen's CIDER). You get the core functionality, but all the bells and whistles that make up the bulk are not included (except the one - layout assistance).

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri
 
On August 2, 2003, Fredrik Högberg wrote:
> Im going to respond to you both in a single mail, hope you don't mind.
> Sorry for the delay, i've been on a short vacation.
>
> Jiri
> I'm sure you have a better overveiw of the open source automation
> projects then what i've found with search engines and if you want to
> share them with me i'll be very glad. <

Hmm, not sure if I have much that could be imparted in a short e-mail... mostly from the recent Linux in Control workshop, and generally being in the MatPLC project for years.

> I havn't looked in to MAT all that much but from what i've seen it's a
> great soft PLC project. There's also possibilities of creating HMI
> interfaces but i basicly feels that this is two totally different
> goals. A SCADA system is something very different from a Soft PLC. <

There are nevertheless many aspects which can be common. For instance, getting data via Modbus or something is the same regardless of what one uses them for. Plus, since the Soft PLC has a screen already, it will probably always have at least a mini-SCADA on itself (even if it's headless, plugging in a monitor could be a diagnostic procedure). At that point the line between the two starts to blur.

Still, there are significant differences between the two; if preferred, the SCADA can be mostly separate, having only a small stub in the MatPLC for the purpose of exchanging data with it.

> I don't agree with you that continuing on existing projects is better
> then creating a new. Interfacing two project with different ideas and
> concepts could some time mean more work then creating a new. <

The problem with creating a new project is that then there are (n+1) existing projects with different ideas and concepts, which *still* don't talk to each other - the situation is made worse rather than better.

> XML-DA is just a structured way of sending data. I don't think it's
> the fastest but it's object oriented and "human readable". <

I think the only real concern here was whether or not there's any encumberances on the spec - XML is fine, but if you have to sign an NDA to see the DTD, it's not very open, is it...

> The most importent reason for me thinking of .net is that i have only
> limited knowledge of C and C++. Java is an option but i like the idea
> with .net and it's limited but usefull and (well) documented classes. <

That's a bad reason to choose a language :)

Taking a few months out to learn a few other languages would probably make you a better programmer, even if you end up coming back to the original language in the end.

> What is needed in classes to make the project (without graphics) work
> is the XML parser, some file IO, tcp/ip socket and a ADO.NET database
> connection. <

At which point you'll be roughly where all the other Linux in Control projects are - just on the edge of being usable, missing a GUI, but too small to attract enough developers to really take off.

Really, if you take the MatPLC for the back-end, and Rainer Lehrig's pvbrowser project for the front-end, you'll have a good start on all the features you wanted (pvbrowser already has a Windows client). Just fill in the gaps...

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
G

Göran Hasse

Well... There is languages and languages. Many general languages do specific things WERY badly. Some specific languages do general stuff terribly.

In the Unix environment there is a LOT of languages that are possible to combine and use in one and the same project.

XML is no gold solution to the SCADA problem. You need a databse - so you need an XML-converter that can do and understand transactions, triggers and journals.

You need a network protocol so you need a XML parser that can do and understand different network failure situations, setsocketoptions and other cool stuff.

You need a graphical user interface so you need an XML parser that can understand mouse movementsk, graphical objects and states.

If you are going to specify a SCADA system in XML you are
taking on a BIG job.

We have done the other thing around... We have used all
possible tools in the Unix environment, GTK, MySQL,
TCP/IP-UDP, etc and come up with http://www.freescada.com/

This is the Unix way of doing things. Stand on the shoulders of others - and just make it!

Göran Hasse
 
All:

Following this thread I understand that this SCADA system would consist of several processes (running on separate PCs). They communicate via messages, encoded in XML.

So, this would allow to have any OS, running one of the processes? So, I have a data base on a UNIX station, viewing alarms on Windows CE handheld and configure from a LINUX PC? Sounds great or did I miss anything?

Regards,
Toni
kaesbeck at netzero.com
 
L

Lynn at Alist

The main problem with XML is it is HUGE reletive to info content. Modbus/TCP can turn a motor on/off in 12 bytes of TCP data. It can read 16 IO points in that same 12 bytes.

UPNP with SOAP (the only XML comm I've formally used) requires over 1500 bytes to turn the same motor on/off. Adding 15 more points would add many more thousands of bytes. I've browsed the OPC-XML files and they don't look any smaller.

For upper corp networks, this is no problem. MES to SCADA should happily use XML. I think you are mainly planning client (user-view) to the SCADA-as-database, which should work Ok. So SCADA still could use other binary protocol to field.

But HMI displays these days tend to have hundreds of points per display/page - not the old 20-30 from DCS/VDU days. I could forsee such a system giving "web browse speed" performance that is Ok, but not what users of competing HMI are used to seeing.

- LynnL
 
F

Fredrik H&ouml;gberg

Hi!
First i would like to explain that i have nothing against Linux. In fact i love it.
I'm using it at home for a lot of things and the more i learn the more i like it.
I would love working with it profesionally some day.
I really don't know why this became a windows vs linux issue. The entire idea heavely relies on OPC as a good method of gaining acces to a large number of different protocols. I'm doubting any OPC server will be created for linux in the nearest future and this will mean that to get a site up and running there must be at least one windows computer running the OPC/XML-DA server.
Of course it would be great if MAT could be a XML-DA server so there would be no need for windows but because im just gathering information and running some tests to find out what could be done and what could not it doesn't really matter what language or platform that's used.

In what way is XML-DA a closed protocol?
The specification is available trough e-mail request (If you send it, it will come).
The WDSL is directly downloadable trough their website.
http://www.opcfoundation.org/webservices/XMLDA/1.0/

I havn't read the disclamers that carefully but i doubt they say something about actually using the documents for reference in software development.

I havn't had so much time but i can't say initial tests have discouraged me from C#.
The wdsl tool in the .NET framework created wrapper classes for the web service and in 10min i had retreived the status of the dOPX XGate made by kassi using HTTP as transport.
OPC Foundation recomends HTTP but other transports can be used if needed for performance or otherwise.
Going to try tag browsing, reading and subscription next.

SVG
To get an idea on what's possible take a look at these sites.
http://www.wpsenergy.com/JayNick/
http://www.mycgiserver.com/~amri/widget/widget.svg
A simple client could be implemented with the adobe's svg viewer. A better one with Batik in java.
It will be interesting to see how the 1.2 specification turns out from w3.

I might not have the full pictiure yet but here's an idea.
pvbrowser looked really impressing. I'm imagining the work that must have meant to make it.
SVG is a standard wich already can do most of this already. Implementing a client would mean the work to creating a DTD that could be used to create a transformation description that in conjunction with a some variabel data and some functions could create a XSL file to be applied to the SVG so that it reflects the current status of the plant.
If the XSL describes to fill a circle or move a rectangle or whatever doesn't have to be addressed, Just that the right property of the right object is changed.
To me this sounds like the simpler approach.

I where never looking for help starting up a project and i didn't expect volontears sign up. However it has been nice to hear your comments. If ever come up with something that's actually usable i'll have to decide to go OS or not but that will be a later question.

Fredrik
 
On August 9, 2003, Fredrik Högberg wrote:
> In what way is XML-DA a closed protocol?
...
> I havn't read the disclamers that carefully but i doubt they say
> something about actually using the documents for reference in software
> development. <

The corresponding license agreement is
http://www.opcfoundation.org/Downloads/LicenseAgreement.asp

The Open Source Definition is
http://www.opensource.org/docs/definition.php

I'm not a lawyer, but it seems to me that the OPC license breaks at least the following items:

- 5. No Discrimination Against Persons or Groups - by incorporating export restrictions into the license (this is a specific example in the annotations to the OSS definition).

- 6. No Discrimination Against Fields of Endeavor - by forbidding commercial sale under certain circumstances.

- 10. The License must be technology-neutral - by the requirement for an /About/ box.

That's just a quick browse, citing the obvious ones. No doubt an in-depth study would reveal others, but there seems little point while the obvious ones stand.

> I havn't had so much time but i can't say initial tests have
> discouraged me from C#. <

Check the license for C# also; I don't think it was C#, but there was some MS programming environment that forbade using it with for GPL s/w. However, you have the license handy and I don't.

> SVG <

I agree that SVG is a nice thing. It would be nice to have an open-source back-end generating it (perhaps a MatPLC module, perhaps independent).

> pvbrowser looked really impressing. I'm imagining the work that must
> have meant to make it. <

It has the advantage of being working code, too, rather than just a specification that's still to be implemented :)

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C
Hi Lynn

This pretty much mirrors my objections, along with questionable parentage and the spectre of submarine patents. It's just not that great of an idea in an automation and control context. It follows in a pattern of adopting vast amounts of bloat and cruft simply because it's what is available and prescribed by the makers of the dominant desktop, for vastly different contexts. Methods by and for A&C people would be very unlikely to be as ugly as what is in use by default or necessity to accommodate the monopoly.

An engineer wouldn't even consider those efficiencies unless compelled to by a mandated platform. It's an insane way to communicate the amounts of data required with any concern for resources and determinism. Yet, in the same breath as advocating this sort of cruft, people will argue that _Modbus_ is inefficient. What's wrong with this picture? Motes and beams?

Regards

cww
 
C
Hi Fredrik

No Offense, but: Can you really not see where total dependance on Microsoft would present a problem to an informed community? I find that rather hard to believe. Things that are totally owned and controlled by a malefactor aren't very wise choices for an Open anything, and that should be obvious. It's not about any other particular platform, it's about working with anything but Windows. Open is about choice. What you propose is Anti-Open by the choice of closed platform tools and methods. You can't have it both ways. MS won't let you. Even if .NET and C# become available on other platforms they still won't be Open. They are designed and intended as closed alternatives to Open technologies. Otherwise MS would simply use the more established and "open" Java, etc.

Regards

cww
 
M
Fredrik Högberg,

I don't think that this is too ambitious of a project at all. I have already written a C# program which does some of what you mentioned:

1. Polls various motion controllers for status information using manufacturer supplied communication drivers. (This forced me to use Windows as an OS because most manufacturers only provide windows communication drivers.)

2. Stores this information in a database so that other programs can access it using descriptive names. For now, the database is just a local array. You could store it in a commercial database if you want more universal access to it.

3. Displays a GUI with a small (15 or different types) set of control objects. Just your standard stuff here, graphics, buttons, sliders, graphs, etc.

I also wrote an editor that lets users set up the database and GUI graphically.

If you want to use some of my code to get up and running, you are welcome to it. I am using this project to learn C# (I usually program in C++) and wouldn't mind sharing ideas with someone.

Currently my GUI and polling program are part of the same C# project. You could easily separate the two into different modules. The GUI module could then communicate with the database remotely. (I have been experimenting with .NET, and this looks to be pretty simple. The difficult part is choosing a communication protocol.)

If you are concerned about being tied to Microsoft, you could write any of the modules except the communication module to run on Linux machines. Unfortunately, I would not be much help when it comes to programming Linux code.

E-mail me if you have any questions, and good luck with your project.

Matthew Dean
Perry Automation
[email protected]
 
Top