Configuration was XML

C

Thread Starter

Curt Wuollet

I have been looking to tcl/tk to produce "fill in the blanks" config tools mostly for the reason that it's the expected ease of use standard in
the industry, and we _have_ to circumvent "the Linux has no gui" fud. We will, of course, produce editable files for those who would rather
simply import or heads down key hundreds of points rather than wimp their way through an afternoon. I'm sure Glade or some other gui
builder could be used to produce these config screens also. Since we will have highly diverse and idiosyncratic IO connected, a set could consist of a driver, config screen script, and an IO proc that will link in to add the IO to the scan loop and map. Tcl/tk has the advantage
that a lot of the code would be reused from screen to screen making adding an IO type a task that more people could handle. Part of my job as team leader is to keep things supportable through normal attrition and use tools that most people can understand. I would like the win/win that we support traditional UNIX text config files and
still provide easy "fill in the blanks" mistake proof configuration for the command line challenged. The typical documentation last or never attitude of developers is somewhat mitigated in this fashion. The commonalities between say, configuring a DIO card and intelligent Ethernet IO are practically nil. This makes a "universal" setup scheme quite difficult to realize. I lean strongly towards modular dedicated configuration tools that match the features of the device and don't require rebuilding any common code when adding a new device type. This means of course a defined API to the SMM and an IO scheduler API that handles IO in a consistant high level manner. We config the IO, register the particular IO proc with the IO scheduler on init and go.

The config files would then have common sections mapping the IO and switches of the type being discussed, start up state, persistance, etc. anything that we support across all IO. They
would also require a section with any specific details for the IO device, eg IRQ, DMA chan, hardware MAC address, baud rate, phase of the moon, magic incantations, etc, that it takes to actually get the thing to work.

I would greatly prefer that these _not_ be stanzas in a huge common config file as debugging would be a nightmare and an errant config could whack the parser and stop everything. I would rather have a menu of config screens in keeping with the incremental development and fluid nature of a project such as this.

I have not communicated this previously as we are not dealing with this area yet. I bring it out now not to provoke a flurry of discussion when nobody's writing the code for it but, to illustrate my reasons for reluctance to jump into XML or other universal schemes at this point. In effect to say: "tho' this be madness yet there is method to it". I am not simply rejecting things out of hand. I have a plan and when we get to discussing the plan at coding time, I'm sure XML will resurface and, if it makes sense be adopted.
This is slightly dictatorial at this point. but only because mine is the only plan I've seen pending that discussion. This is of course, open for discussion, but that would be more fruitful when we are close to writing the code. We have a problem with focus here, but a reasonable amount of anarchy is a good thing.

Regards

cww


jackh wrote:

> Hi,
>
> Before using XML I was just hacking together a file format by hand. It
> started to get ugly when I added the configuration for the IO scanner.
> The IO devices are much more varied between device.
>
> The XML structure did force some integrity. In particular you can
> develop a document definition format (Document Type Definition - DTD)
> that includes argument types, hierarchy, allowed repititions, etc. With
> XML you can parse it with software that will check the document for
> basic layout and syntax (non-validating), or you can do full document
> checking that verifies content also (validating). On the FreeLC (the
> PLC) I have written my own parser that does the final validation, but on
> the programming software and other client programs a validating parser
> makes a lot of sense, and will add another layer of defense against user
> program bugs. This format also means that if you want to construct PLC
> files by hand you can use an XML editor, and be more sure that it is
> correct.
>
> Hugh
>
> |
> |
> |Is any data integrity brought to the table

Snip (for brevity)



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> I have been looking to tcl/tk to produce "fill in the blanks" config
> tools mostly for the reason that it's the expected ease of use standard
> in the industry, and we _have_ to circumvent "the Linux has no gui" fud.
...

I'd somewhat prefer python/tk over tcl/tk, but it's not very important.

Advantage: python is a lot more structured and modular.

Disadvantage: the tkinter documentation sucks. (But we'll have our own guidelines anyway, so they'll just have to be a bit more thorough.)

> The config files would then have common sections mapping the IO and
> switches of the type being discussed, start up state, persistance, etc.
> anything that we support across all IO. They would also require a
> section with any specific details for the IO device, eg IRQ, DMA chan,
> hardware MAC address, baud rate, phase of the moon, magic incantations,
> etc, that it takes to actually get the thing to work.

Suggestion: it should be possible for one config variable to appear several times in the GUI. I've seen that once (in a mail client, I think) and it
was very nice.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi All,

Let's set the language aside for a moment, does the rest make sense?

