PLC logic generation software

ste1171

Member
Join Date
Oct 2003
Posts
14
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.
 
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
 
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)
 
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.
 
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.
 
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.
 
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
 
Ladder compilers.

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.
 
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)
 
rdrast said:
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.
 
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
 
[QUOTE,IN PART=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.(70)[/QUOTE]

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?"
 
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
 
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...
 
elevmike said:
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
 

Similar Topics

Hello I need to message read the entire 16 channel raw analog inputs from a 1769-L33ER Compact Logic controller to another 1769-L33ER Compact...
Replies
8
Views
231
Hello, I have problem i'm working on boiler plc, but i get to the problem that i can't solve myself. I have problem with material gate. I need to...
Replies
2
Views
335
Hey, I am entirely new to PLC's and am trying to help my friend with a project. He wants to take the signal from a PNP photoelectric sensor as...
Replies
12
Views
2,184
Hey guys, I am trying to pull the ladder logic out of some ancient Honeywell S9000 PLCs, but I can't find the software anywhere (google search...
Replies
10
Views
4,833
I need to know how to take a schematic like this and solve it for let’s say a run time of 5 seconds By solve I mean determine which rungs are...
Replies
33
Views
8,978
Back
Top Bottom