Ladder Editor For Linux.

C
Hostile takeover :^) of a commercial PLC is certainly not the easiest way or the best. But it's probably the only way to change what I _have_ to work with. The PLC hardware thing is not that difficult, it's just registers on a bus and level translation and sometimes an A/D and D/A convertor. That is, it's not much different from any _old_ uP design where the I/O was off-chip. Until quite recently when they started doing ASICs, most of the chips were off the shelf items and how they work was no mystery. The packaging costs money because the tooling is only practical for reasonable volumes. But I digress......

Regards
cww
 
In reply to Curt Wuollet: I think you are jumping into the middle of the problem instead of starting at the beginning. Before you can worry about editing ladder, you need to be able to display ladder. Before you can display ladder, you need to be able to read in IL and parse it into elements that your editor can understand.

Lets start by assuming the following:

a) You have picked out a specific PLC.
b) That PLC has a fully specified IL format.
d) There is a one-to-one correspondence between the IL instructions and the ladder symbol representation.
d) We aren't going to worry about getting the program into the PLC.
e) We aren't going to worry at this stage about import and export to the OEM's file format. We are just reading the file in from a straight text file with one IL instruction per line.


If we break things up into stages, they would be something like this:

1) Read in the file and split it up into lines.

2) Go through the list of IL and analyse each instruction. Basically, we are doing most of the same work we would need to do if we were compiling it. Fortunately, IL syntax is normally very simple. That would work like this:

2a) The first symbol on the line is the instruction. Any symbols following it are parameters.

2b) Attempt to look up the instruction. Does it exist?

2c) Compare the parameters to the the definition the table. Do they match?

2d) Since the instruction names are sometimes overloaded, you might have more than one instruction with the same name and can only distinguish between them by the parameters.

2e) Add each parsed instruction to another list. In this list we store whatever information we may have figured out about the instruction in a form which lets use retrieve it more easily.

2f) While we are at it, we also break the program up into rungs and subroutines (so we have lists of lists).

3) Assuming everything is OK so far we can now display the ladder. Basically, you have a "matrix" of display references that you use to draw the rung on the screen. An "AND" moves your current position to the right. An "OR" moves your current position down and to the far left. A branch in the middle of the rung essentially starts a whole new rung which you have to knit back into the middle of the main rung (this can be recursive, as you can have a rung within a rung, etc.). I will pass over the details of this at present, but you might have questions about this later. This requires a series of heuristic rules, so this is dependent on the model of PLC you are using.

4) Some sequences of IL may not be able to be represented as ladder. In this case you need to default those rungs to IL.

5) Now you can add, delete, or replace instructions. As to how you get the mouse clicks, well there are different ways of doing this. You can draw the whole thing on a canvas and get the mouse clicks as X, Y coordinates (and then you figure out which contact this represents. Here is a reference as an example: http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html
You can do it as an array of custom buttons, and get the mouse clicks just like an ordinary button click. You can do it as an array of windows, with one window for each contact. The best way of doing it will depend on a lot of factors, including what programming language you are using and what sort of editing features you want to support.

6) You don't let the user add instructions anywhere they want. Rather you do something like this. If they are adding a contact to the right of the current position, then you are inserting an AND instruction. If they are adding a contact below the current position, they are adding an OR instruction. It can get more complex than this, but that is the basics.

7) Each time you change the rung, you redraw it.

8) At some point in the edit cycle you may need to re-parse the rung to validate it.

9) During this whole cycle you need to limit what the user can be done at each stage to avoid having to deal with their mistakes.

10) When you are done editing, you go back through the edit list and extract the instructions and parameters and make a new output file.
 
C
Whem they used OTS components, you could simply dump the ROM and disassemble the contents and you know what they are doing. Many current products use custom or semi custom silicon and the game gets much harder. This is to lower chip count and maybe to make the game harder :^).

Regards
cww
 
