PLC Programming Archive

J

Jerry Miille

It is very easy to use Adobe ACROBAT to make PDF files from any Windows based programming package. Almost everyone can view a .PDF file. This method
captures the graphics just as the original programs present them. ACROBAT readers are free from Adobe and the writers are not too expensive. The reader also integrates easily into most browsers and the .PDF files are compact.

I did a quick trial from my RSLogix package and will post it to my web site this evening and then post the URL here if you want to take a look.

Thanks,

Jerry Miille
Miille Applied Research Co.
http://www.miille.com
 
A

Anthony de la Rosa

how about sending the output of the ladder to acrobat -- I've done this with other documents and it really works very well. This way it will be pretty much platform independent. The acrobat reader web plug in will take care of the rest.

I'm going to go dig up my copy of acrobat and give it a shot and let you guys know how it turned out.

anthony
 
M

Michael Griffin

At 04:39 03/06/00 -0400, Bob Welker wrote:
<clip>
>... or maybe not wait 'til the weekend ... was tapping my toes waiting for a
>big PDF to download, so jumped in to see what could be done in 20 minutes or
>so.
>http://www.ccomm.com/~users/rawelk/techteach/plc/plc_code_snippet__test_page
>_.htm
>Drop in on this page. Actually, I was kind of suprised how easy it was to do
>something rough (which is all I'm capable of doing at this point;
<clip>
I had a look at it. I noticed that the sample rung was done as a '.GIF' image. This lets anyone look at it without having the software for
that PLC. This is important for several reasons.

1) I might want to use it for another PLC, but don't have the same software as you. Converting this example to work with say a Siemens S7-200 would be easy, provided I can at least *see* it.
2) It's nice to be able to browse through code samples without having to download programs and fire up the programming software. It's also
a lot faster if you just want to look around.
3) Some people may have the software at work, but want to read their e-mail and browse the PLC archive from home.

That example page you have shows how practical this idea is. As I look at it, I realise that it is also very nice to be able to look at the code and read the supplimentary documentation at the same time. The big question is though, how do we actually go about doing it? Whatever we do, it can't be something which involves too much administration work.

There have been some suggestions to manually construct ladder diagrams using ASCII characters. Now that I have thought about it a bit, I don't think that is a good idea after all. It is difficult and time consuming, except for the really simple examples, and it is too prone to
error. The actual print-out or screen shot of a piece of code from a working program is what we want.

jroop wrote:
<clip>
>Another suggestion would be to structure the archive
>database by PLC manufacturers ---> PLC Model ----> Full Code ---->
>Subroutines...etc.

I'm not sure this would be such a good idea. Why would you store it by PLC manufacturer? I would be looking for a piece of code for an
application, not something for a brand of PLC.
Perhaps some suggested classifications would be:

1) Hardware interfaces

1.1) Bar code reader interfaces
1.1.1) Sick 'CLVxxxxz' for an Omron 'wxyz'
1.1.2) Intermec 'abcd' for a Mitsubishi 'hjkl'
1.1.3) etc.

1.2) RF tag system interfaces
1.2.1) Balogh 'efgh' for an AB PLC-5
1.2.2) EMS 'zxcv' for an AB PLC-2
1.2.3) etc.

2) Mathematical Algorithms
2.1) Multiplication and Division
2.1.1) Integer division for PLC 'x'
2.1.2) etc.


3) Communications Drivers ...

I think you can get the idea. I think the classification system will have to expand and sub-divide as we go along. In practice, the amount of
subdivision required will depend upon the number of contributions made.

Some suggested major classifications might be (in no particular order:

1) Hardware interfaces - implementing the interface logic to get device 'a' to handshake with device 'b'. I expect a lot of special devices
to be listed here.
2) Communications drivers. These would be subroutines which implement simple standard serial interface protocols.
3) Mathematical algorithms. For example, how to do division on a PLC which doesn't do division.
4) Special closed loop control or other process or motion oriented algorithms. This shows what to do when the standard PID doesn't do the job.
5) Conversion routines. Converting data from one format to another. E.g., convert Grey code to natural binary. Convert integer to BCD.
6) Accessing features specific to particular PLC models. This would contain code which is only useful in accessing features of particular PLC models. Unlike the other areas, this one would be sub-divided by brand and model.
7) Application specific techniques. For example, under the 'Conveyors' heading there could be samples showing how to control Bosch
conveyor stop gates and transfers, or Flex-link stop gates, etc.

Does anybody have some good ideas of how to come up with a list of classifications?


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
What we need is an HTML printer driver.
Microsoft has an HTML printer driver which will allow you to print to an HTML file for uploading to the web. It is a WIN95 powertoy. Here is an excerpt of the readme file:

"This PowerToy is installed and used like a printer driver (see below) and allows some Windows applications to generate HTML files that
do not support a "Save As HTML" option. Text that would have been sent to a printer is intercepted and written to a file with an .htm extension. Embedded DIBs and bitmaps are converted to JPEG and written to .jpg files, with pointers embedded in the .htm file. The .htm file is then suitable for publishing on the World Wide Web and viewing by a variety of Web browers, including Microsoft Internet Explorer 1.0 and 2.0. The HTML Driver uses heuristics to
determine the intent of the application, such as alignment and columnar output. In some cases, it may be necessary to hand edit the HTML file to produce optimal output."

I couldn't find any updates to this though.


Jit Roop
Oceanside Technologies Ltd.
#140 - 8208 Swenson Way, Delta, BC
Tel: (604) 588-5450
Fax:(604) 588-5457
Email: [email protected]
http://www.otl.bc.ca
 
M

Michel A. Levesque, ing.

I've been following this thread and the idea is basically good. Here are my 2 cents worth:

I have my doubts about the various schemes proposed to view code. A basic question needs to be answered before a scheme can be put forward: Do the code programs/fragments need to be
implemented directly or do they just show methods and ideas (beware of the company lawyers).

If programs/fragments must be implemented directly, then native code is needed. If not, then direct ASCII printouts (use a generic
text printer in your OS and send it to a file). This will keep things easy for everyone (Dos, Windows, Linux, etc.)

If native code is needed, then I proposed to keep the original file intact. Not all functions of PLC's are universal. Take the "DDT" instruction in a PLC-5. For those not familiar with DDT (Diagnostic Detect):

"The DDT instruction compares bits in a source/input file with bits in a reference file and records the bit position of any mismatches in a result file. © 1997 Rockwell Software Inc."

Some other manufacturers may implement a similar instruction, but the actual implementation is not universal. We would have a problem of converting processor specific code. This is a very unsavory can of worms. Until a universal programming language comes out of the woodwork, we're stuck. Everybody will see that this could benefit the largest installed base platforms on the market. But, the way I see it is the largest installed base does not mean the largest code base...but hey, that's what competition is all about isn't it.

So, does the programming archive have to be implementable code or not?

Aside:
Concerning WEB plug-ins, Rockwell has RSLadder5 and 500 which are ActiveX utilities which allow you to browse a program (online even).

Michel A. Levesque eng., mcp
Directeur Bureau Montreal
AIA Inc.
[email protected]
 
J
What would everyone think if we incorporated a 'generic' ladder editor. Since using code from the library would typically involve re-addressing everything anyway, it is not that far from re-keying. This also eliminates some of the copyright issues. It makes all of the concepts available to everyone, cross-platform, and lastly,
makes maintainance less difficult.

--Joe Jansen
 
A

Anthony de la Rosa

I wonder if I can print to a file and view the output with a text editor. I should try that with RSLogix. Add a generic text printer and then redirect the output to a text file.


anthony

> > 1. How does one store the files?:- one config,source and
> > comment could be many files
>
> AB for example uses 1 file, unless you save it in the old format.
> Modicon & GE will hopefully get with the game and implement
> something similar. Typically, there is no need to have 20 or
> more files for a project
 
D
Guys,

I don't want to generally know how to create a programming idea. I want to learn how to make a certain function work for a specific PLC. How does a PID work with a specific module, how can I make a circular buffer in a SLC processor. General diagrams are great, but if I want to figure out how to do something in a specific platform it is not usually because I don't know how the logic is supposed to function, but rather how to make it work in this platform. What generic commands are available for this type PLC.
When I download a sample file to help me figure out how a function works, a general diagram doesn't help. I need to see how someone else
programmed it into a processor to make it work. The syntax is most times much more important to me than the idea.
Maybe we need an area for both. One for general function descriptions and one for specific functions, specific cards, specialty modules, etc.

Dale
 
G
I think this is a good way of doing it. Rockwell RSLogix5 and 500 can be printed directly to Acrobat distiller. This produces a document that looks exactly like you see on the screen. I would imagine that any other programming software that uses windows printers would be able to do the
same. I am not sure of legalities of this but I would volunteer to convert AB programs for people not having Acrobat Distiller who wanted to submit
things to the archive.

Geoff Lynn
BP/Amoco
Olds, Alberta
[email protected] or [email protected]
 
K
> Geoff Lynn [SMTP:[email protected]] said...
> I think this is a good way of doing it. Rockwell
>RSLogix5 and 500 can be printed directly to Acrobat distiller. [...]
>I would volunteer to convert AB programs for people not
>having Acrobat Distiller who wanted to submit things to
>the archive.

Great! The only drawback I can think of to using Acrobat Distiller is that it requires the purchase of a license to use, but if we get someone who already has Distiller volunteering for each brand of PLC software to do the
conversion, then it becomes practical.

Ken Crater
Control.com Inc.
[email protected]
 
M
> What would everyone think if we incorporated a 'generic' ladder
> editor. Since using code from the library would typically involve
> re-addressing everything anyway, it is not that far from re-keying.

This would be the best idea from the perspective of an end user looking to learn methods. The key thing is to make it easy for people to submit work to the archive, as this is often where archives fall over (everyone wants to download the answer, nobody wants to take the time converting the answer into a usable form). Also, transcribing a working solution to a generic format may introduce errors.

However, if you want the archive to be a useful resource then a generic ladder editor would be very good indeed. If it were open enough then in some cases it would be possible to write import/export routines to convert generic to/from real PLC code. Also, the act of transcribing to the real PLC code would encourage the user to
understand the code (and thus learn from it) rather than just using it to save spending time on it themselves. In addition, you don't need
your PLC programming terminal to be the same PC as you connect to the Internet with; you can view the code from anywhere, print it out, etc from whichever computer you are sat in front of. With the write programming effort, that computer could be a PC (Win, Linux) or Mac, or ...

So, if it can be made to work around the problems in the first paragraph, then it would be the perfect solution (imho). I had already
considered suggesting it, but had been wary of the "would you like to write it, then?" calls which might follow.

PS: Would you like to write it? :)

Mark
 
M

Michael Griffin

At 16:16 05/06/00 -0400, Jit Roop wrote:
<clip>
>What we need is an HTML printer driver.
>Microsoft has an HTML printer driver which will allow you to print to
>an HTML file for uploading to the web. It is a WIN95 powertoy.
<clip>
This definitely sounds interesting. One question about it thought is where it says "Embedded DIBs and bitmaps are converted to JPEG and written to .jpg files, with pointers embedded in the .htm file." I wonder if the ladder (or Grafcet or State chart) representation of a program will simply come out as a JPEG? If so, then this printer driver may not do much for us.
It sounds like a generally usefull thing to have though. I think I'd want one even if we can't use it for this purpose.
It would be nice to be able to browse the archive as a set of web pages though. You would click on a link which takes you to the general class of problem you are interested in. A web page comes up which lists brief descriptions of the contents. You click on the one you are interested in, and up comes a web page with the subroutine or code fragment for you to examine. If you would like to download the original source code, an option can be provided for that too. This type of organisation would be fast, simple, and intuitive.

Michel A. Levesque wrote:
<clip>
>If programs/fragments must be implemented directly, then native
>code is needed. If not, then direct ASCII printouts (use a generic
>text printer in your OS and send it to a file). This will keep things
>easy for everyone (Dos, Windows, Linux, etc.)

The problem with ASCII print outs, is that some of the newer software won't do one. The old DOS stuff is generally not a problem. Some of
the newer Windows software though is operating in a pure graphical mode.
As for manually created diagrams, I think we've all seen people include some in their Automation List postings which contain typographical mistakes. I would like to see actual print outs from programs running in real machines.

>If native code is needed, then I proposed to keep the original file
>intact. Not all functions of PLC's are universal. Take the "DDT"
>instruction in a PLC-5.
<clip>
>We would have a problem of
>converting processor specific code. This is a very unsavory can of
>worms. Until a universal programming language comes out of the
>woodwork, we're stuck.
<clip>
I think that what most people have in mind is not a "black box" library, but rather an archive of methods, algorithms, and principles.
People want to know things like "how do I convert grey code to natural binary?" (this was an actual topic of discussion a short while ago). If I were to post a code fragment written for an Omron C20K, you ought to be able to convert it to work on a PLC-5 without much trouble - provided you can
*see* it. It would be no good to you at all in native form if you don't have the software.
There will still be a place for processor dependent code. However, I suspect that code which is genuinely specific to one processor only will be in the minority. Algorithms which use an instruction special to one processor can still be generally useful provided that the function that
instruction performs can be emulated in some other fashion. I'm not too concerned about the fact that a PLC-5 timer instruction works differently from a Siemens S5 timer instruction - I can figure out those differences for
myself.
Furthermore, I may want to browse the archive just to see how other people write programs. Perhaps I can pick up a few ideas which I can use to improve my technique. I may also want to learn a few things about other brands of PLCs which I haven't used yet. Seeing some genuine program fragments can be very educational in that respect.

I believe that I once read somewhere that (refering to computer programs), if you want to learn to write good programs, you should examine
the work of good programmers. You should also welcome critisism as readily as praise for your own work. I hope that this PLC archive can serve those purposes as well as simply a store of knowledge.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
S

Simone Stefani

Hi all, Excellent!, i have many funny routines to share, in IEC 61131-3 format I believe that Rob is right!, some "soft-plc" product (like Twin Cat from beckoff) can load PLC program, developed in
IEC61131-3 format (i.e. from Siemens S7). IEC61131-3 seems to be the actual unique standard in PLC programming.

ciao......

Simone Stefani
Automation Dep.
Romaco Zanchetta
Tel. +39-(0)583-2171
Fax +39-(0)583-217317
e-mail: [email protected]
 
A

Anthony de la Rosa

my thoughts exactly, I think that acrobat is the best way to go. The only forseeable problem is the number of platforms that will be represented in the archive and the number of members on this list with a copy of acrobat. I'm an RSLogix5 and RSLogix500 enduser so anyone with snippets of RS code can send it to me for conversion to PDF format

anthony
 
R

Robert D. Wagner, P.E.

Hi List:

How about using Acrobat pdf format for code display. I have an Acrobat print driver that came with my scanner that works great. Basically anything that can be printed from Windows can be sent to a pdf file. Due to the widespread use of pdf files on the web for product data, manuals etc. for download, most users already have Acrobat Reader on their machines and if they don't they can download a copy for free. Comment and note files could also be put into pdf files to be located in a common directory with the code. With this approach you of course lose the
ability to download code directly to a processor. But is this a bad thing? I agree with a previous poster that the concept of solving a specific application problem should be the primary purpose of a code archive. A user needs to understand the specific capabilities (memory organization, available instructions
etc.) of the target processor before attempting to implement any example code.

Robert D. Wagner, P.E.
 
W
List,

You can download the Acrobat PDF Writer software from the Adobe site. They used to have the driver up there for Windows, but I see that they have
taken it down. They still have it up for NT. This allows printing to a PDF file from ANY windows program. I use mine daily for Win98, to publish
manuals, data sheets, even to send photos.

If you want to try it, here's the link:
http://www.adobe.com/support/downloads/acpwin.htm

I don't know why they took down the actual driver, maybe it was too good to be freeware.

Willy Smith
Numatico SA
Costa Rica
 
L

Leo Olshansky

