Graphics Question

> Displaying a scrolling strip chart doesn't require efficient animated graphics. Your points are quite valid, but my own point was that a scrolling strip chart isn't very demanding. I do the same thing by the way in a web browser using SVG and Javascript, and CPU usage is also very low. <

OK ... I did a test on a LINUX machine. When you scroll more smoothly the CPU load is much higher ... but not so dramatically :)

> You said that "Ethernet Powerlink, EtherCAT, Modbus-TCP and EthernetIP are available by open source projects"

> Modbus-TCP is, without question open. With EtherCAT the specs were initially open, <

The specs of the standard IEC 61784 are open and will never be closed.

"EtherCAT" is a proprietary name of a product based on the fieldbus standard IEC 61784-2. You can't use the name "EtherCAT" without the permission of its owner ... IMHO, that's normal.

> but then the EtherCAT people changed their minds when and sent their lawyers after a university in either Belgium or The Netherlands (I forget which) and force them to close down their open source EtherCAT project. The EtherCAT people were demanding registration, licensing and certification (which the university wasn't willing to to pay). If that has changed back once again, then I would appreciate hearing about any information you might have on it. <

No, no this are simply fairy tales ... you can always use the source of this project without registration and certification:

http://www.etherlab.org/en/ethercat/index.php

But don't use the name "EtherCAT" !!

> For Ethernet Powerlink, I wouldn't mind any up to date information. <

Here are the links:

http://sourceforge.net/projects/openpowerlink
opensource Powerlink stack for LINUX, Windows und FPGAs

http://sourceforge.net/projects/openconf
open source configuration program for Powerlink

It's completely open !

---- snip ----
> If you know of a version of EthernetIP that is available under genuinely open terms, I would be very interested in hearing about it. <

Here is the link to the Ethernet/IP sources:

http://sourceforge.net/projects/opener (partial implemention) ... but the "openness" of that licensing is indeed very strange :)

Best Regards,
Armin Steinhoff
 
C
Hi Michael

> I don't mind making the explanation and I imagine that other people are interested as well. Go ahead and ask questions, this is a subject that I like to talk about. <

Yes, I kinda sensed that you are a pythonista.

> but a lot of the people who contact me directly about actual applications they are working on seem to deploy on Debian. <

My guess was pretty good then. I am using a fairly old version, Fedora 10, this is my "stable" machine and it wiil probably stay with F10 until I have good reason to change. I will see if they have back ported the newer Python. If a yum update doesn't do it. I'll probably upgrade another machine to F12 and move programming efforts to it. Or, I suppose I can see if I have the deps and compile from source.

> The deque was something that I added in the last version to save a couple of lines. You just have to go back to the method shown in the previous ones to fix the problem:

---- snip ---

> Most editors understand Python syntax and will highlight and auto-indent (or whatever they do) for it, but you may have to enable that feature if it's turned off.

> Here it is with the changes. I will include a line by line explanation just after the listing. <

Yes, the style enforcement seems a bit strange and it conflicts with my ingrained editing methods like searching for braces to jump around, but I'll eventually get used to it. I even considered learning a new IDE or editor, but OO is enough change for now. And some do bad things when you do VI commands out of habit.

That's it for tonight, the sun will be coming up soon.

Regards,
cww
 
I find GTK with Mono to be a very good tool for graphics and you can get going fast. I wouldn't mess with direct framebuffer stuff since X windows is well supported. C# is a good transition from C language as they have maintained a lot of the same syntax. A lot of the GTK libraries make more sense when the language supports OOP IMHO, the only trouble is that a lot of the documentations is thin for the more obscure GTK calls so you end up looking at the C API documentation and trying to figure out what the method name is that corresponds to the C function, etc.

KEJR
 
Fedora 13 came out at the beginning of last week. If you (or the user) prefer a Red Hat style distro for deployment but don't like Fedora's rapid turn over, then Centos is probably a good choice. However, that's an "enterprise" server distro, so you're back to dealing with older versions again. I had someone contact me recently about wanting a change to allow Python 2.4 support for Centos (in that case it's just a matter of porting some date calculation code over).

As for Python versions, the language is in transition between the 2.x series and the 3.x series. The 3.x series gets rid of a number of deprecated features (there is a systematic development and deprecation cycle), rearranges some libraries, and makes a few changes which are not completely backwards compatible (e.g. strings are unicode by default now). However, the majority of people are still using the 2.x series because existing releases of "stable" enterprise distros are still using older versions, and also not all third party libraries have been ported yet. Newer distros are starting to package parallel installs of 3.x, so the 3.x transition will probably start to pick up steam now. Version 2.6 (and the upcoming 2.7) is designed as a "bridge", and 2.x support will continue for as long as there is demand for it.

There are multiple implementations of the Python language (at least half a dozen that I know of), including several from major software companies. The long and the short of this however is to stick with what is shipped with your distro, or what whatever default version is shipped with the platform you intend to deploy on.

As for vi, I believe that has a Python syntax template (or extension, or whatever - I don't happen to use vi). Most programming editors do. Very few people use IDEs or special editors with Python however. Most debugging is done via tracebacks (the error message you posted earlier) or just inserting print statements. There is a debugger, but there is seldom need to use it. I find debugging with print statements quite satisfactory, because I can very easily insert some some conditional code to provide more useful debugging information. Doing that with a conventional debugger (any debugger) usually involves jumping through a few hoops.

Turn around time on a edit-test cycle is instantaneous, so the work process with Python tends to be different from that used with many other languages. You work incrementally by writing a small amount of code, testing it, adding some more, testing it, etc. If there is something you aren't sure of, you can check it interactively in a console window. The result of that is you don't often get into a situation where you need long in-depth debugging sessions. If there is a problem, it's usually something you've done in the past few minutes.

You do need to learn to read trace-backs (error messages) however. They give you the module name and line number where the error was which gives you a good starting point for finding the root cause. That's just a matter of experience however.
 
In reply to Armin Steinhoff: Thanks for the links. I just had a look at these, and the terms for Powerlink look quite reasonable.

As for Ethercat, the problem wasn't "fairy tales", I was referring to an announcement in an actual press release a couple of years ago. I think it was the University of Leuven (but I'm not 100% sure it was them). I can't find that original press release (I had no reason to keep it), but I just did a search and found a statement from an organisation affiliated with them which alludes to a compromise having been reached with Beckhoff which allows the code to be publicly released again.

"The concerns that open source projects might dilute conformance with the standard were met by careful additions to the GNU public license: code developed in this project has to remain compatible with the EtherCAT specs and a valid EtherCAT implementation.”

I didn't see these terms in the actual source code release package however, so the status is a bit unclear. Their web site states:

"The license above concerns the source code only. Using the EtherCAT technology and brand is only permitted in compliance with the industrial property and similar rights of Beckhoff Automation GmbH."

The trademark policy is quite reasonable and not unusual. The bit about "using the ... technology ... in compliance with the industrial property and similar rights of Beckhoff Automation GmbH" would have me a bit concerned however. That seems to imply that Beckhoff could claim a license is required to use their "technology" (this is a vague term that many proprietary software companies use in their license contracts - an ODVA contract uses similar wording).

If I was going to use that software, I would want that cleared up. I don't have access to any EtherCAT hardware at this time however, so it isn't something I could pursue at the moment anyway.

As for the EthernetIP software, the license states:

"the software does not, by itself, convey any right to make, have made, use, import, offer to sell, sell, lease, market, or otherwise distribute or dispose of any products that implement this software, which products might be covered by valid patents or copyrights of ODVA, Inc., its members or other licensors"

That is a proprietary software license. Nothing has changed with Ethernet/IP. Being able to get source code does not by itself make something "open source".

On a related topic, I was contacted recently by someone who is working on a DBus interface for industrial protocols (DBus is an interprocess communications bus for Linux and other unix-like operating systems). His objective is to provide an open means of interfacing protocol drivers to any software that wants to use them. It is somewhat analogous to OPC, but it is intended to be completely open and to be a bit more focused on protocols and have less of the "everything plus the kitchen sink" approach that OPC has turned into.

He is in the early development stages now, and working on a proof of concept demonstration. He contacted me to see if I would be interested in adding support for it in my software (which I will, if it works as planned).

If you are interested, I could tell you how to contact him. He's in Switzerland, and works in the process control field.
 
C

curt wuollet

Yes, there are many paths to do GUIs, these days. and I was looking at Glade and the Gnome side of things and the Qt stuff as well, as I kinda like KDE. I don't need Mono as running Windows stuff is pretty close to zero priority and I have no exposure to .NETness. Nor, do I want any. As I look at it, Python transcends the "whose GUI" and aims at any. I can write for any Linux desktop. I'm sure there are some things I need to do that won't be served by an interpreted scripting language, but I've been fairly impressed by way this high level language is put together as far as code reuse, as the critical bits of the libraries seem to be well crafted and I'm not sure I could do better working at a lower level. And it seems well suited for small one off projects. A a great way for a non-gui programmer to add the almost requisite GUI these days without burning a lot of hours. And the whole OO thing makes a lot more sense in this context.

Regards,
cww
 
C

curt wuollet

Please keep us informed on the DBus thing. Linux for Automation really needs something like that.

Regards,
cww
 
> "The concerns that open source projects might dilute conformance with the standard were met by careful additions to the GNU public license: code developed in this project has to remain compatible with the EtherCAT specs and a valid EtherCAT implementation." <

Again ... this is only the case if you want to use the proprietary name "EtherCAT" . You can always do an implementation based on the IEC standard ... and call it EtherRing or something else. Sources are available at:

http://developer.berlios.de/projects/ethercatmaster ( have problems to reach the homepage of this project)

http://developer.berlios.de/projects/soem

> I didn't see these terms in the actual source code release package however, so the status is a bit unclear. Their web site states:

> "The license above concerns the source code only. Using the EtherCAT technology and brand is only permitted in compliance with the industrial property and similar rights of Beckhoff Automation GmbH."

> The trademark policy is quite reasonable and not unusual. The bit about "using the ... technology ... in compliance with the industrial property and similar rights of Beckhoff Automation GmbH" would have me a bit concerned however. That seems to imply that Beckhoff could claim a license is required to use their "technology" (this is a vague term that many proprietary software companies use in their license contracts - an ODVA contract uses similar wording).

> If I was going to use that software, I would want that cleared up. I don't have access to any EtherCAT hardware at this time however, so it isn't something I could pursue at the moment anyway. <

To buy a Realtek 8169 based Ethernet board should not be a big issue ...

> On a related topic, I was contacted recently by someone who is working on a DBus interface for industrial protocols (DBus is an interprocess communications bus for Linux and other unix-like operating systems). His objective is to provide an open means of interfacing protocol drivers to any software that wants to use them. It is somewhat analogous to OPC, but it is intended to be completely open and to be a bit more focused on protocols and have less of the "everything plus the kitchen sink" approach that OPC has turned into. <

Are you aware about an open implementation of OPC for Python ? ->
http://openopc.sourceforge.net/

> He is in the early development stages now, and working on a proof of concept demonstration. He contacted me to see if I would be interested in adding support for it in my software (which I will, if it works as planned).

> If you are interested, I could tell you how to contact him. He's in Switzerland, and works in the process control field. <

There is a lot of infos about DBus on the net:
http://freedesktop.org/wiki/Software/dbus
AFAIK ... DBUs was initiated by the KDE project.

Best Regards,
Armin Steinhoff
 
Curt,

Mono is just like Java or python in a lot of ways.. It's a language that has a runtime component that happens to run on multiple OS's. It was crafted by some really smart people at Microsoft, and is embraced by a lot of folks in the open source community because of the mono effort.

Like I said before, I happen to like it because I know C well and the syntax is nearly identical. The aspects of it that are Object oriented are very easy to understand (much more than C++ in my opinion). So whether you like Microsoft or .NET isn't really a big deal because Mono is an open source project. I guess what I'm saying is that I would not dismiss the power and simplicity of the C# language because of the Microsoft component because you can take it or leave it.

KEJR
 
In reply to Armin Steinhoff:

>To buy a Realtek 8169 based Ethernet
>board should not be a big issue ...

The issue would be buying a selection of field I/O to test with. The software that I've seen just gives you a client (master) only. I don't have anything against EtherCAT itself, I just don't have any particular incentive to put the resources into pursuing it further at this time.

>Are you aware about an open implementation of OPC for Python ? ->
>http://openopc.sourceforge.net/

I'm aware of that, but it's just a client binding for OPC. I have a program called HMIServer (web based HMI) which I modified last year to make it easier for a user to use OpenOPC with it. It doesn't replace the OPC server; you still need one of those. The "multi-platform support" they talk about just means that you can proxy to an OPC server from another computer by using Pyro's RPC instead of DCOM.

>AFAIK ... DBUs was initiated by the KDE project.

As a trivial point, KDE used DCop. DBus was developed mainly by Red Hat who did copy a lot of ideas from DCop. DBus was then adopted by Gnome, and I believe that KDE then adopted it at some point in version 4. It's now considered to be a common infrastructure project and is also being ported to other platforms.

Here's the web page where the the guy is working the specs for what he is called "DBus for process control" (DBPC). According to what I have heard from him, he has done some tests and is working on some proof of concept code to test how well the idea will work.

http://freedesktop.org/wiki/Specifications/DBPC

I don't see a contact link there, but if anyone wants to get a hold of him I have his e-mail address (I can't post it here however, for obvious reasons).
 
In reply to Ken E:

Mono is a clone of MS Dotnet. It's not in itself a language however. It's a VM (a cross between an interpreter and a compiler), runtime, and set of libraries. The main language used with both Mono and Dotnet is C#. DotNet belongs to Microsoft, while Mono belongs to Novell. I'll try to keep the rest of this brief, but here's the history of it in a nutshell.

In the 1990s Microsoft licensed Java from Sun because they liked what they saw in it. They then added features to integrate their version more tightly into their own OS instead of using the portable libraries (they liked Java, but they didn't like the idea of portable applications). Sun eventually sued them over license violations and that business relationship came to an end.

Microsoft then hired a designer from Borland to design a language and system for them that was similar to Java, but with enough differences to avoid ending up in court with Sun again. The result was C# and Dotnet.

Someone from a small company called Ximian then in turn cloned C# and Dotnet. Ximian were bought by Novell (who wanted their server management software). Some of the Ximian management stayed with Novell and they managed to persuade them to continue development of Mono.

Mono hasn't been a big success. They've had some interest from people doing games development for games consoles (their licensing terms are much more reasonable than Microsoft's). The anticipated market for the use of C# on Unix and Linux servers never materialized however, because because C# and Mono didn't offer anything to those developers that they didn't already have from better established and more widely accepted development tools. Sun became more reasonable about outside participation in Java development and it came to look like Ximian (and Novell) had backed the wrong horse.

Dotnet was never designed to be cross platform. Mono on the other hand is portable, but that is only because it has additional platform independent libraries that Dotnet doesn't. A non-trivial C# (or VB) program written for Dotnet usually requires at least some re-writing to port it to Mono (this is according to Novell's customer statistics).

If you wrote a program specifically for Mono with their portable libraries and then used Mono on all your target platforms (Linux, MS Windows, Mac OS/X), you might have a portable program. You could get the same result with C++ and Qt however,

If you want to use C# and Mono because you already know the language, that's fine, go ahead. If you happen to like it, that's fine too. However, you should understand that outside of the MS Windows development world there just isn't much interest in it. Existing applications aren't going to get rewritten, while new ones tend to use more recently developed languages.
 
C

curt wuollet

Given their consistent history of embrace, extend, and destroy, I'm too old to invest time in any technology they have any measurable degree of control over. If they were really interested at all in open anything they would adopt existing languages and protocols instead of shunning anything "not invented here". Indeed, I'm pretty sure that's what the whole .NET thing is about, derailing Java and other popular modern languages that are cross platform. That's not to say it isn't good stuff, especially from their point of view. I don't know because the further away from their stuff I stay the easier things become. Witness what they've done to pervert ODF.

Regards,
cww
 
C

curt wuollet

Hi Michael, all

Trimmed for brevity

Ok

Here's how I hacked up Michael's elegant code to work like a chart recorder. With the loops, I couldn't get scrolling to work, specifically saving and deleting the last set of vertical grid lines so the grid scrolls with the lines when you hit the end. Please be kind as I just started doing this and I'm sure I violated some of the feel and intent of Python. But it runs and except that I seem to recall physical CRs moving the paper the other way, it looks right. Now I need to add times that move with the grid and I'm sure there is a more efficient way to do the grid. Especially if I want to add ticks on the grid.<pre>
***************************************************

# simple example that draws a scrolling line graph.
import Tkinter
import random

# We create a class to make it easier to keep static data between calls.
class Graph:

def __init__(self):
# Initialise the first Y point.
self._YPoints = [451]
self.offset = 50
# The X points are all pre-defined.
self._XPoints = range(40, 490, 1)
# Draw the axes.
canvas.create_line(40, 225, 490, 225, fill='blue', width=2)
canvas.create_line(40, 10, 40, 225, fill='blue', width=2)
# Label the axes.
#for x in range(40, 490, 50):
# canvas.create_text(x, 235, text=(x - 40))
for y in range(10, 225, 25):
canvas.create_text(15, y, text=(225 - y))
# Draw the grid.
# I'm doing all this stuff up here so that I can
# pass the lines to delete them when scrolling
self._Vertline1 = canvas.create_line(90, 10,90 , 225, fill='green', width=1)
self._Vertline2 = canvas.create_line(140, 10,140 , 225, fill='green', width=1)
self._Vertline3 = canvas.create_line(190, 10,190 , 225, fill='green', width=1)
self._Vertline4 = canvas.create_line(240, 10,240 , 225, fill='green', width=1)
self._Vertline5 = canvas.create_line(290, 10,290 , 225, fill='green', width=1)
self._Vertline6 = canvas.create_line(340, 10,340 , 225, fill='green', width=1)
self._Vertline7 = canvas.create_line(390, 10,390 , 225, fill='green', width=1)
self._Vertline8 = canvas.create_line(440, 10,440 , 225, fill='green', width=1)
self._Vertline9 = canvas.create_line(490, 10,490 , 225, fill='green', width=1)

for y in range(10, 225, 25):
canvas.create_line(40, y, 490, y, fill='grey', width=1)

# We draw a small line to initialise the line delete operation
# so we don't have to check each time if a line is already there.
self._PrevLine = canvas.create_line(0,0,0,0)

def UpdateGraph(self):
# Create a new Y point.
self._YPoints.append(random.uniform(50, 200))
# Shift the Y buffer left one it is full.
if len(self._YPoints) > 450:
self._YPoints.pop(0)
self.offset -=1
# This bit of magic combines the X and Y points in one list.
GraphPoints = list(sum(zip(self._XPoints, self._YPoints), ()))
canvas.delete(self._Vertline1)
self._Vertline1 = canvas.create_line(self.offset+40, 10,self.offset+40 , 225,
fill='green', width=1)
canvas.delete(self._Vertline2)
self._Vertline2 = canvas.create_line(self.offset+90,
10,self.offset+90 , 225, fill='green', width=1)
canvas.delete(self._Vertline3)
self._Vertline3 = canvas.create_line(self.offset+140,
10,self.offset+140 , 225, fill='green', width=1)
canvas.delete(self._Vertline4)
self._Vertline4 = canvas.create_line(self.offset+190,
10,self.offset+190 , 225, fill='green', width=1)
canvas.delete(self._Vertline5)
self._Vertline5 = canvas.create_line(self.offset+240,
10,self.offset+240 , 225, fill='green', width=1)
canvas.delete(self._Vertline6)
self._Vertline6 = canvas.create_line(self.offset+290,
10,self.offset+290 , 225, fill='green', width=1)
canvas.delete(self._Vertline7)
self._Vertline7 = canvas.create_line(self.offset+340,
10,self.offset+340 , 225, fill='green', width=1)
canvas.delete(self._Vertline8)
self._Vertline8 = canvas.create_line(self.offset+390,
10,self.offset+390 , 225, fill='green', width=1)
canvas.delete(self._Vertline9)
self._Vertline9 = canvas.create_line(self.offset+440,
10,self.offset+440 , 225, fill='green', width=1)


if self.offset == 0:
self.offset = 50
# Delete the previous line.
canvas.delete(self._PrevLine)
# Draw a new line.
self._PrevLine = canvas.create_line(GraphPoints, fill='red', width=2)
# Call the update function again later.
root.after(25, self.UpdateGraph)


# This creates the window.
root = Tkinter.Tk()
root.title('A simple graph.')

# This creates the "canvas" object to draw on.
canvas = Tkinter.Canvas(root, width=550, height=250, bg = 'white')
canvas.pack()

# This makes a "quit" button.
Tkinter.Button(root, text='Quit', command=root.quit).pack()

# This creates the graph object.
SimpleGraph = Graph()

# Start the graph running.
SimpleGraph.UpdateGraph()


# This is the main event loop.
root.mainloop()

***********************************************</pre>
Still a fairly small program.

Regards
cww
 
[clip ...]

> I'm aware of that, but it's just a client binding for OPC. I have a program called HMIServer (web based HMI) which I modified last year to make it easier for a user to use OpenOPC with it. It doesn't replace the OPC server; you still need one of those. The "multi-platform support" they talk about just means that you can proxy to an OPC server from another computer by using Pyro's RPC instead of DCOM. <

I found at OpenOPC the link to an OPC XML-DA based implementation: http://pyopc.sourceforge.net

Any comment about that project?

Armin Steinhoff
 
M. Griffin, Curt,

I understand your apprehension about C# from a standpoint of the Free Software. I do appreciate the comment as I did some web research and I was unaware of all of the "potential" threats from Microsoft. It seems the FSF has gone back and forth on Mono regarding its "Free" status, but lately it seems that as long as you are using the core language constructs as defined in the language standard you are OK. One of the gray areas is with ASP.net, ADO.net, and windows forms, which are Microsoft provided extensions to the language spec. I personally don't use any of those (I use GTK because I like it and it is well supported on multiple platforms). Seriously now, who would use ASP.net on linux? Windows Forms is probably a lot more of a gray area, but I would hope developers of open source software would use GTK and not windows forms.

For my machine projects I can compile a simple HMI, test it on windows, FTP the same binary to the target Linux box and it just runs (Provided Mono is installed on the linux box and either .NET or mono on the windows box). Granted, the same can most likely be done with Python and/or Java. One of the reasons I initially looked into C# is that Delta Tau is recommending to use Mono for the HMI development on their new Power PMAC motion controller(it is not limited to this, of course, as it is debian linux with Xenomai). I think they figure most people will be comfortable with using Visual Studio and can easily build an HMI, but you can use Mono and a Makefile just as well (we may go this way so as not to chase releases of Visual Studio...). I had looked into Python, but to learn a new language/syntax and switch from C programming to Python programming for the HMI inside one project didn't make for a seamless environment (We need to program in C for non HMI parts of the controller due to the RTOS). C# is a lot closer to C if you don't heavily get into OOP aspects of C#, which for HMI scripting and placing buttons it isn't that necessary. It makes a big difference going back and forth from one file to another and not having to worry if you need a semicolon or not.

One of the things I like about C# is that the syntax doesn't try to be "simpler" than traditional C language syntax by adding vague keywords. I am forever annoyed with the BASIC and Pascal type syntax that tries to make things easier for people who can't program in C. I program in a lot of "automation" languages related to proprietary controllers and hardware (Motion controllers, robot controllers, etc). It seems each one has its own syntax and I am constantly cursing them for not using C syntax since they all seem to use one of five different types of BASIC syntax. One such example is the if statement. I constantly need to check the code to see if I'm supposed to use endif, end_if, and in one case "fi" (old Compumotor project I had to deal with). The same can be said for Select-case, while, etc. Some languages don't support "elseif" at all, which is annoying. I also curse IEC structured text because its syntax is ugly and arbitrarily different. So to see that C# is very similar to C and cut out the unnecessary crap of C++ (but left most of the power) was enlightening. Admittedly Python and Java might be similar in this regard, except they chose radically different syntax (Python more so than Java). I would never use C# for anything needing to reside close to hardware, or for RTOS, obviously, but for GUI style programs it is appropriate.

Bottom line, use C++, C#, Java, Python, or C, but for the love of all things good use a modern graphical abstraction layer such as GTK, or KDE.

~KEJR

In that sense it makes sense to me, as a language.
 
C

curt wuollet

I think C and Python will cover my needs unless I end up back in IT. Python for adding graphics to say, machine vision apps and C for controls and working with hardware. Up until this point I have done OK using the bounty of Linux apps to do my display work using pipes, etc. I don't really want to be a heads down application programmer. And the whole web space thing just doesn't appeal to me. Since most of the jobs posted want Windows or web skills, I'm probably not going back into IT. But, I do need a paying job soon. I'm using the time to do things that would be hard if I was working. Like learning Python.

Regards,
cww
 
In reply to Ken E: Just to be clear on this, I said if you want to use Mono, go right ahead, I don't have a problem with that. I was just correcting the bit where you said Mono came from Microsoft. Mono and Dotnet are two different things from two different companies. We're just debating minor points here.

As for what the FSF has said about Mono, they've been very clear and consistent on it. They've said that it's Free Software and they think it's a good idea that it exists so that people like you can use it for your applications.

They have also said however that they don't think it should be used for key infrastructure systems in Linux because of the uncertain legality of some of the components. The ECMA spec covered only the core language and libraries whereas much of the useful functionality is in libraries and features which were not covered. Furthermore, the patent license from Microsoft was written in a way which allows it to be withdrawn at a future date. Getting the language spec rubber stamped by ECMA was intended as a PR gesture by Microsoft. I don't think they expected anyone to actually make use of it.

As for your question "seriously now, who would use ASP.net on linux?" I think you've unwittingly hit the nail right on the head with that statement. Novell's (Ximian's) business plan for Mono was based on persuading Microsoft's customers to switch from MS Windows Server with IIS, ASP Dotnet, and MS SQL Server to Novell ELS, Apache, Mono, and Postgres or MySQL. The same goes for Winforms in conventional clients.

The target market was vertical applications (hotel, restaurant management, retail POS, etc.). Novell would offer software vendors lower costs on support contracts and greater security and reliability, better remote management, etc., and the software vendors would get the products into customer sites. Is anyone doing this? Well, Novell has a list of customers (software vendors) who ported their products over and are selling them to their customers. Do they have enough to make a financial success of it? That's a good question. What is clear is that if it really does become successful Microsoft will be very unhappy about the effect it has on their bottom line and will likely be looking for ways to do something about it.

I looked into Mono in detail a couple of years ago when I was deciding what to use in a software project. I looked at library support, documentation, packaging and distribution, cross platform capabilities, "community" support (how easily can I find an answer in Google), and various other factors. I compared a lot of different languages, and what I ended up with was Python.

A few months ago you were discussing with us what you should use in your application. At the time I believe I said that your vendor's (Delta Tau) support for Mono in their product was an argument in favour of using it there. I would still make that recommendation today.

However, for what Curt Wuollet is trying to do, I think that Python is a better choice. You can both be right and make different decisions.

As for language syntax, I really don't get too excited about it. I can use C, Python, and Javascript all together on the same day and they're all fine when used for the right things. I'm more concerned about getting practical results.
 
Armin Steinhoff:

> I found at OpenOPC the link to an OPC XML-DA based implementation:
> http://pyopc.sourceforge.net

>Any comment about that project? <

It's a toolkit for building OPC XML-DA servers or clients. I don't know how well it works, as I've never used it. It uses the Twisted communications framework (which I also use), the Zolera SOAP libraries, and some additional code of its own.

You could use it to write a client interface to access an OPC XML-DA server. You could also write your own OPC XML-DA server. Again though, I don't know how well it actually works. It had one release several years ago. If I recall correctly, I believe it was a project by a university student who wrote it as part of his studies.

There's not much to say about it beyond that. So far as I know, there aren't a lot OPC XML-DA servers or clients around, so I'm not sure how useful it would be.

The difference between OpenOPC and PyOPC is that OpenOPC provides a client interface (and an optional proxy) to the more common DCOM based OPC, while PyOPC works with the less common OPC XML-DA and also lets you write servers as well as clients. OPC XML-DA is however if anything slower than the regular DCOM based OPC, so it's probably not a solution for general IO applications.

If I was going to use PyOPC for anything, I would be prepared to spend some time testing and debugging it to make sure it worked acceptably with the specific end point it needed to connect to. That's not a comment on the author of PyOPC. It has to do with the use of SOAP in OPC. I've worked with SOAP in the past (including the Zolera libraries), and cross vendor compatibility with it was very poor. The SOAP protocol is very verbose and poorly specified, so when something doesn't work it's hard to say where the problem is.

I don't know if that answered your questions on this. If not, I would be happy to say more.
 
Here it is with the grid shifting to the left. For the items that I want to shift, I gave them a 'tag'. I can then use canvas.move to move all the items with that tag by a specified x and y amount.

For the vertical lines, I move them one to the left until they have moved one full grid increment. At that point, I move them back to the right and start over again. The same thing happens with the text, except I delete the text and re-label it.

I've added two more functions - one to shift the grid, and one to label the X axis.

A possible optimisation technique for the graph might be to draw the data trace in alternating blocks and moving both blocks to the left (while appending to the right most block). The leftmost block would slide *under* a rectangle to the left of the graph, and the block would get deleted once it had passed completely off the chart. That avoids redrawing the entire line for each point. I haven't tried this because I thought from the application description you were going to be using a lot less data at a much slower speed. I can explain that idea further if you wish.

I've also added a new feature - printing. It prints the graph to a postscript file. There are a lot of different possible configuration options for this, but I've just left it as the defaults.

There are three other points to make here. One is that you can include a #!/usr/bin/python at the top of the file and set the executable bit, and you can run it directly (e.g. "./graph.py"). My examples had that, but your version was missing it. That feature doesn't work on MS Windows of course, as the OS doesn't have that capability.

Another point is that you will see that I've added comments just below a couple of the function names which use triple quotes (""") to start and end the block of comments. A triple quote denotes a block of text. It is a common convention to use this feature for class and function level comments. A lot of software can pull these comments out of the program and display them in documentation.

The final point is that don't mix indentation types. Either use all tabs or all spaces. Having some lines as tabs and some as spaces is asking for trouble since indentation matters. I like to use tabs but either method is acceptable provided you are consistent.


<pre>
#!/usr/bin/python
# simple example that draws a scrolling line graph.
import Tkinter
import random

# We create a class to make it easier to keep static data between calls.
class Graph:


def Xlabel(self, textoffset):
""" Create the x axis labels for a graph.
Parameters: textoffset (integer) = An offst to add to the
label values.
"""
# Label the axes.
for x in range(90, 540, 50):
canvas.create_text(x, 235, text=(x + textoffset - 40), tag='xlabel')

def ShiftGrid(self):
"""This shifts the grid one increment to the left each time it
is called. When the grid has moved one full grid increment, it
is shifted back and relabeled.
"""
# Move the vertical grid lines and labels to the left.
canvas.move('grid', -1, 0)
canvas.move('xlabel', -1, 0)
self._GridPos -= 1
# When the grid has moved one full grid increment, move it
# back to the start position.
if self._GridPos <= 0:
self._GridPos = 50
canvas.move('grid', 50, 0)
# Delete the old labels and draw new ones.
canvas.delete('xlabel')
self._TextOffset += 50
self.Xlabel(self._TextOffset)



def __init__(self):
# Initialise the first Y point.
self._YPoints = [125]

# The X points are all pre-defined.
self._XPoints = range(40, 490, 1)
# Draw the axes.
canvas.create_line(40, 225, 490, 225, fill='blue', width=2)
canvas.create_line(40, 10, 40, 225, fill='blue', width=2)

# Label the axes.
self._TextOffset = 0
self.Xlabel(self._TextOffset)
for y in range(10, 225, 25):
canvas.create_text(15, y, text=(225 - y))

# Draw the grid.
for x in range(90, 540, 50):
canvas.create_line(x, 10, x, 225, fill='green', width=1, tag=('grid'))
self._GridPos = 50


for y in range(10, 225, 25):
canvas.create_line(40, y, 490, y, fill='grey', width=1)

# We draw a small line to initialise the line delete operation
# so we don't have to check each time if a line is already there.
self._PrevLine = canvas.create_line(0,0,0,0)

def UpdateGraph(self):
# Create a new Y point.
self._YPoints.append(random.uniform(50, 200))
# Shift the Y buffer left one it is full.
# Also, shift the grid to the left.
if len(self._YPoints) > 450:
self._YPoints.pop(0)
self.ShiftGrid()

# This bit of magic combines the X and Y points in one list.
GraphPoints = list(sum(zip(self._XPoints, self._YPoints), ()))

# Delete the previous line.
canvas.delete(self._PrevLine)
# Draw a new line.
self._PrevLine = canvas.create_line(GraphPoints, fill='red', width=2)

# Call the update function again later.
root.after(25, self.UpdateGraph)


def PrintGraph(self):
"""Print the graph to a file.
"""
f = open('graphout.ps', 'w+b')
output = canvas.postscript()
f.write(output)
f.close()


# This creates the window.
root = Tkinter.Tk()
root.title('A simple graph.')

# This creates the "canvas" object to draw on.
canvas = Tkinter.Canvas(root, width=550, height=250, bg = 'white')
canvas.pack()

# This creates the graph object.
SimpleGraph = Graph()

# This makes a "quit" button.
Tkinter.Button(root, text='Quit', command=root.quit).pack(side=Tkinter.LEFT)
Tkinter.Button(root, text='Print', command=SimpleGraph.PrintGraph).pack(side=Tkinter.RIGHT)

# Start the graph running.
SimpleGraph.UpdateGraph()


# This is the main event loop.
root.mainloop()
</pre>
 
Top