On the language side, both are semi-commercial with licenses that need to be examined in detail. Since this is adding to the burden for
developers,which is simpler should be an important consideration. An even better feature would be a GUI builder. I know one exists for tcl. I'm not sure about Python. The reason to consider this carefully is that it would probably become the graphics language of choice for UI's throughout the project. Which is smaller? Faster? Are there other candidates? What do we do about character based equivalents for very small environments? Can we do a full SCADA module in the language? Can an end user deal with it? What ever we pick will be the look and feel that most users experience. It's gotta be good. They will have no vested interest in using our stuff.
It's a very important decision. I like curses myself :^) (just kidding).

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Tue, Sep 12, 2000 at 08:39:36PM -0500, Curt Wuollet wrote:
>
> On the language side, both are semi-commercial with licenses that
> need to be examined in detail. Since this is adding to the burden for
> developers,which is simpler should be an important consideration.
> An even better feature would be a GUI builder. I know one exixts
> for tcl. I'm not sure about Python. The reason to consider this carefully
> is that it would probably become the graphics language of choice for
> UI's throughout the project. Which is smaller? Faster? Are there
> other candidates? What do we do about character based equivalents

Perl/Tk would be another one, and AFAIK all three of these wrap the same graphical toolkit, with widgets and events, links to system resources, etc.


> for very small environments? Can we do a full SCADA module in
> the language? Can an end user deal with it? What ever we pick
> will be the look and feel that most users experience. It's gotta be
> good. They will have no vested interest in using our stuff.
> It's a very important decision.
> I like curses myself :^) (just kidding).

Kidding aside, if a suitable API or protocol(s) can be defined, then perhaps the interface could be realized in any of these ways. I doubt if any graphical environment could compete with curses in terms of memory requirements.

--
Ken Irving <[email protected]>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Yes no GUI env is going to beat curses in efficiency terms, but curses doesn't do much either. The closest in efficiency is the X. But that means X programming and if you use Motif then there is the overhead of MWM. I don't really know what to suggest. Tk on TCL and Python both can not be embedded but X can and it also caters for interrupts, but those who have coded in X know it is a very low level and everything has to be done by the programmer (A lot of code for little GUI return).
I am going to watch this discussion extend a bit more as I am little confused as where we are going (Open to ideas).
Thanks
Bob-


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> Yes no GUI env is going to beat curses in efficiency terms, but
> curses doesn't do much either. The closest in efficiency is the X.
> But that means X programming and if you use Motif then there is
> the overhead of MWM.

&lt;two-cents>
What overhead does MWM introduce besides that it is a window manager, like fvwm, enlighten, kwm, (numerious other not to mention).

The question rather is whether to use Motif or some other toolkit. Motif is based on Xt, the X Intrinsic Toolkit. Written in plain C it
features an object-oriented approach with information hiding, encapsulation, inheritance. However, from my own experience, it's a pain, especially if you need to write your own widgets when nothing appropriate is available in Motif itself. I once wrote a full-blown ComboBox widget for Motif 1.1/1.2, so I learned writing Motif
widgets the hard way. The "Inside LessTif" documentation is to a large extend a result of this -- just look at the BaseClass mess the OSF did; this part of code is simply rotten.

The code base of Motif has really come to its age. On the other hand, Motif is still a defacto-standard in industry. But Qt seems to be hard at its heels. On yet a third hand, Gtk+ has quite some nice bindings for several (scripting) languages.
&lt;/two-cents>

> I don't really know what to suggest. Tk on TCL and Python both
> can not be embedded but X can and it also caters for interrupts,
> but those who have coded in X know it is a very low level and
> everything has to be done by the programmer (A lot of code for
> little GUI return).

&lt;two-cents>
Xlib programming is no fun either, so you will surely need some kind of framework. Qt seems to have one of the best abstraction from Xlib or Win32 today, but you'll have to swallow C++.

Bob, aside from this, what do you mean with "interrupts". If I understand right, you mean Xlib's ability to handle simple timers and external I/O (the latter based on file descriptors). None of them are really interrupts, they can only be cooperative in a GUI
environment. So if you are stuck in a lengthy piece of code and do not dispatch (GUI) events, neither timers nor I/O is handled.
&lt;/two-cents>

Harald


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> Since this is adding to the burden for developers,which is simpler should
> be an important consideration.

I believe python is closer to the current thinking on "good" programming languages; arguably that translates into "simpler". It is structured, object-oriented but not rabidly so, variables default to local, etc.

In some ways, it's designed to have and enforce clarity. Most noticeably, it has compulsory indentation. Unlike certain other scripting language(s), it does not use variable names composed of punctuation symbols.

> An even better feature would be a GUI builder. I know one exixts for tcl.
> I'm not sure about Python.

Since they use the same GUI, the rest of the discussion is not so much tcl vs python but tk vs something else.

> The reason to consider this carefully is that it would probably become
> the graphics language of choice for UI's throughout the project. Which
> is smaller? Faster? Are there other candidates?

This is, of course, an important question. I don't think there are other *scripting* GUIs out there - perl, python and tcl all use tk. But there are other GUI libraries for C.

> Can we do a full SCADA module in the language?

That's a different thing, to some extent; there's no reason why the configuration front-end and the MMI should be programmed in the same language.

Since the two have fairly different requirements, it may well end up that they'll be completely separate, programmed with different toolkits.

(rearranged)
> What do we do about character based equivalents for very small
> environments? [...] I like curses myself :^) (just kidding).

Well, there's mmi/curses/vitrine - because we *do* need character-based equivalents. And because they're easiest to write. It needs colour, tho.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

David Nimmons

My .02 cents worth.
Do every thing through a web browser, much like the Procedia.
I do not know what languages would best be suited for that as I am just now starting to explore that area.
Hm, if you do everything through your web browser, then maybe XML makes sense.
Oops, sorry, here we go again. :)


>The reason to consider this carefully
>is that it would probably become the graphics language of choice for
>UI's throughout the project.

>What ever we pick
>will be the look and feel that most users experience. It's gotta be
>good. They will have no vested interest in using our stuff.
>It's a very important decision.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
T

Thong Phat Co., Ltd.

Curt Wuollet wrote:

>I have been looking to tcl/tk to produce "fill in the blanks" config tools
>mostly for the reason that it's the expected ease of use standard in
>the industry, and we _have_ to circumvent "the Linux has no gui" fud.
>We will, of course, produce editable files for those who would rather
>simply import or heads down key hundreds of points rather than wimp
>their way through an afternoon. I'm sure Glade or some other gui
>builder could be used to produce these config screens also. Since we
>will have highly diverse and idiosyncratic IO connected, a set could
>consist of a driver, config screen script, and an IO proc that will link
>in to add the IO to the scan loop and map. Tcl/tk has the advantage
>that a lot of the code would be reused from screen to screen making
>adding an IO type a task that more people could handle. Part of my
>job as team leader is to keep things supportable through normal
>attrition and use tools that most people can understand. I would like
>the win/win that we support traditional UNIX text config files and
>still provide easy "fill in the blanks" mistake proof configuration for
>the command line challanged. The typical documentation last or never
>attitude of developers is somewhat mitigated in this fashion. The
>commonalities between say, configuring a DIO card and intelligent
>Ethernet IO are practically nil. This makes a "universal" setup scheme
>quite difficult to realize. I lean strongly towards modular dedicated
>configuration tools that match the features of the device and don't
>require rebuilding any common code when adding a new device type.
>This means of course a defined API to the SMM and an IO scheduler
>API that handles IO in a consistant high level manner. We config the
>IO, register the particular IO proc with the IO scheduler on init and
>go.
>... clip.

I have used tcl/tk. This script language is terrible if you have to update your screen for time intervals; it displays digit by digit in a string number, so the new digit alignment will make the number blink. Moreover, there is no pointer, it is very difficult to handle structure data. I think tcl/tk is not a suitable GUI for LinuxPLC.

Qt Designer from http://www.trolltech.com may be a good GUI toolkit. Their classes are the core of KDE desktop. It is free if the application source
codes are open in Linux. The current version Qt.2.2.0
ftp://ftp.trolltech.com/qt/source/qt-x11-2.2.0.tar.gz ) supports:
networking, multi-threading, XML, a lot of powerful widgets, cross-platform (but not free for Windows) etc. It is very easy to learn and use, but someone may not like it because it is C++ language.