> I don't think you are getting what I'm doing. From the users perspective, it's a ladder editor, they neither have to know or care what the tool is coded in. That's the developers issue. It's a safe bet that both the current tools and the PLCs have been created with C or C++ in the mix, but they're not talking. So it's kind of a straw man. And the only group with enough pull on the rope to move the industry are the readers here and their peers.
>
> Here's what I want: You boot up your PC and click on the ladder editor and work like you always have. Only the PC is running Linux and the editor works for all your PLCs. And it's free. Wouldn't that be a good thing? <

Well, the good thing is that such a ladder editor is already there :)

What do you need is the possibility to generate code for a bunch of different target PLCs. And second, you have to communicate to all of these different target PLCs in order to upload the ladder application and to get all data for the debug session.

Do you believe that the PLC vendors would open up their proprietary design of their PLCs for you? I'm not convinced...

Best Regards
Armin Steinhoff
 
C
Hi Armin

> Do you believe that the PLC vendors would open up their proprietary design of their PLCs for you? I'm not convinced... <

No, probably not for me, but if a few important customers got together and wanted an end to the madness, the automation companies would even write it. But, it would still be better for the community to own it. There would be fewer shenanigans that way. And it would be hard for the automation companies to do. At the first sign of a defection, planeloads of MS marketing droids would show up. If that didn't stop it, there would be great difficulty in getting support from Redmond. So, any support from the manufacturers would be "leaks" or very low profile. Or maybe they just wouldn't threaten to sue you into oblivion. Look at Modbus.org, once GS did the right thing, the interest in Modbus increased exponentially. It is certainly far more likely to survive now, than if they had aggressively protected their IP. As I said before, the ones who want thousands for their tools are probably beyond hope. But the ones who give the tools away to sell PLCs are prime candidates for a vendor/community partnership. The companies with a good product and tiny market shares could increase their visibility immensely with very little expense or downside. It has to be a win/win, at least until the idea catches on.

Regards
cww
 
Hi Curt,

so what we need isn't an editor for ladder logic at first.

We need a *standard* for uploading of code and exchanging of debug
information with a target PLC system. And second, we have to define a target system which is able to execute the code and is able to support debugging.

