Good morning all. I have spent a little time recently surveying programming tools for ladder logic. Most are very mature and loaded with features. To produce a comfortable environment for folks who have used these tools will be a non-trivial effort. I have thought a little bit on how one would craft such an animal. Fortunately, most gain very little from GUI's. With all the folks lurking, I wanted to see if anyone has done this before I get serious. I'm sure there are many opinions on how to do this and what is needed. I thought I'd get the ball rolling on the various questions. This is where we can get some applications coders on board. What would be easiest to do this in and most universal. I imagine these tools could run on a regular Linux box so the scripting languages are candidates for easy development and extension. TCL, Python, Java? I'd rather not get into the GUI wars and do GTK or K whatever and raw X would make user enhancement unlikely. It would even be possible, (and estremely lightweight) to do this in ncurses although those esthetics might be unacceptable to younger folks. A non-X implimentation is not out of the question. Adapting an existing OSS drawing tool should be very seriously considered, it's the OSS way to "stand on the shoulders of giants" and have something much faster. Output? Boolean, C, ST, compile to a "standard" IL and interpret for on line edits? What is our logic engine going to look like? I have been considering a node struct and linkage. Do we need linkage or can we depend on the ordered nature of left to right, top to bottom? Yes, some of these are rhetorical questions. Actually, I'm hoping we can draw on experience rather than completely reinventing a chariot wheel, as much fun as that might be. We need RLL to even begin to attract interest from the automation populace. I think the time has come where we can support a couple of development threads. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

On Sat, Feb 17, 2001 at 11:51:53AM -0600, Curt Wuollet wrote: > > I have spent a little time recently surveying programming tools > for ladder logic. Most are very mature and loaded with features. > ... > > What would be easiset to do this in and most universal. I imagine > these tools could run on a regular Linux box so the scripting > languages are candidates for easy development and extension. > ... I've been working on interfaces using Perl/Tk, but trying to keep it general, and so hopefully applicable to other platforms. The interface description language used in Mozilla might be worth keeping in mind, though I haven't used it, as a reasonably generic abstraction to target. I haven't done much with RLL GUIs, but if the LPLC presents an API or protocol it ought to be possible to interface to it in a variety of ways. > not out of the question. Adapting an existing OSS drawing > tool should be very seriously considered, it's the OSS way > to "stand on the shoulders of giants" and have something > much faster. I've tried to do a little with XFig, but haven't found a good way to automate it. > Output? Boolean, C, ST, compile to a "standard" IL and > interpret for on line edits? What is our logic engine > going to look like? > > I have been considering a node struct and linkage. Do we > need linkage or can we depend on the ordered nature of > left to right, top to bottom? Yes, some of these are > rhetorical questions. I (almost) hate to bring up XML again, but it might provide a good way to describe the LPLC interface, and so could be a go-between with other systems. > Actually, I'm hoping we can draw on experience rather than > completely reinventing a chariot wheel, as much fun as that > might be. We need RLL to even begin to attract interest from > the automation populace. I think the time has come where we > can support a couple of development threads. I'm afraid I'm working on the sidelines, and nothing to show for it, but will chip in whatever I can. Ken -- Ken Irving <[email protected]> _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Ken Irving wrote: > > On Sat, Feb 17, 2001 at 11:51:53AM -0600, Curt Wuollet wrote: > > > > I have spent a little time recently surveying programming tools > > for ladder logic. Most are very mature and loaded with features. > > ... > > > > What would be easiset to do this in and most universal. I imagine > > these tools could run on a regular Linux box so the scripting > > languages are candidates for easy development and extension. > > ... > > I've been working on interfaces using Perl/Tk, but trying to keep it > general, and so hopefully applicable to other platforms. The interface > description language used in Mozilla might be worth keeping in mind, > though I haven't used it, as a reasonably generic abstraction to target. You now have a great opportunity to be our Perl/Tk guy:^) I hadn't mentioned it only because I know almost nothing about it. I don't know a lot about the others, but I've seen examples that looked like it could be done. > I haven't done much with RLL GUIs, but if the LPLC presents an API > or protocol it ought to be possible to interface to it in a variety > of ways. I see this as something standalone we can start now and resolve the output format as that becomes clear. With on line editing and such this may not be entirely true but, we _have_ to get more stuff happening and more people involved. There used to be third party tools with this functionality for PLC's, so it should be possible without tight integration (dependence) on the ongoing work. Modular is better if we can do it. There's plenty to do before the tool actually produces output. A pseudocode target for now would be sufficient. > > not out of the question. Adapting an existing OSS drawing > > tool should be very seriously considered, it's the OSS way > > to "stand on the shoulders of giants" and have something > > much faster. > > I've tried to do a little with XFig, but haven't found a good > way to automate it. I've been looking at packages that are "rule based" similar to rung construction. There are a few to look at like xcircuit and some flowcharting packages that understand a library of symbols and that they are connected. PC board software is also worth looking at like PCB and Geda. Most of these seem to be X programming exercises. I am going to research TCL/Tk and Python sites for examples like this. I really would like to see something easily extensible so we can start with a core and get folks to extend it to suit their needs. We could then have AB flavor or GE flavor or Modicon flavor. This would help a lot with the religious aspect of attracting people. > > Output? Boolean, C, ST, compile to a "standard" IL and > > interpret for on line edits? What is our logic engine > > going to look like? > > > > I have been considering a node struct and linkage. Do we > > need linkage or can we depend on the ordered nature of > > left to right, top to bottom? Yes, some of these are > > rhetorical questions. > > I (almost) hate to bring up XML again, but it might provide > a good way to describe the LPLC interface, and so could be > a go-between with other systems. If we have someone who can write the other end, that's an option. I'm trying to stick to what I know we can do but I'm all ears for discussions on what the logic engine or solver will run. I know we can run a compiled C target as a solver. I know we can translate boolean equations into something else. I don't know what that something else might be at the moment. The ST code will output C as I understand it, and there was enthusiasm for multiple solvers at one time. Part of this is to spur thinking and discussion on how we are going to pull this together. I knew that at one time, but we have gone a different direction. If the ST thing firms up we should probably abstract the functions from that and use them as a target at least for the near term. Or?................. > > Actually, I'm hoping we can draw on experience rather than > > completely reinventing a chariot wheel, as much fun as that > > might be. We need RLL to even begin to attract interest from > > the automation populace. I think the time has come where we > > can support a couple of development threads. > > I'm afraid I'm working on the sidelines, and nothing to show > for it, but will chip in whatever I can. Please do, and feel free to tell me if I'm being an impediment rather than a facilitator. I am trying hard not to discourage anyone. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt Wuollet: > I imagine these tools could run on a regular > Linux box so the scripting languages are > candidates for easy development and extension. > TCL, Python, Java? Not sure if there's much point doing it in one of these: writing or changing the IDE is hard anyway, no matter the language, installing a C compiler is the least problem. Though one of these is a good idea if we want a scripting language for the thing; no point inventing a new one. > I'd rather not get into the GUI wars and do GTK > or K whatever and raw X would make user > enhancement unlikely. I think this is a case of whoever codes it first, wins Anyway, that's just widgets; there's no problem running a K program under gnome or vice versa, it'll just look and feel a bit alien. > It would even be possible, (and estremely > lightweight) to do this in ncurses although > those esthetics might be unacceptable to > younger folks. As much as I like text interfaces, I don't think doing it in ncurses would be particularly good. No matter what you do it'll end up ugly, and I'm not sure it'd be all that much less work. We could do a web interface; that way you can have graphics but only ever actually handle text. But - there isn't really any (good) way of putting text in there, for labelling the contacts. Either we do it as ordinary text, then the lines won't quite join up, or we do it as images, character by character. And any advantage gained from not having to deal with the GUI is quickly reversed by the lack of state and security. > I have been considering a node struct and > linkage. Do we need linkage or can we depend on > the ordered nature of left to right, top to > bottom? Yes, some of these are rhetorical > questions. For stepladder, it is top to bottom, left side then right side. If we want to do a non-stepladder graphical language, then yes, we need nodes and links and all sorts of things. We also need to invent one. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r

 