>The config files would then have common sections mapping the IO
>and switches of the type being discussed, start up state,
>persistance, etc. anything that we support across all IO. They
>would also require a section with any specific details for the IO
>device, eg IRQ, DMA chan, hardware MAC address, baud rate,
>phase of the moon, magic incantations, etc, that it takes to actually
>get the thing to work.
>
>I would greatly prefer that these _not_ be stanzas in a huge common
>config file as debugging would be a nightmare and an errant config
>could whack the parser and stop everything. I would rather have a
>menu of config screens in keeping with the incremental development
>and fluid nature of a project such as this.
>
>I have not communicated this previously as we are not dealing
>with this area yet. I bring it out now not to provoke a flurry of
>discussion when nobody's writing the code for it but, to illustrate
>my reasons for reluctance to jump into XML or other universal
>schemes at this point. In effect to say: "tho' this be madness yet
>there is method to it". I am not simply rejecting things out of hand.
>I have a plan and when we get to discussing the plan at coding
>time, I'm sure XML will resurface and, if it makes sense be adopted.
>This is slightly dictatorial at this point. but only because mine is
>the only plan I've seen pending that discussion. This is of course,
>open for discussion, but that would be more fruitful when we are
>close to writing the code. We have a problem with focus here, but
>a reasonable amount of anarchy is a good thing.

XML was designed for a very wide networking interface. For a local application like LinuxPLC, XML is not the core of the project and it is too
soon to focus on XML. It can be add-on later if XML was not overwritten by other wave.

Regards,

Hung Lam


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
Jiri Baum <[email protected]> writes:

> Curt Wuollet:
> > Since this is adding to the burden for developers,which is simpler should
> > be an important consideration.
>
> I believe python is closer to the current thinking on "good" programming
> languages; arguably that translates into "simpler". It is structured,
> object-oriented but not rabidly so, variables default to local, etc.

As someone who's worked with all of Python, Perl and Tcl I agree that Python is easiest to learn and most likely to lead to readable and maintainable code.

> > An even better feature would be a GUI builder. I know one exixts for tcl.
> > I'm not sure about Python.

There are some for various GUI libraries. Most are rather immature, but then so is this project. Since some are being actively worked on, there's a good chance that things will get better soon.

> Since they use the same GUI, the rest of the discussion is not so much tcl
> vs python but tk vs something else.
>
> > The reason to consider this carefully is that it would probably become
> > the graphics language of choice for UI's throughout the project. Which
> > is smaller? Faster? Are there other candidates?
>
> This is, of course, an important question. I don't think there are other
> *scripting* GUIs out there - perl, python and tcl all use tk. But there are
> other GUI libraries for C.

Several of these libraries also have interfaces for Python (and Perl). One that I would suggest looking at is wxWindows/wxPython. It's
portable, flexible, has been used for commercial applications and seems to have a committed set of developers. It is widely reported to be faster than Tk, at least via the Python interfaces. The Linux version is the main one and is based on the GTK+ toolkit, which is based on Xlib. The wxWindows license is "essentially the L-GPL
(Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms". See http://wxWindows.org/ and http://wxPython.org/ for more information.

> > Can we do a full SCADA module in the language?
>
> That's a different thing, to some extent; there's no reason why the
> configuration front-end and the MMI should be programmed in the same
> language.

I agree. There are strong arguments for having a character based version of the configuration front-end. This could use curses or something else -- it's my impression that most Linux config utilities actually use something other than curses. The main MMI can probably depend on having a real window system. IMHO, portability is a real plus here -- there may well be a lot of potential users who would be happy to have Linux on the controller but will have political or
ecconomic requirements to support MMI on Windows as well.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Harold,
By interrupts I meant that it is good old 'C' so implementing the interrupts will be easy and all unix implementations have hooks for the Kernel (C libraries) which means it can become part of code without a lot of hassel (The pain will be writing
the C code). One of my main criteria for this project is that the plc must be diskless and networkable, that's why I thought of X.

But I'll keep watching and listeneing.
Thanks
Bob-


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
"Thong Phat Co., Ltd." wrote:

> I have used tcl/tk. This script language is terrible if you have to update
> your screen for time intervals; it displays digit by digit in a string
> number, so the new digit alignment will make the number blink. Moreover,
> there is no pointer, it is very difficul to handle structure data. I think
> tcl/tk is not a suitable GUI for LinuxPLC.
>
> Qt Designer from http://www.trolltech.com may be a good GUI toolkit. Their
> classes are the core of KDE desktop. It is free if the application source
> codes are open in Linux. The current version Qt.2.2.0
> ftp://ftp.trolltech.com/qt/source/qt-x11-2.2.0.tar.gz ) supports:
> networking, multi-threading, XML, a lot of powerful widgets, cross-platform
> (but not free for Windows) etc. It is very easy to learn and use, but
> someone may not like it because it is C++ language.

That would be me. I've also got this crazy idea about having the UI be interpreted so you can change it without a recompile. Still Qt looks really good and the libraries are now GPL'd. Stay tuned.

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
Curt,

You have my attention. I would like to hear more about an XML/GUI thing and would be interested in contributing to it. I have been investigating the Aachen stuff, XML, and GNOME's graphical editor, DIA this past summer.

DIA uses XML as it's native file format. This thing could possibly be used to construct widgets and attach them to signal names. We could then
write our own stuff to display the resulting XML definition. I suppose we could write our own editor.

The Aachen stuff, very simply, is a methodology for constructing scalable control systems over multiple platforms and cpu's. I am very impressed with their work as this methodology can be extremely effective.

A widely accepted file format such as XML could be the GLUE that brings everything all together. It has the advantage being well defined and
undefined simultaneously. This means that if in the future a new ?ML is invented there will be tools and API libraries already written to
process the new ?ML.


regards,

rickj

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
> > The reason to consider this carefully is that it would probably become
> > the graphics language of choice for UI's throughout the project. Which
> > is smaller? Faster? Are there other candidates?
>
> This is, of course, an important question. I don't think there are other
> *scripting* GUIs out there - perl, python and tcl all use tk. But there are
> other GUI libraries for C.
>
> > Can we do a full SCADA module in the language?
>
> That's a different thing, to some extent; there's no reason why the
> configuration front-end and the MMI should be programmed in the same
> language.

Well, there is the reason that it would be handy if a person didn't have to learn too many languages to be a developer or simply hack the code. I sympathise also with educational users who don't want to teach units on half a dozen languages to use lplc as subject matter. That really sounds harsher than I mean it to be. Those are considerations, sorry. And there's my half-baked notion that an interpreted scripting language would be good for a really customizable HMI/SCADA that is really adaptable to what the user is doing. There's also the consistancy thing. It's on those last two I could really use some input from our body of experts. Would an easily customizable HMI/SCADA be worth the hassle of developing the whole thing in a scripting language? Would anybody use it? And is a
consistant UI for all tools important? I haven't done a lot of SCADA.

> Since the two have fairly different requirements, it may well end up that
> they'll be completely separate, programmed with different toolkits.
>
> (rearranged)
> > What do we do about character based equivalents for very small
> > environments? [...] I like curses myself :^) (just kidding).
>
> Well, there's mmi/curses/vitrine - because we *do* need character-based
> equivalents. And because they're easiest to write. It needs colour, tho.

What does RedHat use for their text install screens(at least on older vers)? Those are viewable on the console, are text, but colorful. Isn't that Python? I'll rummage around and take a look. If we could do both with one language that would be a win. Might be a bit heavy for embedded hardware though.

Regards
cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> > > Can we do a full SCADA module in the language?

Jiri Baum:
> > That's a different thing, to some extent; there's no reason why the
> > configuration front-end and the MMI should be programmed in the same
> > language.

Curt Wuollet:
> Well, there is the reason that it would be handy if a person didn't have
> to learn too many languages to be a developer or simply hack the code. I
> sympathise also with educational users who don't want to teach units on
> half a dozen languages to use lplc as subject matter. That really sounds
> harsher than I mean it to be. Those are considerations, sorry.

No worries.

> And there's my half-baked notion that an interpreted scripting language
> would be good for a really customizable HMI/SCADA that is really
> adaptable to what the user is doing.

I'm not really comfortable with doing real-time stuff in a scripting language, but I can't think of an explicit reason. Maybe just that scripting languages tend take more memory, run slower, or both, compared with C code.

> There's also the consistancy thing. It's on those last two I could really
> use some input from our body of experts. Would an easily customizable
> HMI/SCADA be worth the hassle of developing the whole thing in a
> scripting language? Would anybody use it? And is a consistant UI for all
> tools important?

Remember, SCADA isn't a tool, really - it's the product. The creation and user screens of SCADA can reasonably be totally different animals.

> > (rearranged)
> > > What do we do about character based equivalents for very small
> > > environments? [...] I like curses myself :^) (just kidding).

> > Well, there's mmi/curses/vitrine - because we *do* need character-based
> > equivalents. And because they're easiest to write. It needs colour, tho.

> What does RedHat use for their text install screens(at least on older
> vers)?

I'm not sure - I think Debian does some variant on the dialog or whiptail program. But I don't think these are really usable as MMI/SCADA - they just aren't designed for it.

For text-based, I really think that the approach vitrine takes is just about the only way. We may add colours, and numbers, and whatever; but we
don't really need much else for the output side.

In any case, if you *do* need a whiptail-style input/output, you can use the smm/plctest program. (That reminds me, I was thinking there ought to be a command-line I/O driver. So that LPLC points can trigger commands. Eg you might specify that point "Light" is mapped to "heyu turn a5 on/off".)

The web-based thing sounds interesting, but I think we'll eventually need both. However, from an immediate point of view, the web-based thing would probably be easier.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > Yes no GUI env is going to beat curses in efficiency terms, but curses
> > doesn't do much either. The closest in efficiency is the X. But that
> > means X programming and if you use Motif then there is the overhead of
> > MWM.

> <two-cents> What overhead does MWM introduce besides that it is a window
> manager, like fvwm, enlighten, kwm, (numerious other not to mention).

Most applications won't need a window manager at all. X can run without one.

(Just give every window an explicit geometry on startup.)

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Jiri Baum wrote:
...
> I'm not really comfortable with doing real-time stuff in a scripting
> language, but I can't think of an explicit reason. Maybe just that
> scripting languages tend take more memory, run slower, or both, compared
> with C code.

Yes, but X programming is non-trivial to say the least. Part of our attraction is to be accessable, at least in the parts most likely
to want customization. We can't hope to display in true real time anyway, but I know what you mean. No one is going to be impressed by my curses screens however. I would prefer C myself. Many of the existing realtime "demo" apps use this technique to produce, for example, a virtual oscilloscope with the DAQ running in the realtime schedule and tcl/tk doing the pretty display. It is in a sense "realtime" as one trace uses 2048 DAQ samples. This is not edict, merely what I have seen done that approximates the commercial
"state of the art" It was done with a fairly small amount of code. With appropriate widgits, you can do a lot with a little code if you keep all the calculations, etc. on the compiled side.

> > There's also the consistancy thing. It's on those last two I could really
> > use some input from our body of experts. Would an easily customizable
> > HMI/SCADA be worth the hassle of developing the whole thing in a
> > scripting language? Would anybody use it? And is a consistant UI for all
> > tools important?
>
> Remember, SCADA isn't a tool, really - it's the product. The creation and
> user screens of SCADA can reasonably be totally different animals.
>
> > > (rearranged)
> > > > What do we do about character based equivalents for very small
> > > > environments? [...] I like curses myself :^) (just kidding).
>
> > > Well, there's mmi/curses/vitrine - because we *do* need character-based
> > > equivalents. And because they're easiest to write. It needs colour, tho.
>
> > What does RedHat use for their text install screens(at least on older
> > vers)?
>
> I'm not sure - I think Debian does some variant on the dialog or whiptail
> program. But I don't think these are really usable as MMI/SCADA - they just
> aren't designed for it.
>
> For text-based, I really think that the approach vitrine takes is just
> about the only way. We may add colours, and numbers, and whatever; but we
> don't really need much else for the output side.
>
> In any case, if you *do* need a whiptail-style input/output, you can use
> the smm/plctest program. (That reminds me, I was thinking there ought to be
> a command-line I/O driver. So that LPLC points can trigger commands. Eg you
> might specify that point "Light" is mapped to "heyu turn a5 on/off".)
>
> The web-based thing sounds interesting, but I think we'll eventually need
> both. However, from an immediate point of view, the web-based thing would
> probably be easier.

Does that mean Java?

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> > > And there's my half-baked notion that an interpreted scripting
> > > language would be good for a really customizable HMI/SCADA that is
> > > really adaptable to what the user is doing.

Jiri Baum:
> > I'm not really comfortable with doing real-time stuff in a scripting
> > language, but I can't think of an explicit reason. Maybe just that
> > scripting languages tend take more memory, run slower, or both,
> > compared with C code.

Curt Wuollet:
> Yes, but X programming is non-trivial to say the least.
...
> for example, a virtual oscilloscope with the DAQ running in the realtime
> schedule and tcl/tk doing the pretty display.

This may be a good way to do it.

Alternatively, it may end up that our application would be sufficiently configurable that it is almost like a script.

> With appropriate widgits, you can do a lot with a little code if you keep
> all the calculations, etc. on the compiled side.

Then again, there are mathematics packages for the scripting languages, various kinds of matrices and statistics and stuff - maybe for some kinds of calculations that would be useful.

...
> > The web-based thing sounds interesting, but I think we'll eventually
> > need both. However, from an immediate point of view, the web-based
> > thing would probably be easier.

> Does that mean Java?

I hope not.

It shouldn't be necessary, anyway, and at least at the basic level we don't even want Java (or Javascript). Plain old http/html can do most of it, and we can fake the rest.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top