opensource PLC projects in C...

s_viswesh

Member
Join Date
Oct 2002
Posts
13
Hi,

Actually I'm developing a complete ladder logic project, so that my hardware can execute ladder logic programs .
Any reference to open source projects for PLC development will be highly appreciated.

I also need to reference to document on : How a rung in a ladder logic is evaluated? How the entire program scan logic could be implemented in "C" code for my hardware. What datastructure should be used (ie the standard) for storing the ladder program in my hardware etc.

Regards
Viswesh
 
Puffin crossing, not Penguin crossing

You should talk to the folks at Control.com about the Puffin PLC project. http://www.puffinplc.org

They've got serveral man-years in creating such a beast. Frankly, I don't think its ready for prime-time yet, and may never be. While programming in C is fine, it will never take off until they get a GUI Ladder Logic interface, and out-of-the-box setup disks.
 
confusion

I have read this and the other post of yours relating to the design
of a PLC. I don't understand what you are trying to do?
Is this just some sort of hobby exercise or is this an
attempt to design a better mouse trap?
I hope that it is the former.
In order to design a better mouse trap you need to start by learning all you can about the market and your competition and that could take
considerable amount of time!
If you think that you are going to achieve that by asking
few simple questions in this forum, my advice to you would be
save your time and money, it's not going to happen.
I wish you good luck in this endeavor.
 
Hi,


Actually we have developed a motion controller with digital I/O s.
Actually it is used to control a pick & place robot which is to be
integrated to an automation line with its own set of sensors & actuators.
(conveyors, proximity switches etc.)
We need to provide some command list to user like MOVETO,AUTOHOME,
READ I/Os,IF-THEN etc. for programming. We want the user who wants to use my motion control
hardware to program it in PLC style
instead of writing a list of text commands like MOVE, SLEEP, WAIT, READ I/O, IF-THEN etc.


So what I ideally would want to do is:

1)Take an opensource PLC software with its GUI (Graphical User Interface).
2)Add a new set of function blocks related to motion control, in addition to standard
function blocks like contact, timers, counters etc.
(Standard Motion Control function blocks has been specified in PLCOpen.org (IEC61131-3))
(not sure about this exact IEC standard number)
3)Write code specific to my hardware, so that my hardware can interpret the
PLC program and execute the program.

So that an user who wants to use my motion control hardware can program it in PLC style
instead of writing a list of text commands like MOVE, SLEEP, WAIT, READ I/O, IF_THEN etc.

Question:
------------------
1) Is there a standard format for saving PLC files ( similar to DXF standard for
saving drawing files)?

2) Where can I find info about actual logic for executing a PLC program? i.e. Logic for
evaluating each rung ( bunch of OR, AND conditions). Say I have a rung of width 10 components
and say there are 8 such rungs, with possible interconnection between rungs (vertical shorts etc.).
Are the components evaluated in ROW-COLUMN order or COLUMN-ROW order etc. ?

(Please see my new post in the thread "Update/evaluation of internal relays/contacts" also)
regards
Viswesh
 
Where to begin.....?

OK. I get what you're trying to do.

The short answer is - it can't be done.

The long answer:
1) Is there a standard format for saving PLC files ( similar to DXF standard for
saving drawing files)?

There is no standard format. Allen-Bradley is the only one, that I'm aware of, that even imports from/exports into ASCII (which would be the basis of any "universal format".

Everyone's data structure is unique. Some have "unlimited" data registers. Others are fixed. Everyone handles timers differently: AB's which consists of a three-word element, GE's are three consecutive words, others allow you to assign the addresses. Some allow you to address the bits within a word, others don't.

It's a mess out there, and there's no standard.


2) Where can I find info about actual logic for executing a PLC program?

You can't. It's proprietary, closed, and protected. In theory, it's possible to hack it out. But I don't recommend it.


Are the components evaluated in ROW-COLUMN order or COLUMN-ROW order etc. ?

It depends on the brand. Most are row-by-row. Modicon is column-by-column. As I said, it's a mess out there.


So what I ideally would want to do is...[w]rite code specific to my hardware, so that my hardware can interpret the PLC program and execute the program.

I think you have a fundemental misunderstanding of what a PLC is and does. Although it IS a PC (sometimes even with an Intel x86 chip in it), it also ISN'T a PC.

You can't just download any old thing to one. It MUST be in the manufacturer's languange (not just on the IEC 61131-3 level, but on the assembly language level.

The PLC ONLY understands the instructiions in the manufacturers Instruction Set. Nothing else. Period. (Well, OK, years ago, AB had a program (called CAR) that might allow you to add to the instruction set of the PLC-5. I think about 6 units were sold.)

In figuring out what you are trying to do, I'm at a loss as to just where the "ladder-executing" program will reside. If you download it to your machine, how is the PLC going to get it's instructions to turn on motors, etc? If you are going to download it to the PLC, how does it communicate with your machine?

If you are trying to build a "PLC-like" interface to your machine, so that a programmer will use ladder logic rather than instruction lists, well..., OK..., but WHY? You'll be teaching any new programmer how to program your machine, regardless of the interface you create. Create the interface that makes the users life the easiest. If that's ladder, fine. If that's instruction list, fine. If you are doing sequencing, you might prefer Sequential Function Charts (also part of 61131-3). The thing about ladder is that it is intended to mimic relays. It helps to think of ladder as all the rungs executing "at the same time", and think of power flowing through the rungs.

If you are just trying to interface your machine with a PLC, then you need to understand commucation protocols. The OPC Foundation may be a good place to start.

But a PLC has a microprocessor. It sounds like your machine has a microprocessor. 2 microprocessors means 2 programs, with communication between them. It sounds like you are trying to write just one program.
 
Essentially it sounds like you want to emulate the operation of a PLC in code, but you haven't made it clear whether this code will be running on a desktop system or on some form of mpu based I/O board you've developed. In ether case you're faced with writing a ladder logic interpreter, plus an editor that may or may not run on the same computer. Once you have these 2 programs functional, you will still be faced with updating the status of the editor's rungs using info obtained from the running PLC interpreter. The PLC program will of course be scanning the user's program and updating the I/O while in the run mode. If you want online editing, then all the more work. No small task, but it can and has been done.

I've had to do basically the same thing in order to create PLC simulators for training purposes, and I can assure you it's no trivial task. The Ladder logic interpreter is actually the easy part of the equation, while the editor and status updating can be a major challenge, particularly if you get fancy and try to emulate something like the RSLogix editor. Many people believe PLC programs are compiled, which is typically only partly true. Of course your PLC interpreter will be compiled, but if you ever tried to recompile a program while it's executing; then you'd know why the user program is interpreted if you're going to offer on-line editing. The simplest approach is to have the editor send simple ascii representations of each rung to the PLC. (SOR,XIC,I:1/0,OTE,O:2/12,EOR" would get all the required info for a simple rung to the PLC and is fairly easy to decode particularly if you stick to common AB type instructions or similar: Start of Rung, Examine input closed at bit location I:1/0 etc etc.etc. Want a bit more speed; then pre convert the instructions into byte offsets that address indirectly to your code for the appropriate instruction. Lots of fun to be had here, but wait till you tackle the editor!

Once you've gone through this exercise, you'll no doubt have an an appreciation of why AB doesn't want to give their software away.

Best of luck!
 
WOW! There's been quite a few postings since I last read.

But, having put in the time to write this little novelette, I'm gonna post it, then do some more reading.

s_viswesh,

Let's look at it this way... There is a Master-CPU. You are his apprentice - a CPU-Wannabe, if you will. It's the Master-CPU's job to show you the "ropes" while he does his work. (As in all apprenticeships, he starts out slow and easy.)

As part of your training, he takes you into his work area and show you his "stuff".

He has a nice chair and a desk (and a cooler full of beer - don't touch it, you'll break it!). On the desk is a binder. The label on the binder says... PROGRAM. Next to the binder sits 3 sheets of paper and a pencil. The sheets are labeled, INPUT, INTERNAL BITS and OUTPUT.

Each sheet has a grid. Vertically, the grid extends from just under the label, at the top, to the bottom of the sheet. Horizontally, the grid extends from the left margin to the right margin. Along the left margin, from top to bottom, there is a sequence of numbers, from top to bottom, identifying each row in the grid.

"Now," he says to you, "do you see that sheet labeled INPUT? Do you see the numbers listed down the left side? Each number represents an Input. Each column is used to indicate the current state of each of the Inputs. If Input-1 is ON, then a "1" is placed in the first empty box across from "# 1". If Input-1 is OFF, then a "0" (Zero) is placed in the first empty box across from #1. The states of the Inputs are recorded, from top to bottom, one column at a time."

"The sheet labeled INTERNAL BITS is configured in the same manner as the INPUT sheet. Likewise, for the sheet labeled OUTPUT."

Pointing to the left, the Master-CPU says, "The Inputs are in that room, over there. See the sign, Inputs Room?" Pointing to the right, he says, "The Outputs are in that room, over there. See the sign, 'Outputs Room'? The Internal Bits, I keep right here, on this sheet labeled INTERNAL BITS."

Now, he says, "Notice that each box in the first column of each sheet contains "0" (Zero). This is because we haven't started yet."

"Now, I'm gonna sit in my chair and crack a cool-one, you can have a Gator-what-cha-ma-call-it."

"Are you ready to start learning? OK, let's go! Take that sheet, the one labeled INPUTS, and go into the Input Room and record the state of the Inputs. The first column is already filled, so fill in the next column. Then bring the sheet back to me."

The Master-CPU takes a nap. zzzzzzZZZZZZZ!

"So, you're finally back (Yawn!). Let me have that sheet."

"See that binder, the one labeled PROGRAM? That binder is loaded with a series of questions. I'm going to use the information on the sheet that you brought back, and the sheet labeled INTERNAL BITS, and the sheet labeled OUTPUTS to answer those questions."

So, the Master-CPU bends his back to the work. Flipping through the pages, referrig to the INTERNAL BITS sheet and OUTPUT sheet, and with sweat flying in all directions, the Master-CPU enters "1"'s or "0"'s into the second column of the INTERNAL BITS sheet and the OUTPUT sheet. After a few moments, the Master-CPU closes the binder, sits back in the chair, grabs at the cool-one, and takes a loooong swig. BUUURRRRPPPP!

He then hands the sheet labeled OUTPUT to the young apprentice, and says, "Here, take this. Go into the Output Room and set the Outputs to the states I've indicated. Then come back, 'cause you have to go look at the Inputs again."

So the Master-CPU sits back and cracks another cool-one.

And so it goes....

More, if anyone is interested.
 
OK, I've had a chance to scan the new posts.

The short answer is, "YES! It can be done! I have done so in the past."

As Bill indicated, it ain't easy. There is a tremendous amount of work associated with making a GPIOI (that is, a General Purpose Input / Output Interface).

This is an Interface which allows users to configure or re-configure logic as required. I did it on a PC-based system. It can also be done on a PLC-based system, but it requires a great deal of programming effort.

Essentially, you are asking for a level of programming that is even more simple, for the users, than "Ladder Logic" - something that users can handle.

It is generally the case, in cases of this sort, the simpler you make the interface for users (configuration-wise), the less capable the system becomes.

I have to pause and consider (remember) how I did it.
 
more details...

Hi,

Thanks for all the replies. Here is some more details about my system.
My hardware has a TMS320LF240X DSP, which in turn supports serial port & CAN communication
protocols.
Also I have a Master controller & then separate axis controllers for each axis.
The PLC program will be executed by the master controller.
So for motion commands, the Master will just issue commands over CAN to the axis controllers. The actual servo loop to execute motion is in the axis controller.
I plan to make internal flags like AXIS1_BUSY, AXIS2_BUSY, AXIS_AT_TARGET etc.
available to the PLC programmer so that he can use these flags in his program
to sequence the motion appropriately.


So I do need 3 softwares(say S/W:A1, S/W:A2, S/W:B):

S/W:A1: Sitting in the desktop. Ladder editor with Graphical user Interface.

S/W:A2: Sitting in the desktop. Converts the ladder program into a machinelanguage( some kind of bit pattern/data structure representing the PLC program)
that my hardware can understand. This software should also have communication (serial/CAN)
function calls to download the machine language file into my DSP's flash memory.

S/W:B : Sits in the DSP. Starts executing as soon as the DSP is powered up. Should read
the PLC program in m/c language form from the flash memory and start activating outputs,
timers, counters, servos etc. based on the PLC logic. My hardware has digital I/Os,
PWM, BLDC controller, stepper controller etc. all controlled by the DSP program.


"S/W:B" I will probably have to develop on my own. I should be able to adapt some existing
opensource project for S/W:A1 & S/W:A2 part I hope.




What are the main HARDWARE features of a PLC other than digital I/Os?
I can easily implement Internal relays, timers, counters, interrupts, watchdog timers etc. in the LF240X DSP.

Is there any special feature of a PLC hardware that is critical? which I may not be able to reproduce in this kind of DSP? Again my aim is not to build a robust PLC hardware.
My main aim here is to provide the user the option of programming in PLC style.

I have just started going through the IEC61131 standard. Any hints/reference about this
standard? Are there C/Java libraries which implement the function blocks given in this IEC standard?
Where can I get the complete documentation on this IEC61131 standard? In PLCOpen.org, only the table of contents is given. I'm not able to find the complete document yet.

Most of the robotic programming languages (VAL etc.) are
text based instructions. We decided to try the PLC ladder style programming based on the motion control function blocks specified in the PLCopen.org.

I hope I'm going in the right direction here.

regards
Viswesh
 
Viswesh,

Sounds like you have the hardware in place, plus a fairly clear idea of which direction to take, but I'd just like to point out what I consider the greatest pitfall with using ladder logic; at least from a developers perspective.

There's a good reason why robotic, or any common programming language utilize text based instructions. They are clear, concise, and easily created or edited with a simple text editor. Once the instructions have been created, they can easily be saved and retrieved, or send wherever just like a simple text file. Want to redisplay, print etc etc ....No problem! All-in-all, most people work well with text, but there were exceptions, particularly in the industrial segment.

It is widely known fact that electrical people like myself have great difficulty reading simple text, so companies such as AB decided to overcome this obstacle by utilizing pictures in place of text when they developed ladder logic. This started well before apple and then microsoft made GUI into a common term, but GUI does describe exactly what a modern ladder logic editor has become.

A user can easily insert as many "AND" "OR" statements as they want when writing code using a text editor, but imagine what "you" will have to go through to allow them to enter branching (OR) in a graphical environment. Drag&Drop is now expected, and of course any user will also expect to be able to move instructions from location to location or from rung to rung. What do you mean you can't add comments to the instructions; to the rungs or support output branching? This is definitely not a text editor you will be writing, even printing the program is a challenge!

Don't mean to discourage, and if you keep things basic and simple you may do all right, but the GUI editor is the toughest part of the job. Give it some thought.
 
Hi,

Is the source code for the Java PLC project described in the PuffinPLC.org website available online?
Such a nice description of the project is given, but I'm not able to locate the source code site even with a
google search? I located the "MAT Linux PLC" project though, but not the javaPLC project by Mark Hutton.
Any pointers?

regards
Viswesh
 
Hi,

I just got reply from Mark Hutton (project owner of the JavaPLC project) that the project never got started yet.
So there is no source code available.

The 2 PLC projects that I have identified so far are:
MATPLC (for Linux OS, in C) at mat.sourceforge.net or www.puffinplc.org

and

SIMPLC (in Java)(at http://www.stanford.edu/~mcammara/iface/reu/)

regards
Viswesh

To Mr.Allen Nelson:
It looks like the puffinPLC project for Linux does have a GUI (called classic ladder) in place.
 

Similar Topics

Hi, Actually I'm developing a complete ladder logic project, so that my hardware can execute ladder logic programs . Any reference to open source...
Replies
0
Views
3,850
ProcessViewBrowser http://pvbrowser.org is an OpenSource HMI, SCADA system. It runs on Linux/Unix, OpenVMS and Windows. You design your Masks with...
Replies
0
Views
2,779
Hello, I'm trying to delve a little into rs-485 communications for a couple projects of mine. Until now I've been using a delta vfd and a delta...
Replies
2
Views
35
Greetings All, I recently decided to start freelancing in Controls and Automation part time, most of my experience has been with Rockwell...
Replies
2
Views
84
I am having a problem communicating my PLC with Drive via Modbus connection. I start by opening the port and there is no problem, but then when I...
Replies
5
Views
50
Back
Top Bottom