I'm currently using Acrobat 4 Distiller as a printer for most of my RSLogix printouts. It works much better and faster then printing directly to a printer. After all, Acrbat allows me to print in reverse order, print range of pages, save program printout as a document for future references, etc., what RSI hasn't even dreamed of. Then RSLogix seems to be not very stable while printing to a printer. RSI blames Windows or network for that but it looks like Microsoft and RSI compete on who's software is less stable.
 
K
A generic ladder format might be feasible using XML, extensible markup language. "LadderML" documents would be plain text and platform independent, and could be transformed to and from other formats as needed. It might be a good choice for disseminating information via the web, given the very active development of systems to serve XML to browsers.

The set of "tags" to be used to define the elements of a ladder diagram would need to be defined and agreed upon, but there would be room for extensions and proprietary elements by use of namespaces, e.g., to accomodate an element peculiar to some specific PLC.

A simple, fictitious, and partial example:

&lt;ladder&gt;
&lt;rung&gt;
&lt;!-- latch alarm output --&gt; &lt;contact_open id="1001" description="enable" /&gt;
&lt;parallel&gt;
&lt;contact_open id="1002" description="alarm condition" /&gt;
&lt;series&gt;
&lt;contact_open id="0101" description="latching contact" /&gt;
&lt;contact_closed id="1003" description="reset button" /&gt;
&lt;/series&gt;
&lt;/parallel&gt;
&lt;coil id="0101" description="alarm relay" /&gt;
&lt;/rung&gt;
&lt;rung ... /&gt;
&lt;ladder&gt;

For consumption via the web, this could be transformed to a GIF or ASCII drawing (which I'll attempt even though ASCII art doesn't render well in many mail readers :)...

| 1001 1002 0101 |
+----| |----+----| |---------+----( )----+
| | | |
| | 0101 1003 |
| +----| |----|/|--+


--
Ken Irving
Trident Software
[email protected]
 
J
I agree. I found that from RSLogix 500, if I export to a library file (*.SLC) it puts it into a beautiful, human readable format. This
could easily be parsed into the LadderLibraryEditor 2000 (TM). Perhaps the LLE2K could also export back into this format for reading back into logix. I would challenge others out there that have other programming platforms to try to find a way to save the file into something easily parsed, preferably mnemonic codes....

I have volunteered to maintain the site, and I can try taking a stab at writing the code for the LLE2K, but it will be VisualBasic (yuck). I would prefer to find someone who maybe has a library of functions to draw the images on a windows platform, and we could find a group to write the parsers.

--Joe Jansen
 
B
> The big question is though, how do we actually go about doing it? Whatever
we do, it
> can't be something which involves too much administration work.
<clip>

Aye, Mike, there's the rub ... and it might prove difficult to constain the
administative work and yet have a lot of flexibility.

As to classifications, I think it would be very difficult to come to a
consensus, so perhaps the early evolution should have few rules, and see
which constructs are used most often based on the submissions, then firm up
the methodology. Would be fairly chaotic in the short term ...

One primary division might be generic vs. non-generic. It shouldn't be too tightly restrictive, else we'd end up with the divisions along manufacturer and specific PLC models for everything. For instance, most timer, counter,
FIFO, etc. implementations are slightly different between manufacturers (and sometimes within PLC families), but (unless a very specific function, like the PLC-5 DDT function related in Mike's message) is used, then I'd still consider the ladder code generic, and capable of easy transposition to a different PLC.

As a f'instance,

Generic
Motor Starter Control
Vanilla (1 NC PB, 1 NO PB, and a MS; no limit switches, et al)
Example 1
Generic online viewable file
I/O Listing
Downloadable files for x number of different PLCs
Commentary (this approach is used for such n' such reason)
Example 2
Generic online viewable file
I/O Listing
Downloadable files for x number of different PLCs
Commentary (this approach is used for such n' such a different reason)
Vanilla plus motor fault detection/alarming
Various examples ...

There are archetypes of control, so more complex code examples could link back to these more primitive examples, and say somethng like, "this is like the standard example xx motor starter control, but with this twist ..."

Dunno .. this structure could get out of hand.

The structure you outlined looks like it'll work as good or better than the above.

Still thinking ... this is tough stuff!
 
Top