>We could do a web interface; that way you can have graphics but only ever >actually handle text. But - there isn't really any (good) way of putting >text in there, for labelling the contacts. Either we do it as ordinary >text, then the lines won't quite join up, or we do it as images, character >by character. Use SVG (Scalable Vector Graphics), the new W3C standard for vector graphics on the web. It is perfect for generating dynamic graphics on the fly and can include text in the graphic that is searchable, copyable, pasteable, etc. The only problem is that it is basically a Windows only solution for now, but, Mozilla is working on native support which will make it available on other platforms. I am currently using it to develop a web based HMI for my Allen Bradley plc's and find it to be very powerful. For a simple example of data driven SVG graphics go to: (Registration required) http://groups.yahoo.com/group/svg-developers/files/Datadriven/ Download the four files there to your hard drive, open invis.html in an editor and frames.html in your browser. When you make changes to the data in the values array, the graphic in the browser will update. The SVG plugin from www.Adobe.com is required. Works in NS 4.xx and IE 5.xx. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Jiri and all Jiri Baum wrote: > > Curt Wuollet: > > I imagine these tools could run on a regular Linux box so the scripting > > languages are candidates for easy development and extension. TCL, > > Python, Java? > > Not sure if there's much point doing it in one of these: writing or > changing the IDE is hard anyway, no matter the language, installing a C > compiler is the least problem. Though one of these is a good idea if we > want a scripting language for the thing; no point inventing a new one. > It might make a certain amount of sense if the graphical portions were done in the same language. Someone who could customize HMI/SCADA could also customize the instruction set. It would also be good if this could be someone more typical of an integrator. > > I'd rather not get into the GUI wars and do GTK or K whatever and raw X > > would make user enhancement unlikely. > > I think this is a case of whoever codes it first, wins As always. > Anyway, that's just widgets; there's no problem running a K program under > gnome or vice versa, it'll just look and feel a bit alien. > > > It would even be possible, (and estremely lightweight) to do this in > > ncurses although those esthetics might be unacceptable to younger folks. > > As much as I like text interfaces, I don't think doing it in ncurses would > be particularly good. No matter what you do it'll end up ugly, and I'm not > sure it'd be all that much less work. I was just threatening :^) Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc