PLC logic generation software

[ste1171]

I saw somewhere on the internet a software package that automated the generation of plc code somewhat or atleast simplified the code writing process. I cannot, however, remember where I saw this.

Can anyone tell me if they have heard of this software package and if so direct me to a link??

I am curious to see how this works.

Thanks.

[dandrade]

In years of 199X, softwares was simple to lead, with total access it saw keyboard.
Being able, to be automatized with easiness.
Basically it needs:
1)Interpretator - To read a code of fixed syntax.
2)Codificator - To transform into mnemonics adequate for a PLC.

The ways to transfer, it can be for sending for the keyboard buffer or producing a caracters and CTRL+V in EPLC.
Unhappyly, the source and software I lost due the HD burning.

Currently he is not viable, the majority of EPLC needs control for mouse.
Already I found group in the accomplishment of these softwares inhttp://sourceforge.net However had closed.
I am in agreement and support, to develop these softwares.

Hum..., already I read commentary that some manufacturer include of
this resource in EPLC.What brand?

EPLC=software of edition the PLC

[Terry Woods]

Some people won't be happy with PLC programming until they find an interface that they can plug into the back of their head. Then they can "Think the Code".

Of course, this has nothing to do with Process Development. It is more inline with "Key-Punch" or "Data-Entry". You don't have to know how to develop code... you only need to know how to read.

I dare say that there are a lot of folks out there that just can't get comfortable with a keyboard (maybe microwave ovens aren't fast enough for these folks... nahhh, they just can't get that keyboard co-ordination thing down - they're just stuck in that damned hunt-n-peck mode).

The next best thing to "Think the Code" is "Speak the Code". In that case, a voice recognition package could enter code as it is spoken. However, one would have to learn ASM or, at least, STL.

(If you have been a very, very good boy dandrade, they might have a Portuguese version available! It might even have a decent Portuguese to English translator!)

Hmmm... in that case, I'll have to change my "BE THE COMPUTER" to something like, "BE, THINK LIKE, and SPEAK LIKE, THE COMPUTER".

Hmmm... This doesn't really sound like too far-fetched an idea!

However, the voice recognition package is simply going to have to have a "Teach-n-Learn" mode for all of those non-Chicago accents out there. Good for me... too bad for you. Uhhh... it's reasonable to assume that the default accent will be the Chicago accent... isn't it?

Hmmm... Damn... would that mean that I could only expect the Chicago accent to be the default on Win98?

(70)

[rdrast]

The very best 'simplification' of the code writing process is completely understanding the task before you begin to write any code.

If you don't understand the process you are dealing with, you can indeed get it done, but not efficiently, or even correctly. Patch over patch, quick fix here, convoluted logic there... yech.

There was a program out there by TI, called APT, that while very demanding in terms of resources did indeed take state-diagram logic, and convert it into Ladder in the PLC. Fortunately, the programmer only had to deal with the state diagrams 99% of the time, as the ladder code generated was unreadable.

[iknowsomeplc]

ste1171,

There are two types of PLC generation software available today.( I am refering Rockwell PLCs ) First type is using Object model of RSLogix 5/500/5000 and the ladder can be generated using your VB/VC code. I have developed a customized tool for a customer which will develop RSLogix500 ladder depending on customer selection from a VB front-end. The VB program actually picks from multiple standard code libraries already written and kept at specific location, compile everything into one file and download using the RSLogix 500 Object model. The good thing Rockwell Software did was that, they made available the object model of RSLogix 5/500/5000 for higher level programmers, compared to other competitors.

The second type of software is the one REALLY POWERFULL, called the Enterprise Controls from Rockwell Software! They actually creates the ladder from re-usable components which represent the physical, behavioral, electrical, logical and HMI aspects of an automation system.

[LadderLogic]

I don't want to sound like a retrograde and an old ****, but it seems to me, that would be a perfect tool for the unlucky ones who had learned to think C++ yet are forced to do the menial PLC jobs. Not that there is anything wrong with thinking C++.

Unlike PCs, where the convenience of object approach is bought in exchange for the increased demands to the system (more memory, faster CPUs etc.), PLCs hardware is pretty well set up. I don't think we should expect anything that runs at 1 microsecond per scan and has 512 MB memory any time soon. Not at the current prices, anyway.

Even the most hardcore C++ man knows that the most efficient code would be written in Assembly language. He also knows he never has time for it.

Well, in PLC world we are pretty much forced to write an Assembly code. Which, in turn, requires a little bit more understanding of the system as well as the process. Therefore I pretty much doubt the importance of this development.

Maybe I am a retrograde and an old **** after all.

[kamenges]

Back in the early '90s a controls engineer I used to work with tried out a plc code 'compiler'. I can't remember the name of the package. You developed the application using function blocks and the 'compiler' generated ladder logic, or something resembling ladder logic anyway.
The stuff it generated was a VERY twisted mess. In addition, it didn't comment anything so the ladder was essencially unmaintainable.
Now, I think most of us agree that the real power of ladder logic is that it can be interpreted by most technical people from the shop floor up through engineering. 'Compiling' code will take away that benefit. You might as well abandon ladder all together and operate strictly at the souce level. If I remember right, the last person that recommended THAT path on this forum had his spleen removed with a rusty putty knife. Since this forum is so broad based you can assume general industry will respond the same way.
I agree that the best way to speed up development is to plan out your system ahead of time. Also, write with an eye for the future. Writing software in a modular style tends to automatically provide you with code you can use SOMEWHERE in the future.

Keith

[Peter Nachtwey]

Modsoft can convert graphcet to ladder.
The TI PLCs have APT which was a flow chart to ladder compiler.
I still have a customer that uses APT and it is a Dow company.

The problem with both of these is that:
1. They aren't efficient.
2. If you modify the ladder you can't convert the ladder back to graphcet or APT.

I think flow charts, SFC and Graphcet are fine for state machines. Not so good for polling inputs. Ladder or instuction list is better for these tasks.

I an pretty sure that both Modicon and Tisoft had a macro capability or function capability that made writing small bits of ladder that needed to be used over and over, with only slight modifications, easy.

These kind of reminded me of an assembly language macro. Not such a bad way to go as they are efficient.

Compilers are not easy. We are working on a structured text one now.
Optimizing them must be done VERY carefully

Siemens compiles ladder and probably SCL to STL. The ladder to STL converter is not efficient. It wastes a lot of time mimmicking each ladder block.

[rdrast]

This isn't any kind of rant, just my opinion...

Canned, debugged library code is very nice to have, and indeed can speed up development time in many cases, but one must be extremely careful in applying canned library code. I prefer to keep interesting routines around as a template, or style-guide type of reference, rather than for actual use in programs.

