Hi Andrew

And good luck with yours as well. I'm still not sure why markets tend towards monotonal formulae, but diversity is to be celebrated as the next big thing must obviously, and neccessarily, be different from the cookie cutter sameness in this market today.

Regards

cww

 

We have substantial amount of libraries written in C++. The work we did up front allows us to write code for new machines very quickly. The reason we don't use MAT PLC is we are trying to stay away from ladder logic. In our industry (automotive) we need to do changes to machines all the time. I find ladder logic too limiting. I think (my opinion) that structural language gives me a lot more freedom and control of the machine.

I am trying to find some time to give MAT PLC a try to get a feel of it.

 

RLL (relay ladder logic) vs. some other programming method for PLCs. This is an age-old argument. Most control engineers in the US automotive industry require RLL programming for PLCs because their field maintenance technicians can read it and troubleshoot to find failed limit switches, prox, photosensors, and solenoid valves. Also, control of a transfer line is really a set of interlocks for which RLL is appropriate. We now have more than 50 years of experience in programming transfer lines in relay ladder logic -- first with mechanical relays, then with solid state relays, and for the past 30 years with PLCs.

The more structured PLC programming methods such as Sequential Function Charts (SFC) and Function Block Diagramming (FBD) are considerably removed from the control hardware. These are superior methods to program complex and highly sequential operations, but provide repair technicians few tools to troubleshoot failed sensors and actuators.

The ideal would be to program all of the high level logic functions in SFC using top-down methods. Then implement all computation functions in FBD and all final logic functions in RLL.

As an engineer, we think of RLL as too primitive, but its actually a very powerful graphic programming language for logical functions.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

I'm with you on that one, Andrew. But we must also supply
ladder logic for our brethren, or be ignored. It rates very high on the requirements list to try anything new. One very big feature of an Open PLC is that you can roll your own if the existing tools are really wrong for the job.

Regards

cww

 

Andrew Rokicki:
> We have substantial amount of libraries written in C++.
> The work we did up front allows us to write code for new machines very
> quickly.
> The reason we don't use MAT PLC is we are trying to stay away from
> ladder logic.