If you like take the free C compiler "tcc" (http://www.bellard.org/tcc/) which allows compiling on the fly. Build an execution environment for uploading of the C code and for compiling the code with tcc and try to provide the debug information.

The existing editor for ladder logic supports the generation of C code. The remaining issue is the port of tcc to the different target hardware ... sounds easy but is hard to realize.

Best Regards
Armin Steinhoff
 
C
Hi Armin

I think I missed a tick here. What editor are you talking about? As far as the rest, I think we will need to match whatever the target PLC
does to download/upload code and update the dynamic display.

If we used C as the intermediate representation, we would need a converter to load the program from the PLC in whatever format they use and convert it to C. That is a possible approach, but I'm not sure how you would accommodate more than one PLC as the struct sizes, etc. would
change.

Regards
cww
 
Curt,

I'm not trying to be difficult, but what really is the point to having a free (as in speech) editor for ladder on a simple commercial PLC? As you have mentioned in the past the Click PLC is very inexpensive and has free (as in beer) downloadable software.

If you are thinking of trying to convince automation vendors that a GPL programming package will help their sales I think you are mistaken as to what the market really is for PLC software.

If you want to use a PLC for customers that require it, install windows in a virtual machine and use the free packages from Automation Direct. This really is your easiest path and I think it will be more welcomed by your potential customers. I think it will be a hard sell to tell a customer you are going to use something like an AD PLC but with custom GPL software that relies on reverse engineering. I know I would run away from that one in a second because of the long term support issues.

I do admit that this will not get you around the people wanting Rockwell and having to pay the many thousands of dollars to run their software. This *is* somewhat of a problem, especially for independents and small integration companies.

Am I missing something?

KEJR
 
In reply to M. Griffin regarding embedded hardware:

I always thought it would be cool to use a PLC rack with a custom Linux RTOS CPU for the form factor, wiring, etc. Besides the cool factor there is one instance where it is practical, however, and that is when data needs to be sampled in the sub-millisecond levels. More specifically I would guess that polling at anythign faster than 100 microseconds is sketchy even with isolated ethernet UDP transfers. I would love the opportunity to purchase a "slice IO" unit and do this kind of testing with Modbus UDP and Linux RTOS but so far I don't know of anyone who has done this specifically.

I do agree with you 100% though in that some embedded fanless "Box" computer with multiple ethernet ports *is* the way to go. Any open source effort probably should be in this direction as it is the most economical/flexible and should be the most supported in the future.

I will say that the HMI Panel PC could (should??) be the entire controller, or to use a VGA touch panel driven by the embedded box using shared memory to the RTOS threads.

~KEJR
 
K

Ken Emmons Jr.

Armin,

In response to Graphical vs. C/C++ text editing:

I think we are describing two different types of control. I mostly deal with sequential assembly automation, so in that sense my comments stem from that field. Most of the operations I deal with are either pneumatic cylinders with discrete on/off valves (with feedback) and triggering (and waiting on) motion control events (which are executed by a high end motion controller). Currently I use a lot of Ladder based sequencing (Mitsubishi Q series PLC), "C-like" programming (Epson robots), but have also dealt with SFC, Flowchart, and Delta Tau proprietary motion languages in the past. I think SFC and flowchart take up too much screen space and really is useless for detailed low level control. Most of the editors I've used hide all of the detail and only display a comment which makes it hard to tell what the underlying code is doing unless you click on every block, or spend most of your time maintaining comments.

Ladder:
Pros:
- Quick to do some latching and simple combinatorial logic.
- Can be made re-usable somewhat by using Function block calls.
Cons:
- To do sequential operations you have to force sequencing with "step numbers" or set/reset of next rung.
- Inserting items into a sequence often involves renumbering your sequence.

There are some tricks to making this all work out, and it is useable, but in the end it is just too overly complex to sequence things in ladder when in an RTOS/C/C++ environment a thread executes code sequentially *by default*. The ability to describe a sub-sequence in a function call (or object method if you wish) can really help you "divide and conquer".

For the text based RTOS your actual code can be very similar to this pseudocode:

- Turn on ejector
- Wait for ejector forward
- Trigger motion index
- Turn on loader
- wait for index complete

In addition these pseudocode "steps" when implemented as functions/methods can encapsulate a lot of functionality, such as the motion control trigger / wait including diagnostic code built in, as well as having timeouts and fault generation for waiting on the discrete IO, etc.

KEJR
 
In reply to Ken E: Typical PLC rack style hardware isn't up to sub-millisecond scan rates. The physical inputs and outputs are too slow, and the backplane is usually a bottleneck. On at least some popular PLCs (I have only researched this for a few) the backplane is actually much slower than the CPU network connection.

You also usually see that high speed I/O on a PLC is normally either limited to the I/O directly integrated into the CPU, or in a special high-speed card that has it's own CPU and program (or sometimes an FPGA). There is some fairly fast industrial digital I/O. However it all seems to be Ethernet based, not PLC rack based.

Advantech does have a "data acquisition rack" which looks like a PLC. They do have PLC-like CPUs that you can load your own software on. However, while the I/O capabilities are better than a normal PLC, it is barely into the range that you are talking about.

Once you start dealing with kHz data acquisition rates then you are out of the range of ordinary PLC hardware and into PC territory. You would want a data acquisition board, or else you would want to look at PC/104 hardware. It's not just the speed. It's also the signal conditioning and channel to channel skew. Data acquisition on a PC is usually done directly in hardware.

PLC applications can usually get away with ignoring a lot of problems simply because everything happens so slowly. At higher speeds though, the real world starts to intrude more and these issues can't be ignored. Just cranking the speeds up on conventional PLC I/O designs isn't going to work. The signal conditioning and wiring have to be just right and that's outside the experience of most PLC users.

As for TCP versus UDP speeds, well I recently tested a UDP based protocol that used similar principles to Modbus/TCP. Running on the same hardware (PC based), and transferring the same amount of data, Modbus/TCP was 4 or 5 times faster (average throughput) than the UDP based protocol.

Now, you can say that the difference is due to implementation details and that is probably true. However, that is also the point. UDP isn't a magic bullet and TCP can be pretty fast. The speed of networked I/O is going to depend more on the details of the hardware and software design than on whether it uses TCP or UDP.
 
C

curt wuollet

Hi Ken
> I'm not trying to be difficult, but what really is the point to having a free (as in speech) editor for ladder on a simple commercial PLC? As you have mentioned in the past the Click PLC is very inexpensive and has free (as in beer) downloadable software. <
>
No, it's a good question. There are a couple of points. First of all, to get tools running on Linux, which is a far better platform for these tools for a number of reasons. For instance, you could ship the tool installed on a version of Linux and keep that combination indefinitely, Contrast that with trying to support people loading your tool on the last 5 versions and who knows how many service packs with Windows. And having to rewrite every time Redmond needs revenue. Imagine how much easier it would be to support a consistent platform and control when it changes. A community supported tool would take care of itself to a large extent. And an independent, community supported tool is the only way you would _ever_ have a tool that would work across platforms. And Linux is going towards industrial and commercial works at the same time Windows is becoming far more multimedia and entertainment oriented. And getting even larger, with scads of features totally irrelevant to automation that can't be left out. Another reason is that _I_ would rather work with Linux than the mess that I generally get to work with. I would be at least 25% more productive and would need much less costly stuff.

> If you are thinking of trying to convince automation vendors that a GPL programming package will help their sales I think you are mistaken as to what the market really is for PLC software. <

I don't think the sales would change much. Their costs would improve dramatically if they took full advantage of an OS that they can control. They should be acutely aware of this after being dragged through Vista and a few other debacles that really had _no_ upside for them. This is for the big guys that would port their tools. The picture for the smaller outfits that give away their tools would be even better. Why write a tool if you don't have to.

> If you want to use a PLC for customers that require it, install windows in a virtual machine and use the free packages from Automation Direct. This really is your easiest path and I think it will be more welcomed by your potential customers. I think it will be a hard sell to tell a customer you are going to use something like an AD PLC but with custom GPL software that relies on reverse engineering. I know I would run away from that one in a second because of the long term support issues. <

Yes, I could pay more for a copy of Windows than for the whole click setup, for instance, and install it in an environment that will likely decrease it's dubious stability. But that's even harder to support than the current mess. That would be going the wrong direction. That current mess is the problem I'm trying to solve. It costs everyone involved a lot of time and money to chase after a platform that is outside their control and is not at all optimized for automation.

> I do admit that this will not get you around the people wanting Rockwell and having to pay the many thousands of dollars to run their software. This *is* somewhat of a problem, especially for independents and small integration companies. <

Imagine using rockwell without the big bucks and Windows issues, using the same tool you use for everyone else :^)