If canned code is used, I like it to be in the form of a parameterized subroutine (most PLC's), or a stand-alone Function Block/Call (Siemens). The importance here, is that you define up the inputs, outputs, and temporary locations the function requires, and then pass them in and out to the actual routine.

I do NOT like having to modify addresses for canned logic, it just opens a (pardon the pun) can of worms if you mis-type.

My other problem with people liberally applying canned routines is that often they use something 'similar' to what is actually required, but not quite. That either requires modifying the canned logic, to 'open it up' (and making it no-longer canned), or adding wrapper logic to modify the way it behaves.

Also (being guilty myself of this sometimes), in trying to develop a 'Canned plug-and-play' type function, often times one can get so involved in the details of the function, and trying to adapt it to be universal, one loses sight of the original goal. This leads to longer development times.

What I find much more useful than canned logic, is (especially with newer 1131 type PLC's) to take a lot of front-end time to define up my data structures. More and more, it seems, designing a control solution is much more about designing a data interface to the control structures than the actual control structures themselves. If that makes any sense.

Even where I don't have user-defined data structures available (like PLC/SLC/Simatic 505/AD/etc), I'll define of blocks of memory and assign them the same for each machine section.

Out of a 30 word block for example, words 1 through 5 might be control and status bits, words 6 through 20 might be references/feedbacks, and 21 through 30 might be temporary working registers or transitional logic registers (one shots, temporary memory).

Liberal and consistant use of symbols and descriptions of things helps too.

Just my 1.33 cents (after taxes)

[dandrade]

Originally posted by rdrast
What I find much more useful than canned logic, is (especially with newer 1131 type PLC's) to take a lot of front-end time to define up my data structures. More and more, it seems, designing a control solution is much more about designing a data interface to the control structures than the actual control structures themselves. If that makes any sense.


Accurately, everything needs fundament armacion, generally repetition of standards will exist.
For this, a codification program is viable.It has many repetitive systems that are Sample: Motors all exact funtion, sometime swap numbers fisic i.
Still, I do not know a software for capable to multiply parts of the logic.(Frequent, solution and CoPy & graze, the parts and after search and change).
Certainly, it exists other fundaments to validate the developed the software of build code.

[ntommyb]

I've been using RSEC for years and as far as I'm concerned there is nothing canned about it. It has everything RS stand alone has but the generic things are put into subrotines. I spend more time debugging a libibary of assembleys created by rockwell then debugging hardware. It's flow logic with sequences which present alot of problems by itself. I've done state of the art lines using RSEC with RS5k. All the vets hate it and refuse to learn it. Its harder to work with as far as building lines and getting them running but Rekitting lines adding robots changing tooling it a snap super easy. If only I didn't have to spend two years at every install doing 80 to 100 hours a week min. and I think I had a hand full of days off last year.

Lol I told a noob that wanted to tape a penny on a prox to jump it out that this is an EC job buddy we tape hundrud dollar bills on prox's here

[CaseyK]

Some people won't be happy with PLC programming until they find an interface that they can plug into the back of their head. Then they can "Think the Code".

Of course, this has nothing to do with Process Development. It is more inline with "Key-Punch" or "Data-Entry". You don't have to know how to develop code... you only need to know how to read.(70)

If S+M were still in business, they could devlop "Think and Do"programming software!

Wait, isn't that one taken?

Can you REALLY "think and Do?"

[Ken M]

I seem to be in a phase of disagreeing with major contributors to this forum over the past few days, but here we go again. This time it's Terry and Peter's description of TI's APT (and to an extent SCL and similar packages). I used APT when it came out first and I think it was an incredibly advanced package for its day.
Thinking of it in terms of a ladder or statement list compiler is utterly wrong. To get the best from packages like these you have to make the conceptual leap and leave the ladder world behind. It's a bit like criticising Java for its flaws as an assembly code generator. It was never intended for that. Using APT there was no way the user could ever be exposed to ladder logic: you thought, designed, wrote, debugged and maintained your code using SFCs and CFCs (Sequential Function Charts and Continuous Function Charts).
Only if you took another of TI's programming packages (Tisoft) and plugged it in to the PLC would you see the world presented in ladder. APT generated a set of machine task codes and downloaded them to the PLC, and Tisoft interpreted these as best it knew how. No wonder it looked like a mess. And what was there to gain by viewing this way or, horror of horrors, Peter, editing it?

The fact that the same thing can happen with current languages is a user distraction. If you've written code that doesn't work using SCL, don't even dream of poking around in it using an STL editor to find out what's gone wrong. Fix your SCL code, or more likely, fix your design. Lock up your STL editor and leave well alone. I firmly believe that software should be debugged and maintained at the same level as it was written. Write STL, debug using STL. Write SCL, debug using SCL.
[/sermon]

That's it for the day.

Thanks

Ken

[elevmike]

Not necessarly along the same lines..but kinda...

On another thread I'm currently guiding a student programming a "simon" type program for a AD PLC. Basicly it's a recorder. You punch a series of inputs in record mode, and they play back on the outputs when in "playback" mode.

So the thought occured to me that this could be real handy...Let's say a non-PLC educated sparky needs to take a plc and program a simple application himself but has no software or PC or training... So I expiermented with a version of the recoding program that would allow a tech to record desired input & output images so that the PLC will play back a desired sequence of outputs based on whatever input image. In short, a self programming PLC of sorts...

So the user would define and imput image, then define an output image just using the inputs on the PLC. So when the PLC would see that pre-defined input image it would playback the assiciated pre-defined output image. This might save me a lot of trouble for simple applications...

[TimothyMoulder]

So the user would define and imput image, then define an output image just using the inputs on the PLC. So when the PLC would see that pre-defined input image it would playback the assiciated pre-defined output image. This might save me a lot of trouble for simple applications...

Isn't this the very definition of a sequencer? You could do what you are trying for from a simple HMI.

By the way, Unitronics has a new "drum" FB, heh heh...

TM

[elevmike]

Tim, the point is to use a simple method of having a non-programmer program a sequence without HMIs and a PC etc...

We maintain a lot of older all hardwired equipment with old obsolete timers, counters drums etc..and this would allow the tech to reto-fit a small PLC, (without me going through the trouble of programming it), to quickly turn around a shutdown situation...maybe....

Right now it's rather slow to react because I'm using a lookup table and it may take 2000+ scans to find the input image and then find the corresponding output image.

[Ken M]

Going back to the original topic of the thread I did once see a hand-built VB application which someone from another company had written to write code for him.

He had taken a very OOP approach to his design and working in the water industry he had plenty of objects to work with: valves, pumps, motors, filters, entire filter beds, even 'soft' objects like sequences etc. The output from his VB application was a source file for Siemens STEP7. The user input was a definition of the number and relationship of objects and the I/O mapping where appropriate. He had coded in his VB the logical behaviour of each object, so wherever he called for a Valve Type 01 the same source code would used throughout according to his design. He used an Excel spreadsheet for his tag and I/O management and the VB app simply read from that. It was most impressive in operation. He was convinced that for his company's needs it cut the software engineering cost of any projects they were bidding by about 80%. Commissioning and debugging was easy too since so much was standard tested proven code.

However it was a very specific application and even the author admitted it was far from being a general-purpose code writer. What he had done was to invest a vast amount of time up front in doing accurate design and coding in his VB app, and then made it re-usable for him in his industry. Most people may not have the luxury of the initial time or repeatability of applications.

Regards

Ken

[FrancisL]

ProDef was an example of a PLC code generator, it failed see
http://www.control.com/1026217209/index_html
There are others, notably ISAGraf and Codesys.

[FrancisL]

I should have mentioned ControlBuild too.
Has anyone had any experiences with these tools?

[ushidayo]

The part of ProDef which showed a great deal of promise wasn't the code generation but the automatic generation of documentation based on the process model. Perhaps you could do something similar with Controldraw? Anyway, Invensys have now taken over the rights to ProDef so it's probably completely dead now!

[ToddM]

http://petrilld.sourceforge.net/

Later...Todd

[FrancisL]

"Perhaps you could do something similar with Controldraw?"


Code generation has never been an objective with ControlDraw. Instead the intention is to provide a tool that you can use to specify and design the application in as much detail as you wish, and provide documentation for users and programmers to use.
Francis

[ndzied1]

ProDef was an example of a PLC code generator, it failed see
http://www.control.com/1026217209/index_html
There are others, notably ISAGraf and Codesys.

CoDeSys is alive and well in the programming systems of many different controls vendors. Their software doesn't generate ladder or SFC higher level languages but it does take higher level languages and generate processor (target) specific code.

[harryting]

The part of ProDef which showed a great deal of promise wasn't the code generation but the automatic generation of documentation based on the process model. Perhaps you could do something similar with Controldraw? Anyway, Invensys have now taken over the rights to ProDef so it's probably completely dead now!aRgGGHH. I remember ProDev from my Invensys days. I don't think Invensys ever "took over" ProDev but just invested quite a lot of $ into the thing.

Looking back in 20/20 hindsight, the concept would never survive.

- No ONLINE EDITING

- Difficult to learn (for me). Which was the entire idea of not dealing with ladder logic in the 1st place.

- PLC technology (software and hardware) change rapidly, the time one spending updating ProDev negate any benefits.

- Support!!!! The code it generate is hard to troubleshoot for the lucky plant who got the end product. Not to mention it bloated like nothing you ever seen before. Once a code is modified one can no longer go back to Prodev and work on the source code.



It's one of those thing that looks great in concept but bombed in reality.

[ushidayo]

"Perhaps you could do something similar with Controldraw?"


Code generation has never been an objective with ControlDraw. Instead the intention is to provide a tool that you can use to specify and design the application in as much detail as you wish, and provide documentation for users and programmers to use.
Francis

I didn't mean code generation, I meant automatic generation of documentation. Prodef had the ability to store standard documentation for the classes the user made, and then generate complete documents for every instance of the classes within the project. This documentation data was stored in XML format. The ability to have textual documentation of a process design as well a graphical model has some real benefits. What I mean is this, the reader will most probably have already mastered the syntax of written documentation. Whereas a graphical model requires the reader to learn a new syntax and set of symbols. I realize that a good graphical model can be less open to interpretation than a purely text based specification, but this doesn't mean that a written document should be totally discarded.

[ushidayo]

aRgGGHH. I remember ProDev from my Invensys days. I don't think Invensys ever "took over" ProDev but just invested quite a lot of $ into the thing.

Looking back in 20/20 hindsight, the concept would never survive.

- No ONLINE EDITING

- Difficult to learn (for me). Which was the entire idea of not dealing with ladder logic in the 1st place.

- PLC technology (software and hardware) change rapidly, the time one spending updating ProDev negate any benefits.

- Support!!!! The code it generate is hard to troubleshoot for the lucky plant who got the end product. Not to mention it bloated like nothing you ever seen before. Once a code is modified one can no longer go back to Prodev and work on the source code.



It's one of those thing that looks great in concept but bombed in reality.

What is ProDev?

[harryting]

What is ProDev?Sorry, I meant ProDef.

I think I still have a CD of it somewhere...