A few months ago on this list we discussed ladder logic editors. At the time I said that I thought it would be possible to create a ladder logic editor that would run in a standard web browser without using any plug-ins. I've written a basic editor and have it on line on my MBLogic project web site.

This is a direct link to the editor:
http://mblogic.sourceforge.net/techdemo/laddertest.xhtml

This is a direct link to some documentation on how to use it (see the additional links on that page for more help web pages with details.):
http://mblogic.sourceforge.net/techdemo/ladhelp/ladderhelp.html

The demo itself requires Javascript and SVG, so it will run in almost all modern web browsers (it won't run in MS IE however, as that program doesn't have SVG to allow dynamic display of graphics). I've tested it on Mozilla Firefox, Google Chromium, and Opera. It will probably work on Apple Safari as well (but I haven't tested that one).

It's not integrated into the MBLogic open source soft logic platform yet as I still have some work to do to integrate it into the system (some of the processing will be done on the MBLogic server). The demo web page just loads some "dummy" static data from a file to allow a single subroutine to be edited.

However, this sample demonstrates that the idea is practical. You can at present:

1) Add and delete rungs.

2) Edit individual rungs while adding and deleting contacts, coils, timers, etc.

3) Edit addresses.

4) Edit subroutine and rung comments.

Everything was done using bog standard AJAX web programming techniques. All the editing actions take place directly in the web page without reloading the page.

I plan to do another demo which will show how live on-line ladder status can be displayed in a web page by combining techniques used in this example with techniques used in the web based HMI that I wrote a while ago. Again, this would simply use well established and widely used standard AJAX web programming techniques.

I thought this might be of interest to other people as it shows what is possible. The ideas can be applied to more things that just my own MBLogic open source project.

While it isn't something that you could graft onto an existing conventional PLC (at least not easily), it is something that a conventional PLC maker could build into their own product if they wanted to (they would need their own version of it of course).

For example, I mentioned on-line monitoring of a ladder diagram in a web page. Wouldn't it be nice to be able to troubleshoot a PLC program by just connecting to the PLC CPU using a standard web browser? It's not actually that hard to implement, <i>if</i> you're the PLC manufacturer and can insert the (fairly simple) support logic into the system.

Also imagine, you wanted to do some quick and simple on-line editing of a program (as the demo shows). Again, it would be possible to do this <i>if</i> the PLC included the (relatively simple) support logic.

If anyone wants to discuss how the system works I would be happy to talk about it. I'm trying to use this to start off a discussion of how these concepts could be used in the automation industry. I would also appreciate some feedback on the demo itself. I think this technique is something the automation industry should be embracing. It doesn't necessarily render conventional programming packages obsolete, but it would offer some new and convenient options for people who have to operate and maintain equipment.

I will forestall a few comments though by pointing out that yes, I know the demo doesn't have cross referencing built in - that feature has already been built into MBLogic for a while and so isn't shown here. The same goes for creating and deleting subroutines, saving changes, etc. The sample web page is just intended to demonstrate actually editing ladder instructions.

 

That is way cool, Michael!

And it works fine on Swiftfox 3.6 for another data point. Am I right in assuming that this file is laid out like the cell array used for editing? I'll have to take a look if that's up. One reason that it's a big deal, is that we need _one_ OSS ladder editor rather than 20. So, unless I can do way better soon(unlikely), I will see what I can do with yours, going towards the hardware.

Regards
cww

 

At the moment the edit data is in a file in JSON format (also known as "dictionary" or "associative array" in other programming languages). The data for the first rung in the demo looks like this:
<pre>
{"matrixdata" : {"inputedit00" : {"value" : "noc", "addr" : ["X1"]},
"inputedit10" : {"value" : "noc", "addr" : ["X2"]},
"inputedit01" : {"value" : "brancht", "addr" : [""]},
"inputedit11" : {"value" : "branchr", "addr" : [""]},
"inputedit02" : {"value" : "ncc", "addr" : ["X3"]},
"inputedit03" : {"value" : "nocnd", "addr" : ["X4"]},
"inputedit04" : {"value" : "compgt", "addr" : ["DS100", "DS101"]},
"outputedit0" : {"value" : "out", "addr" : ["Y1"]},
"outputedit1" : {"value" : "set", "addr" : ["Y2"]},
"outputedit2" : {"value" : "rst", "addr" : ["Y3"]},
"outputedit3" : {"value" : "pd", "addr" : ["Y4"]},
},
"rungtype" : "single",
"comment" : "Click on the rung title bar to edit this rung."
},
</pre>
The names of the keys (e.g. "inputedit10" is an input for row 1, column 0) are the same as the names of the "cells" in the web page for the rung editor (the part that appears to edit a single rung). I will probably end up changing that so the data format isn't tied so closely to the page layout.

