At 19:33 20/12/01 +1300, Bruce Durdle wrote:
<clip>
>I think it is probably easier to teach a motivated electrician what
>he/she needs to know about programming techniques for the relatively
>restricted set of tasks needed for industrial work than it is to teach
>a programmer what he/she needs to know about the electrical end. I can
>certainly rely on an electrician to deal with the non-programmed parts
>of a PLC system much more effectively than would a programmer.
>Unfortunately, "PLC programming" has too often consisted of Mr
>Allen-Bradley or Mr Modicon showing how to use his favourite
>programming terminal to put logic into the PLC, and nowhere near enough
>about how to decide what logic to put in.
<clip>

I agree with your point of view here. I would like to add that one problem people who are new at the game have is they often don't know where to start. They look at the problem as an indivisible whole and feel overwhelmed. They then run around doing a bit here and a bit there and then try to knit it all together somehow. If it doesn't work, they just add more code until it looks like it works.
If they are taught a systematic approach to the problem, they can take one big problem (the machine) which they don't know how to handle, and break it down into a set of smaller problems which they can solve individually. This isn't something which gets taught in any PLC class I have seen. You are right, the classes usually just worry about explaining the instruction set and how to use the software.
Then again, this latter problem isn't much different from most computer programming classes. You can take a series of classes in Visual Basic and learn lots about VB syntax, but nothing about how to write a program.

I have long since lost any illusions that the situation in the IT/computer world is any better than it is in this business. I have a number of relatives who have worked on large IT projects in at least half a dozen countries around the world (including one who spent a couple of years in New Zealand). When they get together they like to talk about which project was a disaster, and which one was a success.
It seems there are a lot of "programmers" in the IT/business world who simply don't know what they are doing and shouldn't be programming (does this sound familiar?). Having a nice set of formal qualifications isn't the same thing as actually having any tallent or ability. The main difference between the IT business and the automation one is the IT world seems to have a much higher tolerance for failure and much larger quantities of cash they are willing to shovel down a black hole.
It seems though that the really big IT disasters happen not due to "bad code" at the level of the individual programmer, but rather are due to bad planning (or no planning) or bad design analysis. Except for the scale of the fiascos, that isn't too different from what I see in our own field.


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

 

<clip>
>I'm finding this fascinating. I have never met an automation type who
>was an electrician. Perhaps it's local custom, but most seem to come
>from the electronics arena or machine tools.
<clip>
>Probably
>a different situation than big industry. We don't have any electricians
>on staff. We call in outside folks for plant power wiring.
<clip>

That's odd. Around here (in Canada - or at least in my province) it would be more common for a plant (even a small one) to not have engineers than to not have electricians. As for wiring, our maintenance electricians don't normally do our plant power wiring either (except for hooking up machines). An industrial electrician and construction electrician are two
different things here - it's not even the same license.
The trades programs here are run by the colleges. If you wanted to become an industrial electrician you would need to take (and pass) a set college program as well as have the necessary number of hours in the trade. I don't know the details of this, as I'm not an electrician myself.



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

 

I'm trying to get my students to take a look at the overall picture and work down to the simplest comands before they actually start coding: "Top-down problem analysis - bottom-up program writing". But it's very hard
- they all like to get on the keyboard and make those lights flash. The same applies, only more so, to industrial people (and it's not just the electricians).

Again I think the manufacturer's courses have a lot of responsibility here, and, traditionally, before simulation tools became available, the only way to try things out was to connect on tho a PLC and see what the more complex instructions actually did. With better software tools and equipment it became more feasible to do it off-line.

By the way, this doesn't just apply to PLC programs - I once spent a day and a half which was supposed to be devoted to acceptance testing a relay-based boiler control panel watching the design engineer swappoing wires trying to get the flame monitor integrated properly into the logic!

I tell my students to get a Functional Spec in writing and formally accepted. This might at least slow down the galloping growth in requirements that seems to be a universal problem with large IT applications.

Bruce.

 

In the US (CA), at least, where I have worked, an electrician is someone with an electrical contractors license. ( www.bxofsf.com/lic_class.html ) Some do lighting others do industrial work. It's pretty much up to the owner to make sure the electrician he chooses has specific experience in the type of work to be performed.

Electrical contractors that do industrial work will often provide and install MCC's and field instruments. The demarcation points here are the in the areas of instrument calibration and loop checkout. This is usually a technician's job. In small to medium sized operations, it is more likely that the owner will keep a technician on staff than either an electrician or an engineer.

Technicians generally develop their skill through technical colleges, as maintenance personnel in the military, or most frequently, just by figuring it out on their own. I am not aware of any license or certificate that stamps someone as a technician.

Jay Kirsch

 

Hi Micheal

Well, soon it may be the same way here. With the collusion and racketeering between the powerful unions and the state board of electricity, they are pressing for rule by edict that anything that uses wire has to be done by the licensed electricians family under the local don, a master electrician. I'll probably get kneecapped for exposing this. Understand that I have no objection to requiring licensure for power distribution and motor circuits where they are in their depth and safety is at stake. But, I can't possibly see any rationale for control wiring and signal circuits other than turf protection. The cost of compliance will be prohibitive and the benefit to industry nil. I have never seen a case where the electrician knows more about my stuff than I do.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

 

There's another consideration, beyond that of end-users, programmers, and technicians, and integration into higher business functions. Some control processes simply aren't understood that well, even at the academic level, and therefore don't lend themselves to complete comprehension at any level. Please excuse the lengthy build-up before I make my point.

For instance, the company I work for processes APET polymer into drink cups, and other types of containers. APET is extremely hygroscopic, and, if not dried below at least 50 PPM water content, will cause processing and quality control problems in the finished product. This results because high moisture content decreases the polymer's intrinsic viscosity (IV), and hence it's strength. Also, the reclaim stream must be recrystallized before reuse in order to maintain desirable material characteristics.

In both crystallizer and dryer systems a heated air stream of at least 1 CFM per #/hr output (typically 1400 CFM) must be provided. This is routed through a diffuser cone mounted (at least, in the systems we use) at the bottom of the material tanks where is is percolated through the material bed in order to present the reclaim and virgin material particles with equal amounts of heated (in the crystallizer) or heated and dried (in the dryer - negative 40 degree dewpoint or lower) air.

To assure material in the crystallizer is in fact crystallized an RTD is mounted at the top (feed end) of the tank, and is supposed to prevent the dryer from loading material from the crystallizer unless this residence temperature is at or above setpoint (typically 180F). This unit also uses a series of helically offset blades which extend from the tank centerline to nearly the wall. As APET flake approaches crystallization it becomes soft and gummy, and develops into large lumps if not continually stirred and broken up.

Crystallizer delivery air setpoint is determined essentially by material throughput, and minimum residence temperature - higher throughput means higher temperature delivery air to maintain residence temperature. Of course, with greater throughput comes increasing amounts of feed material, and higher temperatures are required. However, if the temperature is too high then the material will degrade, and result in reduced IV values because the polymer chains are shortened. Also, part of the issue is how long the material is at temperature in addition to the overall temperature.

This feed material consists of inline and offline reclaim flake, and virgin pellets, and is a point where complex interactions come into the process. Inline reclaim will be fairly dry, and somewhat warm (how dry and warm depends on how long it sits in the reclaim hopper awaiting reuse), offline reclaim temperature and water content varies considerably (depending on how long it has been in storage) as does virgin pellet (which is stored in unheated outside silos). In addition, reclaim flake size varies from some percentage of powdery dust, to as large (in at least one dimensional axis) as the grinder screen hole diameter, and as thick as the sheet being processed. Virgin pellet stock has less dimensional variation, but can be roughly circular to elliptic in cross-section (depending on how the pellet was manufactured).

This system runs without a lot of problems when processing at lower throughputs (50 to 70% design limit), but becomes very fragile when approaching that limit. In particular, residence temperatures begin to fluctuate over a much larger band (as much as 80 to 100 degrees), and sometimes, even when residence temperature is above setpoint, we get lumps of partially crystallized material.

Over the years we've come to suspect these swings in temperature occur due to convection cells in the material bed, and that these cells change in characteristics as throughput increases. One clue is that the cycle time of this fluctuation will nominally be 12 to 14 minutes (and the overall range is lower) at lower throughputs, then sharply shift at times to a cycle time in the 6 to 7 minute range (with stronger fluctuations). This suggests to me the presence of multiple convection cells.

I'm not going to comment on the basic system operation further, except to note this is a glossed version; several pages of additional text could easily be generated.

Point #1
This equipment uses proprietary controllers that are essentially closed to the end user. The controllers themselves don't have the capability to change air delivery temperature to match throughput rates, so, unless the user pays close attention, the problem of degraded material (and/or chronically insufficient residence temperature) comes into play. In particular, unless the operator backs off delivery temperature when the extruder shuts down for more than a few minutes then degraded material is almost certain to occur.

These controllers do offer RS-485 ports for external comms, but use the SPI protocol, which, last time I looked, cost approx. $5000 for the two books containing the protocol specs. This means I'd have to shell out $5K even before the first line of whatever code was necessary to link the crystallizer and dryer controllers to the in-house PLC-based vac loader (where we *do* have the option to change how control is performed) was written, and I'm not eager to do it. On the other hand, I could replace both of these controllers with PLCs for not too much more than the cost of the protocol books alone, but (because they use gas burners for delivery and regen temperature generation) I'd need to get them recertified, and liability for any problems would move from the OEM to me. Again, not something I'm eager to do.

This is more of a lament about the SPI protocol, which seems to exist more to lock-in users to particular brands of equipment (and/or to feed piles of money into this standards organization) than to open up the systems to o utside control. One by-product of this closed approach has been an increase in my numeric key group typing speed, because what knowledge of temperature fluctuations I've developed came by writing down the residence temperature at 15 second intervals for up to 3 hours at a time, then sticking them into a spreadsheet.

Point #2
Its taken us several years of operating the system and observing behavior, and troubleshooting problems before coming to these realizations. Supplied documentation did a barely adequate job of explaining the system components, and nothing usable in the way of how the system "as a system" operates. I don't know what to do about this, because it's my suspicion than only a handful of people at any particular company have a handle on how all the pieces go together, and they aren't the ones writing user docs.

Also, the HMI consists of a 2 line VFD (no graphical output, no means to store system history), so it is impossible to come to grips with the nature of system operation unless you are willing to stand at the control console for hours on end.

Point #3 (the one I've been building up to)
Several phenomena we've observed are not rigorously understood, period.

For instance, sometimes we'll suffer through periods where large volumes of reclaim flake are carried over to the dust cyclone - sometimes as much as 500# per day, and other times where this doesn't happen at all. There is a correlation with reclaim flake thickness (when running thinner web the problem becomes more pronounced), but it's not a consistent correlation, and sometimes we'll have problems even with thick sheet, or have no problem with thinner sheet.

One thing that does seem to appear when this occurs is the presence of "inverse tornadoes" of material emerging from the top of the material bed. They are smaller in height and diameter, and occur more frequently closer to the tank center, and less common (but higher and larger) when emerging near the tank walls. These rotate with the material bed, and sometimes are positioned directly under the delivery air exit pipe (at which point a lot of flake is carried over).

An engineer at the OEM that builds this system commented this is a symptom of percolation breakdown, and means the system has begun to act as a fluidized bed.

I've been reading up about percolation, fluidization, and mixing over the last couple of weeks, and it appears these fields are all tremendously complex, and have ramifications that are not at all well understood from the practical processing level. Also, each field in itself is on one or more cutting edges, and new things are discovered about them all the time.

The upshot - very KISS control systems from a leader in this type of equipment (and one of the better ones at that) coupled with almost intractably complex real-world phenomena is not a recipe for consistently good process operation. Even more powerful and flexible controls would not be the final answer, per se, because the underlying process complexity is not very well understood, and so the question would remain, "what should the control system do?".

Point #4 (skill demarcation)
Luca pointed to this area of the subject, and I'd like to expand upon it. Let me add that I started in equipment maintenance and troubleshooting about 20 years ago after leaving my job as a dishwasher. I had a 1620 hour vo-tech certification in electronics technology, and a two semesters of the 2 year EET program from Penn State under my belt, and was dishwashing because technical jobs in this area aren't all that plentiful, and especially so for one with an incomplete education and little experience.

I think it was fortuitous to find an employer with an essentially 'horizontal' structure, because it exposed me to typical PM and emergency duties (cleaning, oiling, DC motor brush changing, pneumatics, hydraulics, welding, plumbing, rigging, etc.), machining (lathe, mill, and surface g rinder chores), and just about anything that came up.

I am fairly good at the electrical/electronic end, and troubleshooting in general (and I learned early on I'm better doing these, and am a lousy machinist), so I don't do those things much anymore. However, I think the experience of having once done them gives me a better understanding of equipment, and the plant as a whole, than someone who has always specialized in one area, especially if exclusively programming.

IMHO, someone aspiring to be a machine control programmer (or do other control work - wiring cabinet, and the like) should be thrust into the grunge world for a year or two while practicing their craft, because it will make them sensitive to things that an emergency mechanic would consider no-brainers (i.e. - mounting sensors where they can be accessed and adjusted, grouping signal sources on the PLC input card to promote easier visualization of problem sequences, signal wire routing, and other real-world considerations), but which might not even show up on a programmer's radar.

Working with programmers from equipment OEMs shows they fall into two general camps - ones that understand these things (and are willing to listen to user suggestions), and ones that don't (and who typically engender a NIH attitude to suggestions). Less than remarkably, equipment built and programmed by people in the first camp tends to have less problems than that from the second camp.

Bob

 

> Why have an electrician fix a program?
> because the machine is down!
...
> because i hold an electricians licence does that mean i tell my
> customers that they need the hydrolic tech when i find a sticky valve?
> not if i want to keep them as a customer! i get a valve and fix the
> problem.

But would you change the hydraulic circuit? Take a saw and cut off a mechanical stop?

Changing sticky valves (or burnt-out I/O modules) is one thing; changing the logic itself is another.


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

 

At 12:40 22/12/01 -0500, Bruce Durdle wrote:
<clip>
>I'm trying to get my students to take a look at the overall picture and
>work down to the simplest comands before they actually start coding:
>"Top-down problem analysis - bottom-up program writing". But it's very
>hard
>- they all like to get on the keyboard and make those lights flash. The
>same applies, only more so, to industrial people (and it's not just the
>electricians).

>Again I think the manufacturer's courses have a lot of responsibility
>here, and, traditionally, before simulation tools became available, the
>only way to try things out was to connect on tho a PLC and see what the
>more complex instructions actually did. With better software tools and
>equipment it became more feasible to do it off-line.
<clip>

The manufacturer's courses are not intended to teach people the proper way to design and write a program. They are just intended to teach how their particular software and hardware work. They aren't there to provide a general education - people need to go see you for that.
I would guess that your real problem is that there is no place in the program of courses to teach software design methods. The students need to be given a big enough project that they really will find themselves lost unless they use a proper approach. A project this size would not be feasible for them to complete within the time available in an individual course.
Perhaps though they could be asked to document a design for a large program, but to only implement certain functional parts of it which you would assign. You could then evaluate how well they structured the overall project, as well as how they translated the assigned parts into actual code. This sort of a teaching approach though would only be suitable at an advanced level, and not as part of an introductory course.


>I tell my students to get a Functional Spec in writing and formally
>accepted. This might at least slow down the galloping growth in
>requirements that seems to be a universal problem with large IT
>applications.

We are finding ourselves having to force many of our suppliers to write a functional specification. We take the position that we will write what we want the machine to accomplish (this goes out with the request for quote), but we want the machine designers to write how the machine will actually work (our RFQ asks for this to be part of the design process). We may specify particular hardware and algorithms, but the builder is the one designing the overall machine, so they need to write down how their particular machine will work to accomplish the desired goal. They also need to convince us that what they plan to do is going to work.

I haven't worked with a single one yet who could write a *useful* functional specification without some prodding from us. Those projects however where the builder agreed that this was a usefull exercise always went the smoothest and tended to get finished on time. Where the builder was just going through the motions to satisfy the contract, the review process was just a waste of time. I don't suppose that I need to add that these latter projects were the ones that never seemed to end.

I would like to point out that I've found "galloping growth in requirements" has tended to come more from poor planning than any other source. Elaboration of features tends to happen when someone has been using a "design as you go" approach, and has to keep adding new features to overcome the deficiencies in the existing ones. Calibration seems to be a particulary common source of these problems as it tends to get added last but imposes unique requirements on the machine.

I haven't seen a really good generally accepted formal method of describing the features and functions of a control system. Everyone seems to have their own method (when they have one at all). There are methods used in the computer programming field, but they don't seem to be a good fit to the automation field. A machine control system tends to be of a smaller size but with a greater degree of interaction with the physical world than the typical large computer project.
Are you aware of a good, well described method? I am referring to something which would be used for small to medium size automated assembly machines, rather than for large process industries.


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

 

<clip>
>Technicians generally develop their skill through technical colleges,
>as maintenance personnel in the military, or most frequently, just by
>figuring it out on their own. I am not aware of any license or
>certificate that stamps someone as a technician.
<clip>

Here (Ontario, Canada) we have what are called "community colleges" and also universities (a third group, called polytechnics is now officially considered a university). An engineer would graduate from a university and receive a degree. Technicians and technologists would graduate from a community college and receive diplomas. The difference between a technician and a technologist would be the latter is a longer program, and incorporates more theory - i.e., is closer to a traditional engineering program.
The "community colleges" were established (I think about 50 years
ago) to try to cover whatever post-secondary educational needs were not being served by the universities. They also do extensive continuing education (at night and on weekends) for people who want to update their knowledge. They were also given responsibility for the trades programs about 15 or 20 years ago with the objective of upgrading the skills of tradesmen, and to ensure an adequate supply of them.
The above describes the situation in the Province of Ontario. Each province has its own arrangements, and I haven't investigated what systems may be in effect elsewhere. However, since Ontario has about 40% of the population of the country (and the majority of the manufacturing industry), this covers a large percentage of the situation here.

Something I have noticed is that Americans will say they have "been to college" when they meant they have graduated from a university. Here, we say "university" when we mean university, and "college" when we mean college. I am not sure if the US also has a system equivalent to our community colleges and if so, how they designate graduates of them.


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

 

> >Technicians generally develop their skill through technical colleges,
> >as maintenance personnel in the military, or most frequently, just by
> >figuring it out on their own. I am not aware of any license or
> >certificate that stamps someone as a technician.

I'm not sure what "stamps someone as a technician" exactly means and I don't know if the poster intended this statement in a negative sense. In a positive sense, ISA has a technician certification program for control system technicians(www.isa.org) and there are other organizations that also provide certifications such as the National Institute for Certification of Engineering Technologies(NICET - http://www.nicet.org/), the Alberta Society of Engineering Technologist(ASET - Alberta Canada - http://www.aset.ab.ca/), the International Society of Certified Electronics Technicians(http://www.iscet.org), the Canadian Council of Technicians and Technologists (CCTT - http://www.cctt.ca/), the National Association of Radio and Telecommunications Engineers (NARTE - http://www.narte.org/), and National Association of Industrial Technologists (NAIT -
http://www.nait.org/)

It also appears that certification is becoming increasing attractive to employers and positive addition to one's resume.

There is also a U.S. organization - American Society of Certified Engineering Technicians
(http://www.ascet.org/)

Bill Mostia
===========================================
William(Bill) L. Mostia, Jr. PE
Independent I & E Consultant
WLM Engineering Co.
P.O. Box 1129
Kemah, TX 77565
[email protected]
281-334-3169
These opinions are my own and are offered on the basis of Caveat Emptor.

 

Bruce Durdle:
> >"Top-down problem analysis - bottom-up program writing".
...
> >Again I think the manufacturer's courses have a lot of responsibility
> >here, and, traditionally, before simulation tools became available,
> >the only way to try things out was to connect on tho a PLC and see
> >what the more complex instructions actually did.

Michael Griffin:
> The manufacturer's courses are not intended to teach people the proper
> way to design and write a program. They are just intended to teach how
> their particular software and hardware work. They aren't there to
> provide a general education - people need to go see you for that.

Hmm, thinking we ought to do better than that, I went and added a chapter to the draft MAT LinuxPLC manual talking about that... I wonder to what extent it's possible to cover it like that, though.

(http://mat.sf.net/manual/program/intro.html and follow the right-arrows.)


I don't even know how to cover it in a proper course - even a term-long project will be far too small to properly illustrate the problems. Many of the design documents become trivial, and therefore tiresome, their purpose unclear. At best, students will become mildly resentful of the whole design thing.


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

 

At 22:32 30/12/01 +1100, Jiri Baum wrote:
(with regards to teaching software engineering)
<clip>
>Hmm, thinking we ought to do better than that, I went and added a
>chapter to the draft MAT LinuxPLC manual talking about that... I wonder
>to what extent it's possible to cover it like that, though.
<clip>

I think this sort of a subject would be better suited to a text book than a software manual. Of course it could be a text book with a copy of the "MAT" on a CD-ROM in the back of it.

>I don't even know how to cover it in a proper course - even a term-long
>project will be far too small to properly illustrate the problems. Many
>of the design documents become trivial, and therefore tiresome, their
>purpose unclear. At best, students will become mildly resentful of the
>whole design thing.
<clip>

Teaching it to students is education. Making sure they use it after they graduate is management. There were a lot of things I learned in school which I thought were useless. After I graduated, I found myself using them for things which my instructors never imagined existed.


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

 

> (with regards to teaching software engineering)
Jiri Baum:
> >Hmm, thinking we ought to do better than that, I went and added a
> >chapter to the draft MAT LinuxPLC manual talking about that...
...

Michael Griffin:
> I think this sort of a subject would be better suited to a text book
> than a software manual.

Yes, but we can at least touch upon it, and give those too rushed to learn it elsewhere at least some help. At the very least, we need to point it out to those who never knew it existed.

Besides, pragmatically speaking - I'm not in a position to put it in a textbook; I *am* in a position to put it in the MAT manual.

> >I don't even know how to cover it in a proper course - even a
> >term-long project will be far too small to properly illustrate the
> >problems.
...
> Teaching it to students is education. Making sure they use it after
> they graduate is management.

True - but it's good to have a textbook example. Here, one can't. Not a good one, anyway.

> There were a lot of things I learned in school which I thought were
> useless. After I graduated, I found myself using them for things which
> my instructors never imagined existed.

Isn't that the truth... (Though I suspect the instructors may well have imagined them, or could have; there just wasn't room in the course to talk about it, or any reasonable way of passing it across.)


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

 

Hmmm, it seems like more than one person here misses one point
- you don't have to know C/C++/basic/pascal to program in ladder
- you don't have to know ladder to program in C/C++/etc

Some persons (like myself) need to know both, but not everyone making programs.


Someone quite famous programmer (could be Larry Wall but I am not sure) said something like "A programming language not changing the way you think is not worth learning"

The way to think in C and ladder are really different, in ladder you think like an electican would if the program would be solved with relays. You think in logical operations all occuring at the same time parallel. In C you think do that, do that, do that.... instructions executed after each other, possibly repeated.

In SFC you think let the machine do this, wait for that, let the machine do this, wait for that.

The fact that you can use one language to actually implement the thoughts made in another don't have anything at all to do with this - it is the way you think being the important.

Most machines is easiest programmed in either ladder or SFC or a combination of these, the program editor is probably easiest done in C++, the electrican is probably the best one (efter proper education - of course) to make the ladder program for the machine and to maintain it, he/she might need help with some parts of more procedural nature, but as someone said - they are quite rare in those programs. The computer programmers should not make the machine control, because they know C/C++, not ladder - ie a completely different way to think.


I - for one - know C, C++, ladder, SFC, and our own language we use to make our courses, all of these require completely different ways to think about a problem. Some problems can be solved relatively easy in more than one language - but the solution does not necesarily look the same and the way to think about the solution
are quite often completely different - and last some problems are better solved in some languages - no problem is as easy to solve in
all of them.


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

Hello List,

Johan Bengtsson wrote:

LM> Someone quite famous programmer (could be Larry Wall but I am not
LM> sure) said something like "A programming language not changing the
LM> way you think is not worth learning"
[...]

???

A programming language changing the way of thinking the problem demands is not worth learning.

(to be on a safe side...
if you will want to make a reference to it, my name is Vladimir E. Zyubin)

--
Best regards,
Vladimir

 

> A programming language changing the way of thinking the problem
> demands is not worth learning.
>
> (to be on a safe side...
> if you will want to make a reference to it, my name is Vladimir E.
> Zyubin)

Ah, but "the way of thinking the problem demands" may not be obvious. "If all you have is a hammer, all problems tend to look like nails."

Learning languages that force you to change how you look at problems gives you more options in the future no matter what problem/tool set you're faced with.

Dan Pierson

 

Sorry to get back to this topic but it's (supposedly) been "summer holiday" time here ...

One problem that I see is that most electrotechnology courses are solution-focused, whereas the work in industry is problem-focused. The typical industry practitioner has to firstly determine what the REAL problem is, and in many cases say its got nothing to do with the
instruments or controls - how many of our complex control solutions are there only to patch up a terrible process design? But that's a whole new
can of worms.

We not only need to teach all the tools (to pick up an analogy from another thread) but also all the building materials. Yes you _can_ build a nice shelter out of lap-tops, as well as use one as a hammer, but it is much easier, more effective and less damaging on the laptop to use canvas, corrugated iron, or wood. There is still a place out there for pneumatic controls, and also for simple single-loop controllers, not connected to anything - and there is a place for multi-variable control strategies with all the bells and whistles.

I am fortunate in one respect in that I am the IMC department at my local tech. It is not satisfying personaly in that it is difficult to keep up-to-date, but I have to make sure my students get exposed to all the possibilities. I cover the lot from basic measurement theory to advanced control systems and PLC applications design. I'm sure they get sick of me (I get sick of one or two of them) but at least I can make sure they cover all the technologies they need. I am also sufficiently involved as an independent contractor with local industry to be able to keep my material relevant. Probably not the best from the educatinal theorists' point of
view!

The problem is not one of software design skills, or even control systems skills - it is one of problem solving in its most general sense. I find IEC 61508, inerpreted very broadly, gives an excellent framework to buiild a design course around. It's all there - the project lifecycle sets out the basic stages in the design exercise, there is recognition that they need to consider appropriate technologies for each aspect of the design, and the testing etc is also well covered.

My present approach is exactly as you describe - I give a small chunk of a typical industrial project to the stiudents at the beginning of the year (2nd year of a 2-year "technician engineer" course) and this is used extensively for project work throughout the year. So they start off with a P&I D and learn how to interpret that, prepare spec sheets for various instruments, size orifice plates and control valves, etc. Then they end up
deciding how to implement the controls, preparing writing drawings for a PLC, and writing chunks of PLC code.

However, at least 80% of IMC design work at this level is grunt stuff -
preparing wiring schedules, associated loop drawings, etc, as well as entering scads of info into data bases. It's a matter of drawing the line so they get a good idea of what the work involves (warts and all) as well as spend their time as productively as possible learning useful skills.

The "software engineering" problem can be extended to much of the electrotech field - after all, most electrotech design involves selecting
components, checking their specifications and detailed performance capabilities, interfacing requirements etc, and then integrating them into
a coherent and functining whole that can be built, tested, and survive the industrial environment. This applies to electronics hardware design as well as software, and to full-scale systems as well as chip-level stuff.

A solution-focused aproach usually means that a graduate is familiar with only a limited set of the tools needed for the job, and even less familiar with the properties of many of the "construction materials" available for
use. The result is often what we see on this group. However, at an extreme we get the "software virtuosos" who spend their time looking through the manual and then insist on trying out the instruction they found last night
in the project they're designing today - whether it actually achieves anything or not. At a less extreme level we have those who insist on using
technology X for everything. There is a difference between the in-plant practitioner, who has to face up to the phone calls at 3 am, the sales guy who is trying to maximise his commission, and the academic who is an expert
in a very limited area and genuinely cannot imagine alternative ways of doing things. Unfortunately, the sales guys have usually got the ear of the people withb the chequebooks, and new entrants to industry have often not been exposed to the full breadth of technology during their training.


Bruce.

 

Michael,

I don't know about "method" but I have based a lot of my work (mainly in process industries but with some machine operation) along the followiing
lines:

*************************************************
Overview - brief 2-line description of process stage and its intent

Raw Materials - what and where from
Product - what and where to
Energy - what and where from, with operational limits such as minimum air pressures

Sensors - tag, descriptor, brief specifications
Actuators - tag, descriptor, brief specifications
( These should be scheduled so that they can be expanded into eg a PLC I/O map with minimum rework. Also keep associated elements together so that the correctness of relationships can be verified - so a conveyor speed measured by tacho, involving raw speed, tacho speed, and final indication/switching point are all adjacent)

Power-down state specification (for multiple energy sources, a separate table for each)

Operating cycle - how is overall process started and stopped - with a step that is part of a large operation this could be by a reference to the overall operation start.

Operating sequence - what happens when in normal operation. Keep this to no more than about 5 or 6 steps - if more complex, break steps down into sub-steps for separate treatment (top-down design)

Expected abnormalities - what are the usual problems and how are they to be detected and dealt with - eg faulty raw material or incorrect assembly
Unexpected abnormalities ditto -
(The first are sufficiently common you have to plan for them - the second are maybes that nevertheless need to be considered, such as belt break)

Interactions with other steps in the process - both material and by signal
- signals need to be specified in detail, especially where multi-supplier controacts are involved

Safety issues

Operational issues - eg how is process monitored for production reporting

Maintenance issues - what provision is needed for routine maintenance activities

Testing

Documents and drawing reference list.

************************************

I hope this is of use to you and would welcome any feedback and perhaps an example or two of how it can be adapted to fit into your environment.

Walt Boyes - if you're out there, perhaps ISA can put together a standard on this topic!

Bruce.

 

Hello List,

On Friday, January 11, 2002, 10:34:27 PM, List Manager <[email protected]> wrote:

LM> -----------Forwarded message-----------
LM> From: [email protected] (Dan L. Pierson)
LM> To: [email protected]
LM> Subject: Re: LANG: Demarcation (was: STL x Ladder)

LM> List Manager <[email protected]> writes:

>> A programming language changing the way of thinking the problem
>> demands is not worth learning.
>>
>> (to be on a safe side...
>> if you will want to make a reference to it, my name is Vladimir E.
>> Zyubin)

LM> Ah, but "the way of thinking the problem demands" may not be
LM> obvious. "If all you have is a hammer, all problems tend to look
LM> like nails."

1. Yes. The way may not be obvious. And one of the first steps of the development process ought to be to define the right way...

2. ... it allows the developers to realize: they have to change the hammer for screwdriver...

LM> Learning languages that force you to change how you look at problems
LM> gives you more options in the future no matter what problem/tool set
LM> you're faced with.

There are _thousands_ programming languages... most of them demands a specific way of thinking... to _learn_ all of them is not the optimal way to become a broad-minded person. IMO. To be aware of the concepts is a more time-consuming approach.

Here is the standard approach to solve the problem:
1. to understand the task
2. to choose the right tool

...to understand that the LD does not allow me to solve the problem, I need no info about the operators' notation.

or -|/|- , or -|\|-, or other obscure circles and mysterious boxes...

With kind regards. Vladimir

 

>Someone quite famous programmer (could be Larry Wall but I am not sure)
>said something like "A programming language not changing the way you
>think is not worth learning"


Yes, I agree with this. For an example, try learning FORTH. It is like no other language. I cannot get used to it, but I am a much better programmer as a result of trying. Read "Thinking Forth" and you will learn much about general programming practices, especially for developing reusable code. They call it "factoring".

I am currently working on TCL/TK. It is a very impressive language for building graphical programs. TK is very clever.

Bill Sturm