Does anyone know of any PLC (Ladder Logic) program archives on the Net?
I am always looking for new ways of solving old problems, Better tuning of PID loops, More efficent program control, different ways of machine control.
If there's a need for an archive of PLC programming solutions we'd be glad to provide the site for one (subject to pertinent disclaimers <grin>). Any interest? Any contributors?
Ken Crater, President
I could always find some usefull code lying around (if there aren't any copyright isues <GRIN>).
I hope that others would also help. I can't believe that it hasn't been done yet!
I think it's a good idea, and I'd be willing to put some time into it (if only because there ISN'T anything like that out there so far as I've seen), but what format? Deciphering symbols done in straight ASCII (i.e. - |/|, |Tmr|, etc.) turns to gobbeldygook for more than a line or so, and so far as I know there isn't a 'standard' cobbled together ASCII notation in force.
Could do it using a boolean notation, but that would leave out the folks unfamiliar with this format, and again, whose convention to use for
branching commands, timers, and the like (GE, A-B, Omron, etc.)?
It would be interesting to do some of the 'classics' in Rosetta Stone fashion. One of the best MS-DOS computer programming manuals I have (or had, can't find it now that I want the title) explained various bread n' butter tasks like disk I/O, etc. using assembler (direct to the hardware, and through BIOS calls), and using BASIC. This cleared up a lot of questions.
Maybe the PLC equivalent would be to have the 'standards' (say, a motor starter control) shown in a half dozen or so PLC manufacturer's ladder and boolean (where applicable) representations, IEC structured format, etc.
Why not store it in original format so it can be directly used by the software for the particular type of machine? It would make the
archive larger, but easier to use. Notation from one type controller can not usually be imported directly from different manufacturers or even different platforms from the same manufacturers. Most PLCs have the ability to save portions of the program as files to be used in other projects anyway, just use the native file types.
That would certainly make submissions easier, and would be a necessary adjunct of any scheme, but (until the ladder logic programs start to support some manner of 'export to HTML' ) would make it impossible to see the contribution online.
What I see is a viewable HTML page showing familiar, pictographic ladder logic, an I/O table showing the devices, etc. a synopsis of what the code does, a link to a more detailed analysis/commentary if warranted, and ftp links to download the code in one or more native PLC formats.
Maybe if I get time over the weekend I'll play around with RSL500, and see if I can't cobble together a demo page on my home page, and then list the URL here for comments.
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.
... 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.
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; need to learn how to get around various scripting languages, Java, et al), but still almost worthwhile.
At 04:39 03/06/00 -0400, Bob Welker wrote:
>... 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
>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;
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.
>Another suggestion would be to structure the archive
>database by PLC manufacturers ---> PLC Model ----> Full Code ---->
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.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
2) Mathematical Algorithms
2.1) Multiplication and Division
2.1.1) Integer division for PLC 'x'
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?
London, Ont. Canada
> 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.
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,
Motor Starter Control
Vanilla (1 NC PB, 1 NO PB, and a MS; no limit switches, et al)
Generic online viewable file
Downloadable files for x number of different PLCs
Commentary (this approach is used for such n' such reason)
Generic online viewable file
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!
At 02:56 08/06/00 -0400, Bob Welker wrote:
>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
If things can be organised with links along the lines of web pages, then we might be able to have it both ways. Each sample could be linked to several different master pages.
For example, submission 'x' might be a demonstration of how to control a Bosch vertical pallet transfer unit using a Siemens S7-224 PLC. It could be linked to three separate pages for "conveyor", "Siemens", and "Bosch".
If we have a list of current categories, then when someone submits a sample, they could suggest which categories it should link to, together with a suitable title and summary.
I don't expect things will be perfectly organised, so we should provide a means of allowing people to easily browse around in various ways while they look for something. This will also let us just look around when we are not really sure what we are looking for.
London, Ont. Canada
The more I play with this thing, the better it sounds to use Acrobat, and/or a combination of this, and the 'generic' editor concept.
Learned a couple of things about RSL (at least, true to the version I'm using - v2.57 ... things may have changed) that make we less than happy.
1. When I selected multiple rungs I'm able to paste them only as unformatted text (for the boolean listing). 2. If I copy single rungs then they can be 'paste special' into Word (to get the GIF) which is then pasted into the HTML editor (Frontpage, in this case).
This makes for tedious effort to put together a page, what with a GIF file for each ladder rung, and a ton of back n' forth ... not too bad
for small snippets, but would be a killer for doing an actual application-sized ladder program.
Went looking for the HTML print driver mentioned here, and came up dry ... saw references to it at a dozen or so pages the search engines hit on, but no download links (and MS Powertoys for 95
doesn't list it as part of that collection).
Would be willing to try it if I can get hold of a copy.
In any event, I'm going to do a dozen or so 'snippet' things using the above technique as an experiment, and to be used where I work as part of a PLC mini-seminar.
I've linked these 'new and improved' experimental pages to
The look and feel is kind of icky yet ... but it's coming along.
The problem with generic program archive is that alot of what we want to see is how someone tackled this problem with aother PLC. example:
With AB SLC on a PID loop. It is good practice to:
Scale PV eng unit to 0-16383
Scale SP eng unit to 0-16383
Clamp both so out of range doesn't crash PID loop.
Enable bits Off/Manual/Auto Modes
Copy raw output to sp for Bumpless Transfer
Scale Output 0-100% Float for display purposes
Scale Output X to Y to go to I/O card for output.
Modicon Concept has it's own issues with setting up PID loops, as well as Mitsubishi FX. Each one has tricks and techniques which experience brings. This is the type of info which the list members are problaby looking for.
VP Controls & Automation
92 Montvale Ave
Stoneham MA 01890
e-mail to pager: firstname.lastname@example.org (short messages only)
Sounds like a good idea. I would be willing to contribute some subroutines I have written and found useful. I have a few suggestions though.
1) Contributions can be complete programs, or individual subroutines or code fragments. Small subroutines or code fragments will probably in most cases be more useful than entire programs. Complete programs can sometimes
be useful though in order to illustrate an overall method of organisation, or to show the context in which certain subroutines are used.
2) The contributor should be the author of the code. No sample should be accepted unless the contributor is willing to state that he wrote it.
3) There should be some way of associating additional documentation
or explanations with the program.
4) Submissions should include a descriptive title and a brief summary explanation which would be used by someone else to search or browse for something.
5) It would be nice to have some way of displaying a "print-out" form of the program, so that it can be viewed without using the intended
programming software. This would be especially useful if you find a sample which does something you need, but need to translate it to a different brand of PLC before you can use it. Some programming packages support a "print to disk" function which can be turned into a simple ASCII file which can be viewed directly. In other cases, you might need to use something like
"Ghostscript". Small subroutines or code fragments might perhaps be sent in scanned as JPEGs if no other means is available.
6) It would be nice to have some way of allowing people to add their comments or reviews in some fashion (as in "tried it and it worked great", or "won't work properly because of ...").
7) Some sort of download counters would be nice for each sample. This would let people easily see which ones were the most popular. This
might be a crude indicator of quality, especially if used with item #6 mentioned above.
8) Some general guide lines for submissions should be issued before the archive is activated. Some sort of classification scheme should also be instituted (e.g. "bar code reader interface subroutines", etc.).
9) Programs of other types than just PLCs should also be accepted (servo drives, MMI panels, etc.).
10) The archive should have a summary on the entry screen showing when it was last updated so someone can see if anything new has come in
since the last time they looked.
11) Each entry should be date stamped with the submission date.
London, Ont. Canada
Sounds like a webmaster to me! Are you volunteering?
All of your suggestions sound great but would require a full time person(s) to accomplish such a task.
I personally would like to see "concepts", not necessarily full Ladder Programs. I think that there would be less of an issue about Copyrights if concepts, code 'snippets', or ideas were submitted vice fully working progams. But I'm an engineer, not a lawyer (thank God!)
I personally don't like the idea of submitting code for specific PLC platforms. I currently program with 3 different PLC manufactures with multiple platforms. But I can see someone submitting the exact code that I looking for, for a platform that I don't have software for, or the currect version of software. That would create a ton of messages, "Can some convert XYZ to ABC?"
Anyone have a program that could display some form of texted based Ladder? I have seen examples in books and documentation in 'text' form.
I suppose I had better get back to "The 'Ol Salt Mines."
Electrcial Design Engineer
At 15:01 01/06/00 -0400, Chuck Meyers wrote:
>All of your suggestions sound great but would require a full time
>person(s) to accomplish such a task.
No, I don't believe it will. I think most of the suggestions were made with keeping administration to a minimum. The big question is whether some of the "nice" things like "down load counters" can be implemented easily and cheaply.
Perhaps the e-mail archive system could be used somehow, with new topics used to classify the submissions.
>I personally would like to see "concepts", not necessarily full
>Ladder Programs. I think that there would be less of an issue
>about Copyrights if concepts, code 'snippets', or ideas were
>submitted vice fully working programs. But I'm an engineer, not a
>lawyer (thank God!)
I think that subroutines or code fragments would be what most people would be looking for. The exception would be if they wanted to see how an entire system went together. That is, someone had a complete "system" or
"method" they used, and needed an entire program to illustrate it.
As for copyright issues, even if that were not a concern, some people might be upset to see someone else submit their work.
>I personally don't like the idea of submitting code for specific PLC
>platforms. I currently program with 3 different PLC manufactures
>with multiple platforms. But I can see someone submitting the
>exact code that I looking for, for a platform that I don't have
>software for, or the currect version of software. That would create a
>ton of messages, "Can some convert XYZ to ABC?"
I scanned various ladder format subroutines and code fragments into JPEG files to illustrate examples in a programming guidelines document recently. These subroutines and code fragments varied from 12k to 90k in JPEG format. I didn't spend a lot of time trying to minimise the file size, but they were still fairly compact.
Something that was in instruction list format could of course be a simple ASCII file. I agree though that we should encourage people to send stuff in universally accessable formats. Some stuff could be constructed manually as ASCII characters - this isn't always easy though (we've seen examples on this list).
I don't suppose though that anyone has heard of web browser plug ins to view PLC programs though?
London, Ont. Canada
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.
> 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? :-)
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.
I have not been following this thread, but for a while, PLC-Open was working on using the STEP Language for exchanging programming between IEC 1131-3 implementations. (Please no flames on
procedural vs. object vs. state languages).
According to me re-collection STEP enable an 80% - 85% portability.
William F. Hullsiek
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:
<!-- latch alarm output --> <contact_open id="1001" description="enable" />
<contact_open id="1002" description="alarm condition" />
<contact_open id="0101" description="latching contact" />
<contact_closed id="1003" description="reset button" />
<coil id="0101" description="alarm relay" />
<rung ... />
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 |
| +----| |----|/|--+
I would suggest that this project should be coordinated with LinuxPLC project - they will have to tackle programming in ladder diagram and "'generic' ladder editor" looks to me like a missing piece of puzzle for both areas.
Have you never heard about softCONTROL from SoftIng ???? Is a IEC61131-3 programming system for controller producers, it can be connected to almost every controller platform. Could be the
common platform where developing PLC application. Surf on www.softing.com
Keep in mind that must be represented the "advanced instruction" too, like pointers, structured item etc.
So I looked at softing. This is not a programming package. It is a PC based control. It can connect to many controller platforms, but
not as a programmer, but as a data acquisition station.
This is along the same thread as the 'neutral programmer' idea. I still prefer the .PDF files.
Why not put the codes in STL and make the life easy. I think all the PLC programmers can translate STL to Ladder or CSF. I agree that
the STL syntex in different platform is slightly different but can be understood easily. The codes can also be made platform independent like (If I write Joe's example in a platform independent
> | 1001 1002 0101 |
> +----| |----+----| |---------+----( )----+
> | | | |
> | | 0101 1003 |
> | +----| |----|/|--+
AND NOT I1003
Say this statement list is equivalent to the above ladder.
Phone: +9221-636 5519
Fax: +9221-568 2972
At 03:55 PM 6/8/00 -0400, Tanweer Ahmed wrote:
>Why not put the codes in STL and make the life easy.
Tanweer and List,
While this approach has some merit, there are some problems:
1) PLCs don't all use such a language, and may execute a ladder diagram differently from the IL representation.
2) Ladder Logic is appealing to some people because it is NOT text-based. More information is transmitted more quickly by a diagram than a listing of code.
3) There is some value in having the *original* code shown in its syntax, as the code then does not claim to be more than it is. "This code has been running on a Nacho PLC-1000 since 1993", followed by the printout (or PDF).
4) Complex functions or function blocks make #1 and #3 worse. Contacts and coils are one thing, even timers are not standardized among all PLC
As far as generating PDF files goes, I found a third party PDF printer driver for 50 bucks on the web. Here is the site:
You can download a sample version and try it.
Numatico, S. A.
San Antonio de Belén
If there were to be such a beast that would be as good a way as any for creating the online viewable example.
Any native code for implementations for various processors could be referenced to download links (and when multiple files are needed, then a .ZIP archive would be created to hold them).
Excellent suggestions from Michael Griffin, I would contribute to such an archive as well. Another suggestion would be to structure the archive database by PLC manufacturers ---> PLC Model ----> Full Code ----> Subroutines...etc.
I think this is a good idea. I have created some common code that I use for certain functions for our company. I think if anyone wants to share this type of code that it would be great to be able to find reusable code on the web. Tell us where to stick it! hahah
How can we do it, so that everyone without the programming software can view the code?
I know that I have some sample programs when I first started PLC programming, just to learn how each instruction worked.
It would be nice to see a tutorial section, which includes plc instructions from various manufacturers.
I got a few questions/suggestions (some may have been asked before)
1. How does one store the files?:- one config,source and comment could be many files
2. How could one look at the code? if you don't have the programming s/w. (May the app is on AB and I want to Modicon)
3. Why not standardise on IEC 61131-3 format?. (look at http://www.plcopen.org for compliance etc.)
Then (in theory) any IEC compliant s/w can be look at by any other IEC package.
4. When exported to text, the IEC code can be looked at in notepad. (one file, but difficult to read)
5. Else you could goto http://www.modicon.com/ConceptDemo/index.html to
get a demo package that could view and import the ascii IEC text file.
6. Saving this file in the arcive would then imply "open" by default
> 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.
> 2. How could one look at the code? if you don't have the
> programming s/w.
> (May the app
> is on AB and I want to Modicon)
Still beneficial to us that have most of the programming packages.
Since we are talking mainly about sample routines or snivets of code, why not just do a screen capture and save/display in a graphic format...bitmap, WMF, GIF, etc. This would provide enough insight into what the original
author had intended to show.
As far as compatibility between different manufacturers.....who cares, enter the logic as shown or modify it slightly to the platform you want to run it on. There really isn't that much difference. The whole point is to provide a working example or solution to some problem.
Personally, I think this is a great idea.
ZTR Control Systems
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?
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
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.
At 16:16 05/06/00 -0400, Jit Roop wrote:
>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.
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:
>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.
>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.
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
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.
London, Ont. Canada
I would propose the following based on minimizing administration on the web site end, ease of use by users, and ease of submission.
Files are submitted to archive site in native formats supported by Web Master.
Documentation is submitted as a *.doc or *.txt format
The web master converts supported file formats to *.pdf format
It is the responsibility of submitters to provide *.pdf files of unsupported file formats
A simple questionnaire should be filled out by the submitter stating what processor, software version, equipment interfaced, etc. for use in sorting by users.
The web master would provide the *.pdf, native files, and any documentation for download by users.
Code could be sorted by the categories on the submittal questionnaire or by date.
This method keeps the submission process simple to maximize the number of submissions, keeps the administration process simple to be practical, and allows users as much usefulness as the submitter is willing to provide.
What do you think?
C. Thomas Wiesen
At 01:19 08/06/00 -0500, C. Thomas Wiesen wrote:
>I would propose the following based on minimizing administration on the
>Files are submitted to archive site in native formats supported by Web Master.
>Documentation is submitted as a *.doc or *.txt format
>The web master converts supported file formats to *.pdf format
I think perhaps we are putting the cart before the horse here. This file format makes an assumption of how we want the archive to appear to the user which I don't believe has been established yet.
Do we want the site to consist of:
1) A series of headings with download links to various files (click on the link to download a file and view it off line), or
2) A collection of linked web pages which show code samples and documentation directly, or
3) A combination of '1' and '2' ('1' for larger programs or samples, '2' for smaller ones).
Secondly, I believe that files should be submitted to the administrator directly in a form he can publish. There should be no requirement for him to prepare anything from original PLC (or other) files.
>It is the responsibility of submitters to provide *.pdf files of
>unsupported file formats
PDF is nice, but I don't have anything which can save or print to PDF format, and I don't believe we should require people to have to buy this. I am not aware of any PDF converters which are genuinely free. While the cost of this extra software probably wouldn't hurt me, I am sure that there are other people who don't have as much free cash to spend but certainly have ideas to contribute which are just as useful as mine.
I believe we should establish a method which allows someone to submit a universal format, but which doesn't require any software not
available for free or at low cost (other than whatever PLC software they may use to create the program in the first place).
I have used the following methods:
1) ASCII print to file (older DOS software only). Cost - zero if the software supports it.
2) Print to disk as a postscript file, then use 'Ghostscript' (a software package I downloaded off the internet) to convert to JPEG. Cost - ???? (I'm not sure if Ghostscript is intended to be free after the evaluation period, and I didn't pursue it further after I tried this out).
3) Print to paper, and then scan it in as a JPEG. Cost less than $100 for a scanner (nothing in my case, since I already had one).
4) Cut and paste between windows and save as a JPEG. This can be very difficult and tedious if the entire image you wish to show does not fit
on one screen.
Options 2, 3, 4 assume you are using Windows (or perhaps Linux).
>A simple questionnaire should be filled out by the submitter stating what
>processor, software version, equipment interfaced, etc. for use in sorting
Yes this needs to be done. Also include author, date originally written, number of applications it has been used in, and a suggested list of subjects it should link to. If it was derived from another source (e.g. it is a re-write of an existing program from the archive), then that original source should be cited.
"Tanweer Ahmed" wrote:
>Why not put the codes in STL and make the life easy. I think all the
>PLC programmers can translate STL to Ladder or CSF. I agree that
>the STL syntex in different platform is slightly different but can be
I don't think this is a good idea because:
1) Not every PLC supports STL,
2) The program may not *be* for a PLC - it might be for something else entirely, (e.g. a bar code reader, or an MMI panel),
3) The whole point of the particular submission may be to illustrate how to accomplish something using state charts or sequential function charts.
Submitting it as STL (if this is even possible) may defeat the whole purpose.
I believe that submissions should whenever possible be direct print-outs or reports or screen images from actual working programs from
real machines. Samples that 'ought to work', but have never actually been tested in their current form would not have as much credibility. This is why I am not sure that the 'universal ladder editor' which has been suggested by several sources would necessarily be useful.
London, Ont. Canada
> PDF is nice, but I don't have anything which can save or print to
>PDF format, and I don't believe we should require people to have to buy
>this. I am not aware of any PDF converters which are genuinely free. While
>the cost of this extra software probably wouldn't hurt me, I am sure that
>there are other people who don't have as much free cash to spend but
>certainly have ideas to contribute which are just as useful as mine.
True, but most people can print postscript (e.g. postscript driver for HP laserjet printer) to file. This creates anyname.prn postscript file, which can be send (e-mailed) to single "conversion point", preferably to administrator directly. He can run anyname.prn file through "Acrobat Distiller" and convert to anyname.pdf. Conversion is very simple (automatic and in batch mode) and quite robust (more reliable than printing to pdf itself).
Ghostscript has the ability, using the 'PDFWrite' printer, to create pdf's from postscript files.
This is how I deliver my ladders to people without software.
Actually, to really get the cart up front, we should ask what we expect to get from this.
Here's my wish list.
1) Basic logic for the students/initiates.
- simple faults
- simple motor/valve/light/etc. control
- basic PIDs
2) Examples of what not to do.
- scan dependant examples
- horror stories
3) Funky stuff
- message/bar code handling routines.
- advanced control (not patentable stuff)
- PLC peculiar logic like network or module health, etc.
- ways and reasons for I/O map arrangements for
- high speed operation issues.
- performance enhancements.
- patches, DLL's, scripts and workarounds.
- logic to help electricians.
This doesn't necessarily have to be a repository
of logic and code. English pseudo code and
mathematical equations are just as useful.
Perhaps we could look back at the list archive
and come-up with a list of past and present hot
topics. Maybe this could a compendium of the
actual list discussions with related notes.
Anthony Kerstens P.Eng.
> - patches, DLL's, scripts and workarounds.
> - logic to help electricians
Maybe someone knows how A-B, GE, et al. feels about linking into their sites? Not that this would necessarly be a good idea (a lot of these links probably get changed constantly, and hence increase rather than decrease overhead) but if not, might be useful for referencing the patches, DLLs, white papers, etc.
> This doesn't necessarily have to be a repository
> of logic and code. English pseudo code and
> mathematical equations are just as useful.
This is what makes me think that HTML makes the most flexible 'wrapper', per se. Fairly easy to evolve, and (depending on how automated the submission process gets) something like the way eBay gets embedded picture links from users might be considered for the 'non-standard' links.
> Anthony Kerstens P.Eng.
-> At 01:19 08/06/00 -0500, C. Thomas Wiesen wrote:
-> >I would propose the following based on minimizing
-> administration on the
-> >Files are submitted to archive site in native formats
-> supported by Web Master.
-> >Documentation is submitted as a *.doc or *.txt format
-> >The web master converts supported file formats to *.pdf format
-> I think perhaps we are putting the cart before the
-> horse here. This
-> file format makes an assumption of how we want the archive
-> to appear to the
-> user which I don't believe has been established yet.
-> Do we want the site to consist of:
-> 1) A series of headings with download links to
-> various files (click
-> on the link to download a file and view it off line), or
-> 2) A collection of linked web pages which show code
-> samples and
-> documentation directly, or
-> 3) A combination of '1' and '2' ('1' for larger
-> programs or samples,
-> '2' for smaller ones).
I think that this will end up as an evolutionary process. I would like to start by simply having a list of programs and descriptions to follow links. As the site grows, catagories will make themselves apparent.
-> Secondly, I believe that files should be submitted to the
-> administrator directly in a form he can publish. There should be no
-> requirement for him to prepare anything from original PLC
-> (or other) files.
-> >It is the responsibility of submitters to provide *.pdf files of
-> >unsupported file formats
-> PDF is nice, but I don't have anything which can
-> save or print to
-> PDF format, and I don't believe we should require people to
-> have to buy
-> this. I am not aware of any PDF converters which are
-> genuinely free.
per Willy Smith's post, I followed the link,
and installed. This is a nag-ware PDF generator. I think that we can live with the watermark for those who do not want to register. We could include a link on the site to get this download file. Perhaps a deal could be worked with zeon to let us mirror the file. The EULA appears to permit this. I will follow up with them on this if others agree. Ken? Opinions?
-> I have used the following methods:
-> 1) ASCII print to file (older DOS software only).
-> Cost - zero if the software supports it.
-> 2) Print to disk as a postscript file, then use
-> 'Ghostscript' (a
-> software package I downloaded off the internet) to convert
-> to JPEG. Cost -
-> ???? (I'm not sure if Ghostscript is intended to be free after the
-> evaluation period, and I didn't pursue it further after I
-> tried this out).
-> 3) Print to paper, and then scan it in as a JPEG.
-> Cost less than
-> $100 for a scanner (nothing in my case, since I already had one).
-> 4) Cut and paste between windows and save as a JPEG.
-> This can be
-> very difficult and tedious if the entire image you wish to
-> show does not fit on one screen.
I strongly dislike the idea of JPG files. although file size is small, if someone wants to include a large program, that is a really big picture, or a whole lot of small pictures. Administration would be easier with PDF.
-> Options 2, 3, 4 assume you are using Windows (or
-> perhaps Linux).
-> >A simple questionnaire should be filled out by the
-> submitter stating what
-> >processor, software version, equipment interfaced, etc. for
-> use in sorting by users.
-> Yes this needs to be done. Also include author, date
-> written, number of applications it has been used in, and a
-> suggested list of
-> subjects it should link to. If it was derived from another
-> source (e.g. it
-> is a re-write of an existing program from the archive), then
-> that original source should be cited.
Agree with all......
-> "Tanweer Ahmed" wrote:
-> >Why not put the codes in STL and make the life easy. I think all the
-> >PLC programmers can translate STL to Ladder or CSF. I agree that
-> >the STL syntex in different platform is slightly different
-> but can be
-> >understood easily.
-> I don't think this is a good idea because:
-> 1) Not every PLC supports STL,
-> 2) The program may not *be* for a PLC - it might be for
-> something else
-> entirely, (e.g. a bar code reader, or an MMI panel),
-> 3) The whole point of the particular submission may be to
-> illustrate how to
-> accomplish something using state charts or sequential
-> function charts.
-> Submitting it as STL (if this is even possible) may defeat
-> the whole purpose.
-> I believe that submissions should whenever possible be direct
-> print-outs or reports or screen images from actual working
-> programs from
-> real machines. Samples that 'ought to work', but have never
-> actually been
-> tested in their current form would not have as much
-> credibility. This is why
-> I am not sure that the 'universal ladder editor' which has
-> been suggested by
-> several sources would necessarily be useful.
Agree some more....
I guess the generic editor idea is losing some of it's appeal (in my opinion) since we have access to a PDF generator that, although nagging, is
> I guess the generic editor idea is losing some of it's appeal (in my
> opinion) since we have access to a PDF generator that, although nagging, is
Ghostscript (http://www.cs.wisc.edu/~ghost/) is free, runs on a variety of platforms, produces PDFs, and can be set up as a 'Print To PDF'
printer in Windows, as well as other more capable platforms. I have it set up on the LAN here as a Network PDF creator, allowing all machines on the
LAN to produce PDFs at will from anywhere.
Comes with a nice install utility, too, and a PS/PDF previewer.
And it doesn't nag, or generate silly watermarks. And it's free, unless you're incorporating the code in a commercial product.
| Derek J Decker email@example.com Decker Automation |
| Tel/Fax: 859/608-0041 585 Winterhill Lane |
| http://www.iglou.com/DeckerAutomation Lexington, KY 40509 |
Granted we can't make people buy the acrobat maker but maybe, just maybe there are enough people on the list with the appropriate software and platform. I for one would gladly volunteer myself to do A-B RSLogix 5 and 500.
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.
> > 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
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.
If there were such a ladder archive site, I would be happy to donate numerous programs to it. I think it is a fantastic idea and a way for people to share their programming styles. If no one knows of a site, lets talk control.com into helping us!
"The Lightning Man"
I believe the archive would be useless as programming codes and PLC modules are constantly updated and improved. Plus each manufacturer has different scan times, module performances, and rack configuration rules. Would you want a program designed with an older PLC and different modules used on a completely different application?
I have heard that GE Fanuc has a product called FX Manager which would allow you to keep a central archive within your own facility. This program can do things like provide audit trails of people who have checked out the program,
schedule downloads from a central server, and do comparisons of programs. You can contact GE at www.GEFanuc.com
Some great ideas have been presented for the archive -- we've also had someone volunteer to maintain it, and have started a side discussion about how things might work.
We've just registered a new domain "plcarchive.com", and are starting to
plan the site now. A remaining question, that several people have already mentioned, is how to best represent programming concepts so that people
using a variety of equipment types can make use of them. A pictorial representation, as mentioned by Michael Griffin, would probably be best, along with commentary and provision for subsequent discussion.
Our existing web tools make it easy to allow discussion threads associated with any given posting. The question, though, is how to convert ladder diagrams from a large number of different vendors' programming software to a common graphical format that can be presented on the web. Is there anything better than ASCII art for this purpose?
> The question, though, is how to
> convert ladder
> diagrams from a large number of different vendors'
> programming software to a
> common graphical format that can be presented on the web. Is
> there anything
> better than ASCII art for this purpose?
If the ladder logic/program isn't too large, use screen capture or print and then scan, and save in graphical format....jpg, bitmap, WMF, etc.
ZTR Control Systems
1. Base it on the IEC ladder/block formats
2. How about Word line drawings - can it be done with text boxes?
3. Basic ladders are no problem with multi-vendor formats - but there are major differences between eg Modicon timers and those for other vendors and the same applies for other complex functions.
These family differences will have to be maintained.
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.
Miille Applied Research Co.
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
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.
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.
firstname.lastname@example.org or email@example.com
> Geoff Lynn [SMTP:geoflynn@TELUSPLANET.NET] 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
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.
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:
I don't know why they took down the actual driver, maybe it was too good to be freeware.
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.
I just put a sample file to the test and it looks very good. If anyone is interested in seeing what the pdf output looks like, email me directly at firstname.lastname@example.org
I took a look at this, and I agree that the output is beautiful! my only concern is the high amount of administration required to get files into this format. And if someone is using 'Bob's PLC's Inc" brand of processor, and doesn't have Adobe, they cannot submit.
I also agree with Jiri that if we do go with a generic ladder editor, it would be good to work with the LinuxPLC group, with one caveat: It needs to run under windows. Jiri, have you looked at Hugh Jack's code? I have a copy, but am unskilled enough in C that I would not be able to port it. Could you tell me how much work it would be? I still think that if we could get this running, and write up a bunch of import/export filters, we would be ahead.
Anyone want to give an opinion on writing a ladder viewer/editor as a Java app/applet? Something that could embed on the page and display the code?
Does anyone know if there is a freeware version of Adobe acrobat out there for generating the files? If it was available for download at one time for free from adobe, maybe we could get a copy of that download file and put it up on our site for other to download. This would solve the problem of not being able to generate the files in order to submit. Anthony, did you download your's or purchase? If it was a free download, could you post it somewhere we can get it, or does the EULA forbid?
(I'm not on the list, so forgive me if this has already been covered.)
Jansen, Joe wrote:
> I took a look at this, and I agree that the output is beautiful! my only
> concern is the high amount of administration required to get files into
> this format. And if someone is using 'Bob's PLC's Inc" brand of
> processor, and doesn't have Adobe, they cannot submit.
> I also agree with Jiri that if we do go with a generic ladder editor, it
> would be good to work with the LinuxPLC group,
I think that was Petr rather than me.
> with one caveat: It needs to run under windows. Jiri, have you looked at
> Hugh Jack's code?
I haven't looked at it, but I'd expect that making a neat Windows program out of anything would be a lot of work.
If the input is plain text, though, then it's portable anywhere with minimal fiddling.
Alternatively, store the contributions in the repository in plain text instruction-list format - perhaps under CVS - and have a bunch of scripts
that automatically convert it into PDF, GIF, text-step-ladder and whatever else people dream up in the future.
(Storing it as plain text instruction list would have quite a few advantages: machine-readable format, so a stepladder editor could directly
import the snippets; multiple download formats, automatically generated; version control. The disadvantage is that - unless the ladder software has a `save as text' function - somebody has to type it in manually, while all programs can print to pdf/postscript.)
> Anyone want to give an opinion on writing a ladder viewer/editor as a
> Java app/applet? Something that could embed on the page and display the
Hmm, it would almost be possible to display stepladder in HTML tables, with a few gifs for "NO contact", "NC contact", "coil" etc...
> Does anyone know if there is a freeware version of Adobe acrobat out
> there for generating the files?
Apparently, ghostscript can do that - but I've no idea how well.
Jiri Baum <email@example.com>
Windows is not popular. Windows is *widespread*. Linux is popular.
On Tue, Jun 13, 2000 at 07:31:15PM +1000, Jiri Baum wrote:
> > Does anyone know if there is a freeware version of Adobe acrobat out
> > there for generating the files?
> Apparently, ghostscript can do that - but I've no idea how well.
My Linux system (SuSE 6.1) has a ps2pdf utility. Here's its manpage:
ps2pdf - Aladdin Ghostscript PostScript to PDF translator
ps2pdf input.ps output.pdf
ps2pdf converts the PostScript file input.ps to the Adobe Portable Document Format (PDF) in output.pdf. ps2pdf uses gs(1). See /usr/share/lib/ghostscript/M.N/doc/use.doc for
more details, where M.N is the Ghostscript version number.
Currently ps2pdf does a reasonable job on filled/stroked graphics, on bitmap images, and on text in the 14 built-in PDF fonts in the intersection of Windows and ISO Latin-1 encodings. It converts all other text in the PostScript file to bitmaps in the PDF file (although it does only write the bitmap for each character once per page, and only on pages where the character is actually used). It does not compress the output at all, except for character bitmaps: it can't use LZW because of Unisys' patent claims, and it doesn't yet use other compression methods for images.
AUTHOR OF DOCUMENTATION
L. Peter Deutsch <firstname.lastname@example.org>
(end of ps2pdf manpage)
> format. And if someone is using 'Bob's PLC's Inc" brand of
> processor, and doesn't have Adobe, they cannot submit.
that is the biggest problem, but before we go and panic, we should figure out who has a pdf writer and what plc platform
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.
Oceanside Technologies Ltd.
#140 - 8208 Swenson Way, Delta, BC
Tel: (604) 588-5450
The Archive discussion seems to have died away, and the web site is still not active. Is there anything happening with this idea?
London, Ont. Canada
The website is currently in development. It has not died, it is being completed as we speak. The only thing left (AFAIK) is the administration
portions, and it will be ready to go live.
With regards to the PLC archive question, I have found an interesting way of making PDF files which has not been mentioned so far.
The lastest version of Ghostscript has a "convert to PDF" feature built in. Ghostscript is a "free" program which you can download from the
internet (this is a full version, not a demo program), and there are versions available for just about any type of computer or operating system.
Ghostscript is a program which can convert Postscript files into a large variety of other formats. Ghostscript has a front end program
available called "GSView" which gives it a more user friendly interface. When I refer to "Ghostscript" below, I am actually referring to this "GSView"/"Ghostscript" combination.
It can be found at the following address:
After down loading and installing it, I simply performed the following steps (I am using a Windows 98 operating system):
1) Install a new printer device in Windows as a "Postscript" printer of some sort, but set it to "print to file", rather than printing to an actual printer. Set this printer as your default printer (you can change the
default back later of course).
2) Start up the program which will contains the data you want to convert to a PDF file.
3) Print whatever it is you want a print-out of. A window will pop up asking you for a file name. Give it a name with a ".PRN" extension.
4) Start up Ghostscript.
5) Load the ".PRN" file which you made earlier.
6) Select the "Convert" option from the "File" menu, and follow the steps through to creating a PDF file (this process was fairly simple and obvious to me, so I won't detail it any further).
7) You should now have a PDF file.
PDF files are based on Postscript, so the conversion from a Postscript printer file to a PDF is no doubt much easier than converting any
arbitrary format to PDF.
I have had a few problems relating to fonts. The symptom of the problem is that certain fonts seem to cause the letters to pile up on top of each other in the PDF file. This only happens with some programs.
I installed the fonts separately, and am not sure I installed the right ones correctly, so this may be my fault. I intend to repeat the
download and install procedure to try to correct this. If anyone else is familiar with this, I would appreciate any comments.
I created documents for the PLC Archive by using Wordpad to write the documentation about it, and then including either ASCII text "print to
disk" (from DOS programs) or graphics clips (from Windows programs). I then printed the Wordpad document using the above proceedure. Any word processor can be used for this purpose. Using a word processor as a base allows me to create a mixture of text (the bulk of the document) and code. I had no problems performing the conversion on the documents output from Wordpad. The
graphics images seem to be automatically compressed in the PDF conversion, with some loss of image quality.
In addition to documents for the PLC Archive, I have found Ghostscript to be very useful for creating PDF files from web pages. This is handy for those web sites which provide on line data sheets as web pages, but no PDF files which you can down load. Sometimes I need a data sheet with me when I can't get on line to the internet, and this is a convenient means
of creating a copy. It also provides a permanent copy in case the original web page disappears later.
Since making PDF files is now so easy, I would like to suggest that people may wish to contribute the PLC archive. Even if you don't have some especially clever algorithm that you are proud of, just some samples of well written code for various processors can be very useful.
There was a recent request from someone for samples of SLC500 code for example, as the person requesting this was new to AB hardware and just wanted to browse a typical program to get an idea of how people use them.
London, Ont. Canada