[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HELP - pushing Inferno as a solution

i forwarded the two messages talking about ladder logic
to a friend who's been working on ladder logic compilers,
and this was his reply.

Date: Thu, 27 Mar 1997 11:56:04 GMT
From: Steve_Kilbane@cegelecproj.co.uk
Message-Id: <199703271156.LAA01401@phantom.cegelecproj.co.uk>
Subject: Re: ladder logic and limbo

Here's a response. Feel free to forward it to the list, although it's
a bit rambly..

>From ClarkGR@aol.com
> > 	>>> With all the new stuff out there, is my company specing the right
> > hardware and software?

For now, probably, although see below for language issues.

> > Will we remain competitive with utilization of the
> > Allen Bradley stuff?

Certainly. AB, ABB, Siemens, etc. are industry standards, AFAIK, and
aren't going to disappear any time soon.

> > Should we give serious consideration to some of the
> > newer technology?

Yep, but your main issue will be with the user interfaces, rather
than with the control side. That, and how you actually develop your

> > Could Inferno (and custom applications in Limbo) improve
> > our performance,

native, quite possibily, but there are trade-offs - see below.

> > or perhaps lower our cost to the customers?

well, that depends on how much you sink in the development budget

> > Could Inferno
> > provide a better foundation for the necessary integration work?

Pass. If you're talking about different components of your control
system talking together, then quite possibly. But then, there are
a lot of developments going on in the automation arena that might
get in your way. How do you feel like writing a FIP driver for Inferno?

If you're talking about interfacing with controllers themselves, then
I'd forget it.

> > Are the AB
> > controllers (and others in that market) so proprietary in design that nothing
> > else would work with them?

This is near enough the case. PLCs are extremely proprietary beasts.

> > Would a new controller design be necessary.

I'd say so, and that might scare your customers.

> >  Could Inferno provide controller manufacturers an opportunity to reduce the
> > high cost of these devices?  Will AB respond to this with an offer for joint
> > venture with Lucent?  (OK, maybe I'm getting carried away with that last
> > one.)

You're pushing the barrel out, aren't you? :-) I think that controller vendors
would have to consider that one themselves.

> > GOD ... I hope someone can tell me there really is
> > something other than PLC5 "ladder logic" (wiring diagrams masquerading as
> > code)!!

There is, but it's still pretty sick: IEC1131 and its ilk.

> > But of course, we must maintain many sites
> > where there are no programmers on site.

Plus, I imagine, supporting the existing non-programmers that you have.

For those who don't know, here's the deal on PLCs. At the basic level,
a PLC has a single program which is a list of instructions, which generally
read data from one "table", modify it a bit, and store it in another
"table" - tables being arrays of fixed size and simple type, usually
something like 16-bit integers or reals.

The instructions are in "ladder" code, because it's based on wiring
diagrams, with power rails down either side, and wires going from one
to the other, with coils, switches, that sort of thing. Loops, branches,
subroutines, etc. aren't there, although you can "switch off" chunks
of code, so there's the effect of a skip forward.

That's basic ladder. Every vendor has their own variation, to add
value in their own way.

The PLC runs the program in a loop of defined interval - a "scan". Just before
running the loop, it reads a bucket-load of data from inputs from
plant equipment, and makes this available in tables. The program
is run once, from top to bottom, and then the PLC copies another
wodge of data from other tables to the outputs. Pause a little bit,
then repeat.

There are good parts to this system:
	- you don't need software engineers to write ladder code.
	old hardware engineers seem quite happy with it.
	- the process has a fixed, defined, max run-time - you can
	work this out in advance.
	- the memory usage is not only static, but decided by the
	engineer, not a compiler. The program deals only with
	table indices, no pointers.

and the bad parts:
	- PLCs are usually controlling concurrent systems, but the
	people who program them don't know anything about concurrent
	system theory, and don't have the tools to program them if
	they did.
	- due to lack of procedures, if you want to do the same thing
	1000 times, you write it 1000 times...
	- Because PLCs are such a small market in comparison to the
	rest of the computer industry, the software tools tend to
	lag quite heavily, and openess is nearly non-existent.

There's a push to fix a lot of this. The IEC-1131 standard defines
the PLC world "openly", and part 3 describes languages. There's a
ladder variant, an assembler variant, something that looks a bit
like Pascal, and two graphical languages that look like state
machines and a IC wiring diagrams, respectively. These are all
improvements over the current state of the art, but as languages
go, they're pretty horrendous beasts. Clark's company should
be looking at them because they're like ISO-9000 - you think it's
lousy, but your customers want you to support it anyway.

The problem with the IEC-1131 system is that they still interpret
a PLC to be scan-based, which isn't going to do much good if you
want to program your control system in limbo.

You could take the route of producing your own controller, which
runs Inferno. Your problem would be to sell it to your customers.
Depending on who they are, they'll either just want a system that
does the job, or they'll want one that's based on hardware they
trust, which could sink your controller.

More interestingly, it's not uncommon for a control system to be
sold, including the source to it: the customer buys the rights to
maintain and modify the system themselves, which means that they
will want to understand the language its written in.

Above all, it's the closed attitude of the PLC vendors that is
the main problem. Having been involved in a project to produce
IEC-1131-based development tools for a number of PLCs, I was
amazed to discover that some vendors refuse to give out any
interfacing information whatsoever. You either use their programming
tools, or you use a different controller. In the end, it was
the lack of interfacing specs that caused the project to die.
That was a couple of years ago, which in this industry is one
"forever", so things might be different now.

All opinions are mine, and have no relation to those of my employer.