Graphical Interface

C

Curt Wuollet

Hi all

Even with portability and religious issues aside Tcl/Tk would be a better solution as it allows changes in a screen without a recompile. It would
let us have the advantages of a screen builder (of which there are many good ones available) with the flexibility of a scripting language. (great when the customer wants "one little change"). Another handy thing is that there are quite a few interfaces to databases and Linux tools already available in Tcl/Tk. I am concerned about speed, but I have nothing to base that on yet. The few things I have done with it were fast enough where I didn't notice a problem. I would like to see ncurses or hand coded equivalents so we can also run on modest hardware
(read embedded) With the market for Embedded Linux and Real Time Linux going crazy, it would be good to think small, modular and tight.
The learning curve might be a problem as well, but, as you say there are books and I've seen at least one graphical tool, Visual Tcl. Let me know what you come up with.

Regards

cww


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

Why don't you try Java and JBuilder Foundation?

JBuilder is free, developed by Borland and available for Windows and Linux.

Alternatively, FreeBuilder is available from linux.org.

Plenty of Java Beans (commercial) are already available for SCADA/HMI type purposes.

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

There are so many great ways to develop the interface, and so many excellent tools, that there will never be an optimal solution.

Initially I really wanted to use Java, but this would require one of three options. First, the logic engine (and other stuff) could be
converted to Java. This would be messy and inefficient without pointers, but it might be desirable task for future java devices that are now being planned. The second approach would require interfacing to native C++/C code. This might actually be a good alternative, but if I have an X-interface (well written) it would be easy to later write a java interface. The third would be to use sockets to connect to the logic
engine and/or shared memory. This could get very slow for involved interactions, with the average socket turn-around time being approx 0.1-1ms on the same machine.

Another note, my first rough code was written with basic X11 calls. I then upgraded this to use Motif/Lesstif, but I am finding that it not in
the base installs of many releases, such as Redhat/Mandrake and SuSE. So, I am going to evaluate a package called 'Kdevelop' that is tied to the KDE environment. It allows program layout, much the same way that Visual C++ does.

Hugh

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

I am developing, though not very quickly, a logic engine in Java.

The project description for the jPLC is on the Linux PLC home page and on my personal page at http://www.warrier.demon.co.uk. I have been away from the list for a while for a number of reasons, and have not moved very far with my project. I have a basic design in my head mostly and lots of ideas. I have a number of candidate classes.

> Hi Mark,
>
> There are so many great ways to develop the interface, and so many
> excellent tools, that there will never be an optimal solution.
>
> Initially I really wanted to use Java, but this would require one of
> three options. First, the logic engine (and other stuff) could be
> converted to Java.

there is no reason why a Java HMI couldn't connect to a non-Java logic engine. ther are more than likely going to be several ways of connecting to and from a logic engine and its memory space. jPLC will use (hopefully) CORBA, RMI, TCP/IP and HTTP among others. I also intend to connect to the SMM using jni (Java native method invocation).

> ..... This would be messy and inefficient without pointers,
> but it might be desirable task for future java devices that are now
> being planned.

Contrary to popular belief, Java does have pointers, you just can't do all the things with them that you can with C/C++ pointers. Java objects can only be passed by reference, when you use a Java object you are using dereferenced pointers to the object.

> ........The second approach would require interfacing to native
> C++/C code. This might actually be a good alternative, but if I have an
> X-interface (well written) it would be easy to later write a java
> interface. The third would be to use sockets to connect to the logic
> engine and/or shared memory. This could get very slow for involved
> interactions, with the average socket turn-around time being approx
> 0.1-1ms on the same machine.

SCADA update times are typically of the order of a second(ish), ditto for many commercially available HMIs (e.g. AB's PanelView, Siemens OP25).


> Another note, my first rough code was written with basic X11 calls. I
> then upgraded this to use Motif/Lesstif, but I am finding that it not in
> the base installs of many releases, such as Redhat/Mandrake and SuSE.
> So, I am going to evaluate a package called 'Kdevelop' that is tied to
> the KDE environment. It allows program layout, much the same way that
> Visual C++ does.

JBuilder Foundation has the same front end, IDE as Delphi and C++ Builder. Much more like Visual BASIC than not-Visual C++. There are other products around (http://www.omnis.net) but none have such a high profile (and are not necessarily free).

Also you might want to try glgTool kit http://www.genlogic.com, it is a (commercial) tool kit for real time graphics with support for C/C++ and Java. Ergotech have some beans which have been developed for virtual instrumentation http://www.ergotech.com.

Regards
Mark Hutton
e-mail: mailto:[email protected]
web site: http://www.warrier.demon.co.uk


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

I very much look forward to your code, I looked over your original spec and was impressed at the level of detail you suggested. You comments in
your email are very salient. What I have been dealing with is the basic logic engine and the program verification. If the logic engine, and
supporting code is directly tied to the GUI during programming, the uses simulation, as well as other abilities while programming. So.....I have been coding with the logic engine as the base for the GUI, fully planning to use the logic engine to verify, save and -- when it came time for on-line downloads, it would be possible to keep an update log, and then just pass this log to the currently running PLC. This on-line (hot update) feature is highly desirable among PLC programmers, and would make ours very competitive with existing approaches.

My main concern is that if the cumulative requests form the logic engine (if separated from the GUI) are more than a few dozen the total GUI
response time will slow to more than 1/4 second, and we will start to smell like windoze.

I know that Java does have the container classes for lists - these actually make many programming problems simpler. Wouldn't it be nice if
every body used a language like java. -- NOTE: I still thing Java is a very good way to go, but in the short term, I feel that C++ will be a good first tool. We have used java and RMI for a couple of years now for on-line robot control and simulation of robots, cnc, etc. Note: I am also developing code so that languages can be swapped fairly quickly when the time comes. Even the 'compiled' approach of the LinuxPLC project should be supported beautifully with this method.

I am thinking about developing a communications protocol guided towards asynchronous program updates (on-line and off-line) using Corba,
Java/Scokets, CGI, etc. But, your comments about HMIs would be great if we considered that HMIs based upon Java, Corba, CGI, HTTP, and other web
based protocols so that used could call in to update and control PLCs (Note: the date on this message is May 6th, 2000, so if you want to
apply for a restrictive patent on these methods you are too late). This would allow user to call in from their mobile phone, home computers, or
palm pilots to do simple memory checks, program updates, or system changes. Consider the possibility of using a Linux machine from home,
running the program and directing the display home 'FLCedit -display 198.162.1.32:0' and then changing the program on-line. All of these
features are possible now, and are being used by many others.


Yours objectively,

Hugh

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

There was a tongue in cheek comment I made to the list a while back which stated that jPLC would run on a mobile phone.

There is little point in that, but certainly the ability to monitor the PLC from a mobile phone could be useful. But not as useful as the implementation of messaging services within the control system as a whole. (One of the projects I have had some imput on involved the sending of SMS alarms to an on call mobile phone). An integrated system would be a god send.

(aside)
As a PLC programmer, I have been exasperated by the lack of tools for PDA's. Granted RSI now has PocketLogix, but it is only for wince (ouch!) platforms and does not support IrdA (but then neither do the PLC's, what are they going to do whenthe PC's no longer support RS-232). I'd like to see support for my Epoc32 Psion and PalmOS.

I'd like to talk to you more, but don't have time at the moment. Maybe I'll get time in the week.

Regards
Mark


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