Hi there,

I am working on a tool for graphic description of PLC programs. Since I don´t want to reinvent the wheel I would like to know what tools are currently available.

Please give me also some feedback about the tools you have been using.

Thanks for your help

 

What are you trying to do? Who will look at this?

I don't like flowcharts. I don't find them very compatible with ladder logic.

What about showing the actual ladder logic. Any PLC engineer will undestand it.

 

> What are you trying to do? Who will look at this?

I am trying to put text description in english language away due to the misunderstandings it causes to different PLC programmers.

> I don't like flowcharts. I don't find them very compatible with ladder logic.

Neither do I, it is not a flowchart program I am working on, I am to research an effective way to comunicate with the programmers with minimum ammount of written text in order to decrease the enginnering overhead. Something in between flowcharts, state diagrams and the like.

> What about showing the actual ladder logic. Any PLC engineer will undestand it.

and then fire the PLC engineer? I will think about it...

 

I think you might need to rethink your approach. You see, the personality of the controlled process dictates how you illustrate its semantics. Take a steady-state process such as temperature control. A flow-chart will do nicely. However, for a batch driven process you might getter use a Data Flow Diagram (DFD) view borrowed from the IT world. While for a discrete/sequential process you'll need a time-driven GANTT/PERT style approach. Control Enginners deal with this all day long so the most "homogenous" compromise is ISA symbols. That is why the IEC PLC standard involves multiple languages that expand above ladder logic into languages that resemble Fortran, Basic, and/or Sequential Function Chart programs. You never know what the process will demand to control it, untill you understand its "personality." Not trying to confuse just trying to help! Good luck.

 

Yes, I agree that some tasks are better represented in one form than others as in the examples you have given.
Big plants might need several kind of diagrams to describe its control (flowcharts, state-diagrams, CSF, etc.) for each independent part of the process.

Maybe that´s what I have to make. But I am still researching for the current tools available for this purpose (not Visio, something more specific for automation/process control).

What do you people use when describing a process control? Free text in english? Or any graphic tool other than Visio?

Thanks for your help

 

>>What are you trying to do? Who will look at this?
>
> I am trying to put text description in english language away due to the misunderstandings it causes to different PLC programmers.

It sounds like you need a clear statement of purpose for this project. What problem is it that you are trying to solve? Who is the beneficiary of this solution? What measure will you have of its success?

With a clear goal, perhaps you will get some more concrete suggestions.

>>I don't like flowcharts. I don't find them very compatible with ladder logic.
>
> Neither do I, it is not a flowchart program I am working on, I am to research an effective way to comunicate with the programmers with minimum ammount of written text in order to decrease the enginnering overhead. Something in between flowcharts, state diagrams and the like.

"Something between flowcharts and state diagrams" is a (vague) description of a class of solution, but doesn't really tell us what problem you're solving. There are any number of highly formalized, well developed and mature methodologies/techniques/languages for describing programming requirements, constraints, constructs and interactions to programmers. What do they lack that you require?

>>What about showing the actual ladder logic. Any PLC engineer will undestand it.
>>
>
> and then fire the PLC engineer? I will think about it...

It sounds like you want to specify PLC programs in terms that are conscise and unambiguous to PLC programmers, but without writing PLC programs.

As you have noted, the ambiguous/nonconcise end of the spectrum is characterized by natural language descriptions.

<ASIDE>

I will add that this is particularly true of descriptions provided by people who lack any or all of the following:

- a real understanding of the problem
- a real understanding of the nature of the solution
- an understanding of the distinction between a statement of the problem and a description of the solution
- the communicational rigor to render unambiguous descriptions in their natural language.

</ASIDE>

At the unambiguous/concise end of the spectrum is the the PLC code, which is itself the ultimate description of the solution. (A program by itself does not, however, indicate anything about how well the programmer understood the problem. It does exactly and precisely what it does, whether or not it does what someone needs or wants it to do. Requirements analysis - exploring the nature and limits of a problem, and capturing and communicating that information - is a completely different area from program design and specification, and there is a host of methodologies and techniques to support it.)

It can be presumed from your statement that the people who understand the problem don't code for PLCs, and the PLC programmers don't understand the problem. If either of these were not the case, you wouldn't need the tool you're working on.

So what information do you want presented to the people who know how to code for PLCs, and what level of precision/conciseness you require from people who understand the problem?

My apologies if all of this seems rather academic, but you've invited us into your project rather late in the process, without the benefit of any of the thought that's gone into it so far.

Regards,

Greg Goodman
Chiron Consulting

 

Generally I use a combination of logic diagram (based on a superset of ISA binary logic diagrams - extended to include analogue and process block diagrams) for common logic, and Grafcet/SFC to describe sequences.

I also use these in combination with cause& effect diagrams, P&IDs, state-charts, UML diagrams and anything else that I might be useful in particular instances (such a Z).

Diagrams are generally done using Visio or SmartDraw, but I have used a CAD package (AutoCAD/TurboCAD) but these are not as good.

Visio supports VBA (as do both the CAD packages mentioned, which also have other language support) so could be a good starting point (there is a Linux equivalent but I don't know if it is scriptable).

 

Hello,

I've recently spent some time evaluating some process modelling tools that can go right from the business process into case model design for our custom software development, including some PLC functionality.

After evaluating quite a few packages, I finally ended up writing my own stencils in Visio. Most of the packages available have way more than most people need to illustrate simple business process functionality and the inputs/outputs/resources that affect each function.

If your not looking for a modelling package that might take your diagrams and automatically generate PLC code, I would recommend just writing your own custom stencils with Visio and training your PLC programmers how to understand your business process model diagrams.

That's just my experience, hope this helps a bit. Good luck!

Scott
PEER Group
Kitchener, ON Canada

 

Angel Caban, [email protected]

Did you find a solution to the question "Is there a description tool for PLC programs"?

This is a tool that would make it possible for a PLC programmer to describe his program to the world of none ladder logic programmers and for the rest of us to convey our understanding of the problem and to define a solution to the problem in a way even a PLC programmer will understand and have to adhere to.

I say the above with respect and admiration for the capabilities and talents of most PLC programmers. However the only machines that fully adhered to my original intent and did everything I believed they should were the once I programmed myself over twenty years ago.

I recently started to generate a graphic description of a slightly advanced PLC program that combines an original manually loaded and unloaded 'process automation machine' and a later added 'load and unload module' which had to be married to the original machine to form a fully automatic piece of equipment by a person three thousand miles away, the 'Fully Automatic Unattended Process Machine'.

I wrote a natural language description for the PLC program on the first machine and another description of the PLC program for the added module which was much more complicated because the second PLC program had to interface with the first PLC controller without changing the first PLC program with only a few Inputs and Outputs moved to the second PLC which then mimicked in automatic mode and echoed in manual mode to the first PLC.

After a few revisions of the second program it all worked so well that my next project was to make a faster all-in-one machine with more bells and whistles.

The FDA documentation requirements were raised to include full program documentation with reasons for the flow of the process. What makes things even harder for me is that the Programmer I am using did not like the complexities of the natural language descriptions. I told him I had started a Flow Chart that would describe the new all-inclusive program and he said it would be too complicated to follow and that he would not use the flow chart.

Then I started to do a simplified time and event based graphic description of the PLC program requirements using Visio and at this point I am convinced that he will not be able to follow it as because there are so many machine/Operator interface conditions, flow directions, and operator actions and responses the program must track.

What Next?

Please reply, Thanks

 

> What Next?

Just look at http://www.controldraw.com

Francis