The data for each instruction is more nested JSON (e.g. {"value" : "noc", "addr" : ["X1"]}), where "value" indicates the type of instruction, and "addr" is a list of parameters (some instructions take multiple addresses or constants).

Outputs are relatively easy to handle, as they are just a one dimensional list. Inputs are more complicated because they exist in a 2 dimensional relationship with each other. So, a NO contact might really be equivalent to a STORE, and AND, or an OR, depending on where it sits in relationship to other instructions.

I've had a feature in MBLogic for quite some time where it will convert IL to SVG to display a ladder diagram on a static page. The SVG strings are created as part of the parsing process when it reads in the program (which is just a text file of IL). When you ask to view a page, it just assembles the individual rungs into a page and gives it to you.

The editor web page just wants a list of rung data similar to the example that I've shown above. The Javascript routines in the web page then take care of converting this into SVG (instead of in the soft logic server). That gives the rung editor data that it can understand.

Integration into the soft logic server involves changing the parsing logic so that it produces the format shown above instead of SVG. That should be straightforward to do. I think have to add new logic to reverse the process (this data format back to IL). It would be possible to just send raw IL text to the browser, but then that would be duplicating a lot of the parsing and compiling logic in two different places, with the potential for differences between them.

The same technique can be used to simply display ladder, or to display live ladder (on line monitoring). The browser could poll the soft logic server for changes or for the on line data. That allows for things like remote programming or multiple people editing the same program.

For the purposes of the demo, I'm just loading the subroutine data from a file (it's a Javascript file that linked to the page). When it is integrated into the complete system, it will be able to receive and send the data asynchronously in a manner similar to how the HMI system polls for data (except doing it on demand, rather than on a time based poll).

The concept can be adapted to other instruction sets, as most of it is not closely tied to the instruction set the I used. It's mainly a case of drawing different graphics for the instructions and changing the parameter editing forms.

 

I had discussed this possibility with the "Major" US PLC manufacturer 10 years ago, and there response was that this would disrupt there channels of income and increase per unit PLC. I believe they are missing the market personally.

A single unit with web based programming (logic) and web based graphics all on a single device, no polling, dongles, keys, update times, etc.

 

In reply to Anonymous: I've got live on line ladder monitoring working in MBLogic now and will probably release that soon. It turned out to be easier than I had thought it would be. The ladder editor however unfortunately still has a few bugs, so I won't be releasing it just yet. The idea does work however.

I think that most PLC vendors could implement web based on-line monitoring quite easily with only minor changes to their existing PLCs and programming software. The programming software could pre-generate the web pages (although I generate them dynamically) and download them to the PLC along with the program. AJAX communications between the PLC and the web page for update data would also be very easy and have low overhead.

It all uses very standard web techniques (Javascript and SVG) that have been around for a long time, so there is really no new technology to be developed here. Generating the web pages is not difficult either if you are already parsing the rungs (which their existing programming software already does anyway).

Quite frankly, I'm puzzled as to why PLC vendors are not already doing this. It may be that as you say they are simply afraid that even just web based live monitoring would cut into their sales of their programming packages (most maintenance personnel just want monitoring for troubleshooting). I think they're really missing the boat on this however.

 

I am a high school teacher and think your online program is really cool. Any chance you can add input symbols? NO PB, NC PB, Green Light, Red Light, Limit Switch, Prox Switch, Optics Switch? The reason??? I can use RX Linx or something else to generate a PLC ladder to show the kids on the Smart Board, but I have to draw the RELAY ladders out by hand, which just isn't as nice. Make sense?

Any help is appreciated.
Sean