> Am I missing something? <

I think immersion tends to lull people into thinking that things have to be the way they are. Imagine for a moment how you would want them to be and compare that with what I am proposing. Being involved with computers was once the same sort of mess as automation is now, Action by the users has straightened things out a lot. Left to the manufacturers, it would still be ugly. But they can be winners too, if they try leaning towards the users side of things a little. Some grudgingly embraced the change, the rest are history.

Regards
cww
 
KEJR wrote:

> [ clip ]
>
> For the text based RTOS your actual code can be very similar to this pseudocode:
>
> - Turn on ejector
> - Wait for ejector forward
> - Trigger motion index
> - Turn on loader
> - wait for index complete
>
> In addition these pseudocode "steps" when implemented as functions/methods can encapsulate a lot of functionality, such as the motion control trigger / wait including diagnostic code built in, as well as having timeouts and fault generation for waiting on the discrete IO, etc. <

IMHO ... our concepts are not very different. We use more or less the same modular approach, but we do an additional step to encapsulate these function/methods (or APIs) into graphical function blocks. This hides a lot of syntactical problems of textual languages. You can consider our function block display as a graphical abstraction layer supporting transparently threads and multi-core CPUs. Even recursive calls of function block routines are possible...

Best Regards
Armin Steinhoff
 
In reply to Armin Steinhoff:

Do you have examples/screenshots of function block code running a detailed sequence?

KEJR
 
In reply to M. Griffin:

I'm not talking about typical PLC racks I suppose. Currently I use a lot of Mitsubishi Q series backplanes with their higher speed input cards. They are not co-processor cards or interrupt cards, but simply Input cards that have a settable digital filter that goes as fast as 100 microseconds on the hardware filter. My typical scan speeds are on the order of 600-700 microseconds (which includes rack IO reading), so we are getting real savings out of the faster inputs. I use this as a default and have not had any problems. Proper 24V signal thresholds and decently conceived wire runs help you out a lot here because the noise amplitude that you can get away with.

Like I mentioned before, I do agree with you that standard Linux box with commercial (or public domain) field IO is probably the way to go. I'll keep an open mind to test with Modbus/TCP if the opportunity arises.

Thanks,
KEJR
 
In reply to Curt Wuollet: You said "Imagine using rockwell without the big bucks". Do you know if it is feasible to do this however? Forget about how to edit ladder on the screen for now. The question is do you know how to compile and download a single rung of ladder into a modern AB PLC and get it to run? A simple command line program would be good enough to demonstrate that.
 
In response to Armin Steinhoff:

I just don't see that type of SFC programming being easier to write than text programming using a system such as I described earlier. I've done it both ways and am at least 5 times faster with a structured programming language and RTOS. Maybe we'll just have to say it's a matter of preference.

~KEJR
 
C

curt wuollet

Hi Michael

No, I don't know if it's feasible yet. That would require owning or at least borrowing the equipment and software to RE the process. Then there's the difference between possible and feasible. I'm certain it is possible, feasible depends on how bad you want it :^) That is, in my current circumstances, it is not feasible to work on that part. Given the choice between eating and buying automation gear, it's going to be a while before I can start on that. But with the generosity of the FOSS community, I can write and test code for the machine independent part. I might be able to finagle a Click environment, but the ROI on that isn't very high as it's a singleton. Better would be the older AD line. And a brick with a bad output, for example, would be feasible if it can be found. Or for that matter, even a worn Micrologix if they still offer the 10 point demo version of RS Logix. And I'd have to dredge up Windows someplace to run it. But, one of the things I'm trying to assess is the _interest_ in such an undertaking as I would never accomplish it alone. Donations from your pile of dead, but programmable gear will be accepted :^) If I had known....

Regards
cww
 
D

Dave Ferguson

So I just read the Control Engineering magazine annual awards. Not one category of a non Windows product was listed. Apparently Windows based packages are ok for the masses.

What is the market share for Linux supported Pc sales......minimal
Percentage. Industrial Pc sales with Linux even smaller.

I will NEVER get a large client to deviate from an unproven, unbacked control system.......period.

Can we please move on from this now 13 year old debate with no change in outcome. My employer and almost every one I have contact with has enough trouble supporting the softwares they have on the defacto standard OS, without trying to run on multiple flavors of "everyone will help you" software.

I will stick to me "Best in class" Rockwell ladder software and it's price. I make money writing code and so should they.

I suppose that this same argument holds that music artists or any artists for that matter should give their work away for nothing. The plumber should not charge me and I should give him free tools so he can do it for me. And the car dealer should give his computer diagnostic machines away for free. Shouldn't the DCS manufacturers give away their software for free also and put it on free OS and free hardware.

Bottom line, I do not want free ladder editors because then someone will want free machine code. The market has spoken, over and over and over.

Cmon let's move on already......

Dave Ferguson
Control Systems Engineer

Sent from my iPhone
 
Top