Right - but the MatPLC is happy to be used from C (or C++) as a library! Perhaps we should stress that in the documentation somewhere (but we didn't want to scare the people who prefer it the other way).

> I am trying to find some time to give MAT PLC a try to get a feel of
> it.

Let us know how you go...

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Dick Caro:
> RLL (relay ladder logic) vs. some other programming method for PLCs.
> This is an age-old argument. Most control engineers in the US
> automotive industry require RLL programming for PLCs because their
> field maintenance technicians can read it and troubleshoot to find
> failed limit switches, prox, photosensors, and solenoid valves.


I would say that if the tech needs to read the program in order to troubleshoot these, it's a failure of the HMI.

However, it does point to an (apparently) often overlooked requirement for any replacement language: it should support the creation of such troubleshooting screens. ("Support" in the sense of "make easier", to the point of automating it insofar as possible.)

For instance, if the language (or one of its libraries) has a "cylinder" construct, it should be capable of automatically saying, paraphrased, "I tried to extend cylinder <name>, which usually takes 1.36 s, +/- 0.2s, it's now 10s later - Houston, we have a problem". The language should make it *easy* to program stuff like that. (Preferably, if several cylinders fail at once, it should say "air supply failure" instead.)

Admittedly, I don't have a good way of doing that either.

(RLL satisfies this by being easy enough for the tech to read directly, effectively becoming part of the HMI; but that's not a solution that scales to complex systems.)

> Also, control of a transfer line is really a set of interlocks for
> which RLL is appropriate. We now have more than 50 years of
> experience in programming transfer lines in relay ladder logic --
> first with mechanical relays, then with solid state relays, and for
> the past 30 years with PLCs.
Yeah, that is important. Where RLL is appropriate, there's no reason to change to anything else, particularly in the absence of a clearly superior alternative.

> The ideal would be to program all of the high level logic functions in
> SFC using top-down methods. Then implement all computation functions
> in FBD and all final logic functions in RLL.
It shouldn't be that hard to write a compiler that reads the language of your choice and produces RLL. It'll be ugly RLL, though.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri

 

Dick:
> from the control hardware. These are superior methods to
> program complex
> and highly sequential operations, but provide repair
> technicians few tools
> to troubleshoot failed sensors and actuators.


I think this has little to do with RLL itself and more to do with the people programing the quipment and training the technicians. Having been in various plants with different standards, I've generally found that the technicians who are given proper training have less trouble than those who do not (and of course it helps to have people who dont mind learning something new). Having said that, I think by far the biggest difference in comfort levels comes from the way the programs are written. In RLL for uncomplicated systems its easier to see the logic as its happening, giving one a clue as to whats going wrong. Experienced programers don't need that "crutch", because they use the tools constantly and see all the benefits of better (more productive) languages. What they normally don't worry about is maitenance functions, because they're just trying to get the equipment to run right in the first place (which can be quite a challenge in itself). With a little more attention to such concerns, I think that most problems could be rectified. One thing I've done before with complicated batching systems, is save a history of the error conditions with timestamps. That allows the techs to know what happened to shut down the equipment and in what order it happened. Because there was a well thoughtout design behind the system to begin with it was trivial to add. Standard templates for things like motors, valves, loops, etc. with some diagnostic functions can give techs all the information they need to troubleshoot those types of systems. They just need to be trained on how to use them and willing to learn.

Richard Higginbotham (speaking for me)

 

Dick, Thanks for the voice of reason on the RLL vs computer language argument. I've contended for many years that in industrial plants, where maintenance men have to troubleshoot and maintain the equipment, RLL was the only choice(see Control Engineering November 1988, A Case For Ladder Logic). I still use the same modular structured programming method I developed in the mid '80s and it still meets the needs. My goal on every machine is to NOT be called at 3:00 AM because the shop personnel can't understand how something works. When I move on to the next job I know that they can handle all aspects of the logic because its all in simple common RLL. High level languages may be OK in environments where a technician or engineer is available to help with troubleshooting, but not in the plants I work in. Dave Hurd GE Appliances Louisville, KY

 

On June 26, 2003 21:44, Dick Caro wrote: <clip>
> The ideal would be to program all of the high level logic functions in SFC
> using top-down methods. Then implement all computation functions in FBD
> and all final logic functions in RLL.


At least some implementations of SFC represent the transition conditions as RLL. An SFC provides a broad overview of a program, but some other representation is required to provide the detail of what is actually going on in the step or transition.

> As an engineer, we think of RLL as too primitive, but its actually a very
> powerful graphic programming language for logical functions.
<clip>

Ladder is actually a very high level programming language. Its major failing is that it doesn't provide any inherent means of organising a program beyond the individual rung level, or of indicating the relationships between rungs.

Given the above, I see Ladder and SFC as being complementary, rather than as alternatives to each other.

--

************************
Michael Griffin
London, Ont. Canada
************************

 

Spoken like a computer geek. Here is an answer from a control systems geek. There are already several "compilers" that speak PLC source code. Concept from Schneider for their own lines, and ISaGraph from ICS Triplex/Altersys for the PC and some other platforms. Both support all of the IEC 61131-3 programming languages for PLCs. ISaGraph also supports a flowcharting programming method and loads of documentation aids. If you start with SFC, your code modules can be in well documented RLL for interlock functions. These are such good packages that I don't understand why they are not more popular.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

Exactly. My experience with SFC is Grafcet (in both Concept and ISaGraph). The beauty of SFC is that you can organize all of the code into logical sequences and parallel activities. Then, depending on your preferences and the nature of the application, you implement the lowest layer with RLL, FBD, Structured Text (ST, like Step7), or even C++ for those computer geeks. RLL is great for linear logic, but sucks for sequences where SFC excels. They are very complementary.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

<p>On June 28, 2003, Jiri Baum wrote:
> I would say that if the tech needs to read the program in order to
> troubleshoot these, it's a failure of the HMI. <

<p>EXACTLY.

<p>
> However, it does point to an (apparently) often overlooked requirement for
any
> replacement language: it should support the creation of such
troubleshooting
> screens. ("Support" in the sense of "make easier", to the point of
automating
> it insofar as possible.)
>
> For instance, if the language (or one of its libraries) has a "cylinder"
> construct, it should be capable of automatically saying, paraphrased, "I
> tried to extend cylinder <name>, which usually takes 1.36 s, +/- 0.2s,
it's
> now 10s later - Houston, we have a problem". The language should make it
> *easy* to program stuff like that. (Preferably, if several cylinders fail
at
> once, it should say "air supply failure" instead.) <

<p>This is easy to implement and quick with C/C++. Like I said before, we have libraries that suit our needs well. To alert operator about the problem with the machine all we need is something like this:
<pre>
test_switch(SWITCH_OPEN,CAN_LIFT_RETRACT); //make sure retract switch works
CAN_LIFT_CYL.Off(); //turn cylinder off
test_switch_delay(SWITCH_CLOSED,3000,CAN_LIFT_RETRACT); make sure it retracts in 3s or less.
</pre>
<p>If there is a problem with CAN_LIFT_CYL there will be an error on the
screen and machine will go into a stop mode.

<p>Of course this could be rewritten into a cylinder class where all you would
need is:<br>
SmartCAN_LIFT_CYL.Off(); <br>
this would have the same functionality.

 

Andrew,

This is a late reply, so you may already have got what you need from earlier feedback.

There's absolutely nothing about the MAT PLC that implies you have to program it in ladder, or even in any of the IEC 11631 languages.

Control logic in MAT PLC is just a module that attaches to the virtual hardware (shared memory) and follows the rules for reading and writing its contents. You can program the PLC's logic in any language that gives you access to the core API. Besides the native 'C' libraries and 11631 modules currently under development, API wrappers have been written for Python and Tcl. Certainly you should have no trouble accessing a MAT PLC from your C++ code.

Greg Goodman
Chiron Consulting