The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
Subject: Re: Avoiding PLCs
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
Date: Thu, 17 Oct 2002 10:16:17 +0100
NNTP-Posting-Date: Thu, 17 Oct 2002 10:16:13 BST
Organization: ntlworld News Service
As I originally said:
"The reasons users want you to use 'the make of controller already in use by
them' are sensible - they want to reduce their training and maintenance
costs. Using another type of controller will not help those users."
That has been confirmed I think by many responders.
I went on to say:
"I suggest that you produce a detailed but system independent functional
specification that can then be implemented on any suitable PLC. It is good
practise anyway, and you can use an IEC-61131 type approach for this
functional specification so that it can be easily implemented on an
IEC-61131 type PLC."
Let me explain this a bit more. The big problem that I have experienced over
and over with equipment supplied with embedded controllers (PLC, PC,
Chips-R-Us or whatever) is poor design documentation. This problem is
particularly acute for the pharmaceutical industry due the the need for
validation. There is an army of people working to reverse engineer the
design documentation from the PLC software provided by such suppliers in
order to be able to validate the applications. This should not be happening,
but it is.
I really believe that given good enough design documentation (And I mean
System Independent design) the generation of the actual software is not a
big issue. And of course there are many systems integrators who know AB,
Siemens, Modicon or whatever extremely well.
So I suggest that equipment suppliers should concentrate on producing system
independent Functional Requirements specifications and then get SI's who
know the particular PLC do the implementation. It will probably even reduce
the cost in the long term.
"bob peterson" wrote in message
> Hi Rufus.
> The real issue is what the end user wants and is willing to accept,
> not what the vender wants to supply.
> Venders who try to convince end users to accept something non-standard
> are unlikely to get much of a hearing, and are almost always doomed
> when it comes to getting an order.
> Do yourself a favor and give them what they want, or they will go
> "Rufus V. Smith" wrote in message
> > "Reed Blake" wrote in message
> > >
> > > "JohnS" wrote in message
> > > news:...
> > > > We have run into a problem, hope someone here can make a helpful
> > > > suggestion! We have a digital control system which is fairly easily
> > > > using a plc. (Lots of interlock logic, timers, 4/20 mA circuits, 4
> > > > display, etc) Unfortunately every customer then seems to insist that
> > > > build using the make of controller already in use by them. In order
> > avoid
> > > > this I am looking for modular electronic systems that we can program
> > or
> > > > whatever so we can avoid using a PLC, but still have the flexibility
> > add
> > > > I/O etc as required.
> > >
> > > Check out the ICL-4300 from Industrial Control Links. I haven't used
> > > researched it for a project a few years ago.
> > > http://www.iclinks.com/Products/IntelligentRtu/IntelligentRtu.html
> > >
> > > You could also use a National Instruments FieldPoint system, with one
> > > their intelligent controllers.
> > > http://www.ni.com
> > >
> > If you want to go SBC (single board computer) you can check out:
> > http://sourceforge.net/projects/mat/
> > Which is an attempt to create an Open Source PLC-Like system to
> > run on Linux.
> > One interesting commercial system (which may be overkill):
> > www.mnrcan.com
> > Rufus
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup