# Connecting a production monitoring system

M

M

#### Mark Wells

Michael,

Hopefully you'll get lots of responses in appreciation for all your input to
other people's problems!

Since the equipment in your plant is "constantly changing and moving", I
wouldn't recommend using PLC's as data concentrators. You will have to map
the addresses from the PLC's you want to monitor to the concentrator PLC.
You will then have to map the addresses from the concentrator PLC to the OPC
server. These mappings will have to be documented, and then everything may
have to be changed when you move or change a PLC. As well, it is unlikely
that any single type of PLC will be able to incorporate all the existing and
future protocols that you may require. While Siemens PLC's will definitely
support the many flavours of Profibus, they are unlikely to support
ControlNet or Mitsubishi's MelsecNet.

Although you had a bad experience with a Siemens rep trying to sell you
WinCC, I'd like to suggest that you use a product like Wonderware or FIX or
Genesis to collect the data. Although OPC is starting to catch on, there
are still PLC protocols that don't have an OPC server, and you'll still want
to talk to these PLC's. The data collected by one of these commercial SCADA
packages can simply be passed on to any application you have on your
pretty well all of the present and future PLC's, without having to find an
OPC server.

As for the limited number of I/O that you were going to collect with ASI, I
would recommend getting a small, network-aware PLC for this job. Since you
seem to have a lot of Siemens PLC's, I would recommend something like an
S7-215 with a Profibus DP connection to the SCADA node . You could choose
to install a Profibus-DP card in the SCADA node and get the I/O directly
(like from Siemens ET-200 I/O), but I wouldn't recommend it.

I know this isn't what you wanted to hear, but I have worked with systems
that have PLC's as data concentrators, computers as data concentrators, and
computers with custom software interfaces to PLC's, and I think you'll want
to avoid all three. It may seem like a waste of money to pay $10,000 for FIX or Genesis or Wonderware simply to get the PLC information, but you'll recover your costs in reduced engineering time and faster time to market for new production lines. Sincerely, Mark Wells M Systems 206 Bloor Street West, Suite 7 Toronto, Ontario, Canada M5S 1T8 Ph. 800-265-1771 Fax. 416-352-5206 E #### Enrico Guasco Hi Mr.Griffin, I don't know whether you'd like to talk about a soft logic for this project, but I'd take a look to SoftPLC at www.SoftPLC.com and think about the possibility to use some SoftPLCs with web-server add-on option as concentrators or as PLCs. Of course you'll have to forget about OPCs, you'll be able to access to any datatable of any of the SoftPLCs from any web browser from any PC in the network...and speed it up with a 100Mbs Ethernet. I've done a similar application in north Italy and it works just fine, in that case I'm talking about a single SoftPLC accessed from three PCs in the network but the application has really been very simple. If you need further infos please feel free to contact me directly. Best regards Enrico Guasco D #### Dave Hurd Michael, We've implemented a similar system in each of our manufacturing plants. In most cases the site has decided upon (2) PLCs as data concentrators collecting data from over 100 PLCs over the proprietary comm. network supplied by the PLC manufacturer. The data concentrators then communicate to the server (Running under UNIX) via Ethernet over an isolated sub-LAN. The data concentrator updates approximately every second and the polling rate from the server is set at 3 seconds. Interestingly, one site chose to run Ethernet to each PLC and avoid the data concentrator, but after connecting about 80 PLCs the update time rose beyond acceptable limits. They have since installed an NT box as a data concentrator, split the Ethernet into several sub-buses, and have the server access the data in larger chunks from the data concentrator. In addition to the PLCs, data is also collected from inspection CMMs, operator input, production scheduling systems, and mainframe systems either directly through the Ethernet sub-LAN or by serial comm. through the PLCs. Feel free to contact me directly for more info. Hope this helps, Dave Hurd Systems Engineer GE Appliances Louisville, KY A #### Albert Phair Michael I came across a company "Specter Instruments" while at a seminar at CB Engineering in Toronto (it was a while back). At that time I was only interested in their 911 product, but listened to their spiel on PINs (think they refer to them as protocol interface modules) I recall they bragged about many different protocols with peer to peer communications. Once programmed these devices were reported to operate locally without intervention from a host or if required they would communicate with the host. Specter's web site is http://www.specterinstruments.com/ CB Engineering's web site is http://www.cbeast.com Note: I have not used this equipment, but from what you describe it could be a component which would fit your system. Dennis [email protected] M #### Manny Hellstern Michael: Another alternative you might look at is to use a historian package that utilizes different "collectors" to interface with various protocol. I know that Foxboro has a product called FoxHistory that runs on a PC and has various collectors available. This Historian has both a near real time portion from which you can get dynamic data as well as a historical portion for long term retrieval. The update rate for the near real time portion can be different from that of the long term portion. This particular product may not be mature enough for what you want, but there may be other main stream historian packages out there that could work. Just another avenue to pursue aside from the suggestion of using something like Wonderware - which by the way, I agree is a possible solution. Regards Manny Hellstern Mustang Engineering Houston, Tx 713-215-8380 M #### Michael Griffin At 14:08 30/11/99 -0500, Mark Wells wrote: <clip> >Since the equipment in your plant is "constantly changing and moving", I >wouldn't recommend using PLC's as data concentrators. You will have to map >the addresses from the PLC's you want to monitor to the concentrator PLC. >You will then have to map the addresses from the concentrator PLC to the OPC >server. These mappings will have to be documented, and then everything may >have to be changed when you move or change a PLC. The mappings have to be documented regardless of how the system is constructed. I think though I wasn't clear enough in my original message. Typically, an entire line is moved in one piece between different locations. For example, last weekend one of our lines was moved from the back of the plant to a spot just outside my office. Next weekend another line will join it. I had envisioned one data concentrator for each line (since each line is a natural unit of equipment). In this case, no changes to the production data system would have been required, only a different network drop. The point though of the data concentrators is to hide as much of the low level differences of each line as possible from the higher levels of the production data system. It also helps to localise any network problems. It also acts as a translator from an industrial network (e.g. Profibus L2) to Ethernet TCP. In most cases, its job will be fairly simple. If equipment is added to or removed from a line, then the application software will have to be reconfigured anyway. >As well, it is unlikely >that any single type of PLC will be able to incorporate all the existing and >future protocols that you may require. While Siemens PLC's will definitely >support the many flavours of Profibus, they are unlikely to support >ControlNet or Mitsubishi's MelsecNet. In some cases I may have to use a PC as a data concentrator. Most of the connections to be made though are pretty straight forward. Of the equipment I would be interested in monitoring, I have about 5% AB, 10% simple machines with a mixture of very low end PLCs, and 85% Siemens S5, the majority with Profibus L2 already wired up and waiting (we have been wanting to do this for some years now). >Although you had a bad experience with a Siemens rep trying to sell you >WinCC, I'd like to suggest that you use a product like Wonderware or FIX or >Genesis to collect the data. The Siemens guy from Toronto came to visit me last Thursday, and tried to pitch WinCC again. I did manage to squeeze in some questions about the different flavours of Profibus L2, and what the differences between S5 and S7 implementations are. He is going to get back to me on this issue (it turns out he wasn't the guy I really needed to talk to after all). However, I did let him show me a WinCC demo as his reward for looking into my questions, and now I am more convinced than ever that WinCC (or Wonderware, or FIX, etc.) although a very nice product when used as intended, is *not* what I need for my application, at least as far as displaying data and reports are concerned. He did suggest though that I could use WinCC as an OPC server without using the display functions. I am still not sure though why I would want to do this when I could just use an OPC server as an OPC server (Siemens and other companies sell those too). >Although OPC is starting to catch on, there >are still PLC protocols that don't have an OPC server, and you'll still want >to talk to these PLC's. <clip> So far though, for all the major equipment I am interested in there are OPC servers (Siemens and Allen Bradley support their own hardware). This covers just about everything that I would want to connect anyway. Unless I hear that there are specific problems with particular OPC servers (perhaps I should ask people here on the list before I make any final decisions on OPC) I still don't understand why I shouldn't use them. Perhaps I am overlooking something though. >As for the limited number of I/O that you were going to collect with ASI, I >would recommend getting a small, network-aware PLC for this job. Since you >seem to have a lot of Siemens PLC's, I would recommend something like an >S7-215 with a Profibus DP connection to the SCADA node. <clip> The S7-215 is dead (along with the rest of the S7-21x series). The new S7-22x series (some very nice improvements in them) don't include an equivalent to the S7-215 (the 215 didn't sell very well). There is however a DP slave module that could be plugged into the existing S7-214s and S7-216s we have (provided we have the panel space). I don't know if a DP slave module is planned for the new S7-22x (the old I/O is not compatable with the new CPUs). However, the new models can act as MPI slaves at high speeds, which means they can act as slaves to the S7-300's native networking mode. I have considered this though and may do this in certain applications, but I also looked at how we are using this PLC in most applications. Most are used in very simple machines which don't have the different operating modes and fault decoding present in the types of machines where we have been using S5-95U and S5-115U PLCs. This means that there is much less information to be extracted to begin with unless I intend major re-writes of the PLC programs (which I don't). I have worked out a series of logic equations based on the possible states and operating modes of typical machines, and I find that 4 bits can characterise these simple machines quite nicely while keeping things fairly cheap and simple. I don't have any definite plans yet, but I am keeping this as an option. >I know this isn't what you wanted to hear, but I have worked with systems >that have PLC's as data concentrators, computers as data concentrators, and >computers with custom software interfaces to PLC's, and I think you'll want >to avoid all three. It may seem like a waste of money to pay$10,000 for
>FIX or Genesis or Wonderware simply to get the PLC information, but you'll
>recover your costs in reduced engineering time and faster time to market for
>new production lines.
<clip>
What I wanted to hear was your opinion; I don't have any fixed ideas
of my own yet other than the two I am about to list. I started looking at
this idea because:
a) I want to put the application server in the computer network
room. This way I can dump the responsibility of looking after that hardware
on our computer department. I have enough problems of my own already without
baby sitting something as tempermental as a PC.
b) I didn't want to have to run Profibus cables all over the plant
in order to accomplish the previous point.

I have been told though that it is quite practical to use our
plant-wide ethernet backbone system (1 gigabit) to make this connection.
This is very convenient, and makes moving equipment much simpler. Now I may
not be an expert on networking, but I knew that you can't join an Ethernet
cable to a Profibus cable just by using a big knot. I need some hardware in
between, but it doesn't have to be exceptionally smart hardware. This is
where the idea for the data concentrator started.

Now, as I said before, we haven't definitely picked out the
application software, but on Wednesday I am going to another demo of a
package that looks quite interesting. It pulls the data from the PLC and
logs it as well as generating all the reports which are oriented towards the
type of industry I work in.
It sounds like it as easy to make the PLC connection configurations
with this software as it would be with an MMI package (I'm a bit fuzzy on
the details though - I haven't tried it for myself). As long as I have a
decent OPC server, I'm not sure just exactly what WinCC (or Wonderware,
The company putting on the demo should be able to give me some
haven't done anything involving Siemens hardware though, which is why I was
conducting some research ahead of time.

keeping the connection direct. Perhaps I should be looking at something like
the SST X-Link (or something on a similar principle) which simply translates
from one network to another. I've no experience with something like this
either, but if it can make the Ethernet to Profibus transition transparent
to either end, then the application software may be able to address the
machine PLCs directly. I'm pretty sure this won't work for every
application, but it may work for 80% of them. It also looks to be compact
enough to fit into some of the tight spaces I will have to work with on some
lines.

**********************
Michael Griffin
[email protected]

M

#### Michael Griffin

At 11:48 01/12/99 -0500, Hurd, David L wrote:
<clip>
>We've implemented a similar system in each of our manufacturing plants. In
>most cases the site has decided upon (2) PLCs as data concentrators
>collecting data from over 100 PLCs over the proprietary comm. network
>supplied by the PLC manufacturer.
<clip>
>The data concentrators then communicate to
>the server (Running under UNIX) via Ethernet over an isolated sub-LAN. The
>data concentrator updates approximately every second and the polling rate
>from the server is set at 3 seconds.
<clip>
>Interestingly, one site chose to run
>Ethernet to each PLC and avoid the data concentrator, but after connecting
>about 80 PLCs the update time rose beyond acceptable limits.
<clip>
This is interesting. I am currently debating which of these two
routes to use in my application. I have a need for a system larger than
either of the ones you mentioned. It would be interesting to know where the
bottle neck was.
whether the OPC driver (or some other component) will prove to be a bottle neck.
For example, if I connect 250 machines, and poll each one at once
every 3 seconds for 50 bytes (including overhead) then that is 83 messages
per second. This amounts to 4167 bytes, or 33,333 bits per second each way.
Even if I am off by a factor of 2 or more in my estimate, this is
not a high data rate. However, it could be that the driver or some other
part of the computer system may not be able to handle large numbers of small
messages efficiently.

I could think of several places the bottle neck may be, including:
1) The application on the server
2) The driver (OPC or other)
3) The Ethernet driver or card
4) Some other component in the Ethernet system
5) The Ethernet card in the PLC (although this doesn't necessarily
make sense - the number of messages each card had to respond to didn't
increase on a per card basis)

Typical PC Ethernet systems are intended to handle small numbers of
large packets. The sort of application we are talking about constitutes
large numbers of small packets.

- Or, maybe the application or PLC communications driver on the PC
had a polling algorithm that required it to wait for a reply to each message
before it sent the next request. If so, then if the PLC cards were slow in
responding (they may have had to wait until the end of the PLC scan before
fetching the data) then the overall process would slow down.
For example, if each message took 50 msec for a response, and the PC
waited for a response before sending the next message then:
50 msec * 100 machines = 5 seconds

This is definitely another point for me to look into.

Albert Phair wrote:
<clip>
>I came across a company "Specter Instruments" while at a seminar at CB
>Engineering in Toronto (it was a while back). At that time I was only
>interested in their 911 product, but listened to their spiel on PINs =
>(think they refer to them as protocol interface modules) I recall they
>bragged about many different protocols with peer to peer communications.
>Once programmed these devices were reported to operate locally without
>intervention from a host or if required they would communicate with the
>host.
<clip>
I had a look at their web site. I don't think I saw quite what I was
looking for, which is a Profibus FMS (Siemens L2 for S5-95U flavour) to
Ethernet TCP/IP converter.

This raises another point. One possibility I am looking at (although
I shall keep in mind what David Hurd has told me above) is to use some sort
of protocol converter or gateway to pass the messages between Profibus and
Ethernet. I know that this sort of thing has been done.
The question though is *how* does this work? If I use a normal
Profibus OPC server, I would assume that it would want to talk to a Profibus
card. How do I convince it that the Profibus it wants is at the other end of
an Ethernet cable? In other words, are systems which use OPC server plus
Ethernet plus industrial bus (e.g. Profibus or other) just individual
generic components, or are these always a complete package? E.g. do you have
to buy the OPC server and Ethernet to Profibus gateway as a package from one
company?

As a final question, has anyone used an SS Technologies X-Link for
any purpose before? If so, what was your opinion of it? Does anyone know of
another equivalent that might suit my needs?

**********************
Michael Griffin
[email protected]
**********************

M

#### Michael Griffin

I made some further progress in my research for setting up a
communications system for a production data monitoring system, and I would
like to ask some further questions.
The first concerns a network gateway or translator. I talked to
someone at SS Technologies today, and got some rather interesting
information. They can connect Profibus FMS to Ethernet, but currently only
in a rather odd way. SST currently has Ethernet drivers for AB, GE, or
Modicon, but not Siemens. What I would do is to set up the system so that my
application software on the PC server would think it is talking to either an
AB, GE, or Modicon PLC. Then the X-Link box would translate both the network
protocols and PLC address messages so that the Siemens S5 PLC would get
messages formatted in its own desired fashion.
This sounds rather impressive if it works, but I would rather not do
anything that convoluted if possible, as it could get rather confusing.
I am interested in how typical systems work though. I understand
that Allen Bradley and Omron (among others) offer their own proprietary
gateway systems just for their own networks (which means I can't use them
for my own purposes). I don't know the actual names for this hardware. Has
anyone used them, and could they offer any comments on them? E.g.
1) Were they easy to set up and use?
2) What sort of configuration did you have to do?
3) Approximately how much do they sell for?

The second question is with regards to the cost of developing
screens with conventional MMI software (e.g. Wonderware and the like). There
was a discussion a while ago on this but I can't seem to find it. I am quite
convinced that this is NOT what I want to do for my project, but I would
like to get some rough estimates to help prove this.
The questions would center on the following:
1) What is a reasonable time estimate for an experience person to
create a simple screen comprising minimal graphics (e.g. a trend plot and a
few indicators), together with a dozen columns of numbers. Historical data
is to be logged and recalled. Also to be included is alarm logging and
recall, with various statistical measures to be applied to the alarms.
This would include designing, creating, configuring the addresses,
debugging, documentation, etc. Assume that someone else has provided you
with a written description of what the PLC addresses are that you need to use.
2) What would be reasonable estimate to create and configure a
system containing multiple screens like the one described above, when I
would want to have at least a half dozen similar screens for each of 250
machines (a total of at least 1500 screens). Assume such a system would then
need to be installed and tested on 2 dozen computers. Also assume that some
of the sets of screens would be identical, while others would have minor
variations. Also needed would be a simple and logical method of linking
screens to allow people to navigate through them.
I don't know if there are any short cuts which can be applied when
you need identical screens which access similar data from separate locations
(e.g. some sort of indirect indexed addressing). I don't have the experience
with MMI systems that someone who does this full time woud.

Now before anyone sends me a message telling me they would like to
build such a system for me (and I have received several already), my point
is to try to show the impracticality of this for our application. My own
estimates say so, and and I have received some advice from others which
confirms this.
If I assume an arbitrary average of 1 hour per screen, then:
1500 * 1 hour = 1500 hours
= 187.5 days
= 37.5 weeks
= a lot of time and money

Realistically, I think and average of 1 hour per screen is far too
small if each screen has to be created indepedantly, but I don't know what
the number should be. My reasons for not doing this involve more than just
cost (it wouldn't really do what I want), but I would like to make an
estimate none the less.

**********************
Michael Griffin
[email protected]
**********************

R

#### Rodney Stevens

At 10:59 PM 12/3/99 -0500, you wrote:

> Now before anyone sends me a message telling me they would like to
>build such a system for me (and I have received several already), my point
>is to try to show the impracticality of this for our application. My own
>estimates say so, and and I have received some advice from others which
>confirms this.
> If I assume an arbitrary average of 1 hour per screen, then:
> 1500 * 1 hour = 1500 hours
> = 187.5 days
> = 37.5 weeks
> = a lot of time and money
>
> Realistically, I think and average of 1 hour per screen is far too
>small if each screen has to be created indepedantly, but I don't know what
>the number should be. My reasons for not doing this involve more than just
>cost (it wouldn't really do what I want), but I would like to make an
>estimate none the less.

Your requirements would take someone a fair amount of time to do a
reasonable estimate especially if you whant to include documentation. I
would agree 1 hour is probably to small except for the usual Alarm and
Trend pages which are usually included as templets where you just fill in
the boxes. Custom screens could take up to a day. Even filling in the tag
data base takes a fair amount of time before you even start the interface
and writing code for custom variables take even more. I have experience
with Citect, not Wonderware, but I would assume that they are similar in
the design of screens.

Rodney Stevens

Email: [email protected]

Work Phone: 61 2 97106701
Work Fax: 61 2 97106789
Email: [email protected]

Elan SS s/e 45/7616
http://sites.netscape.net/rodjohnstevens/homepage

M

#### Mark Hutton

Whether or not you use a concentrator on each line, and whether or not you

Consider the following;

Standard DDE protocol servers, (e.g. from Wonderware or Kepware), allow the
connection of any DDE aware software. For example, (depending on performance
requirements) you could use a PC with an appropriately configured Excel work
book as a data concentrator, it may even suit the reports that you want to
generate.

Serial hubs can be connected to Ethernet making RS-232 connections and
RS-422/485 networks 'transportable'. Comtrol do some serial hubs, 4 to 32
ports I believe, see http://www.comtrol.com. These ports are addressable as
COM5 - Com??? though I believe that they are working on IP addressable
versions.

Regards
Mark

L

#### Lou York

Mike;

Wow that's alot.

We have used Allen-Bradley's ControlLogix Gateway. It allows gatewaying
modules from Prosoft to implement MODBUS networks with A-B PLC's. You
should be able to set up a Gateway in two days. You will probably need
help from their tech support. The cost for each module is about
$1,000.00 plus rack and power supply. For two network system you are looking at about$3,800.00.

As far as HMI packages - I am not exactly sure what you are looking for
but a screen like you described could be done in about an hour. If you
want to distribute the screens to users on an Intranet then there are a
lot of options. WonderWare and RSView32 both have client/server
packages. This allows for developing the screens for one machine and
allowing clients with MS I.E. or their client software to access the
screens. Citect also has some sort of distributed architecture but I am
not familiar with it.

One option that you may want to consider is a Web Server application.
You can bring your data into a Web Server and distribute the data via
"web pages" to clients.

The big issue to keep in mind is long term maintanence of the system.
If you use a canned HMI package to develop the system, the resource to
make modifications later are more readily available than if you
developed a custom application such as a Web Server.

Sincerely,

Lou York

V

#### Vincent QUILLET

Dear Michael,

I would ask me first how I can organize data in PLC memory especially with
similar type of data. This approach can cut down the development time of the
HMI=2E You will have structured easy to access PLC data because you will have
rules to access them=2E The communication between PLC and HMI developpers
will be easier too.

Secondly, I would consider object structures in the HMI development
software. A good HMI software (see Iconics for example) include object
concepts (ActiveX controls). Create your custom object library; you will be
able to drag and drop graphic objects or group of objects in the different
screens, including custom functionalities with Visual Basic for Application.
If part 1 (structured data in PLC) is well done, you won't have to do a big
configuration work, a lost of it is included in custom objects and
automatised at development time.

If any change is needed, this concept allow you to perform changes on a
single object or globally to a group of qualifying objects.

In manufacturing industries people always think about method to gain time
and avoid multiplicated errors that cost a lot.

New technologies are efficent to do that !

Hope this helps.

Vincent QUILLET

EDL ASAlog
Aix en Provence - France
New technologies for automation
T=E9l : +33(0)442 94 06 87
Fax : +33(0)442 94 06 88
e-mail : [email protected]=2Efr

J

#### John G. Boland

Hello, the list!

Warning: L O N G .

system, in small part:

<< (1) The first concerns a network gateway or translator. [SST] can connect
Profibus FMS to Ethernet [so] my application software on the PC server would
think it is talking to either an AB, GE, or Modicon PLC. Then the X-Link box
would translate both the network protocols and PLC address messages so that
the Siemens S5 PLC would get messages formatted in its own desired fashion.

(2) The second question [concerns] the cost of developing screens with
conventional MMI software (e.g. Wonderware and the like). There was a
discussion a while ago on this but I can't seem to find it. I am quite
convinced that this is NOT what I want to do for my project.

[Both involve the cost and time for] designing, creating, configuring the
addresses, debugging, documentation, etc. Assume that someone else has
provided you with a written description of what the PLC addresses are that
you need to use. >>

Michael, if I understand correctly, there are a couple of hundred PLCs of
various fruits and flavors with decent production rates. The production
reporting will be done at a "higher" level, not as a requirement for an HMI -
which you do not really want.

It strikes me that *at least one* way of doing this is to build ring buffer
code for each type of PLC, so the PLC itself can collect and time stamp its
production records. The code would be identical in all PLCs of that kind, and
functionally equivalent even between breeds of PLCs. Can be subcontracted.

The data structure would be identical for each record in any PLC's ring
buffer, regardless of the PLC, with DateTime, Machine_Number, Variable_Name,
and Data_Value (can be multiple if required) fields. This can eliminate a lot
of editing at higher levels, since (with *any* luck) only a machine number
may change.

Dedicate a PC for each PLC network and/or subdivision of the facility - since
there is some concern about data transfer rates, anyway. The PC data
acquisition code would be virtually identical, tweaked for the PLC network
driver, and not required to be "real time" (PLEEEEZE, guys), since the PLCs
are doing the time stamping and the ring buffers prevent any data loss. The
PCs stuff the production monitoring system database of your choice, using
identical code, regardless of the subnet.

I would use a text (*.csv) "Machine_Number" to "PLC Address" lookup table for
each PC and read it in when a PC's data acquisition app boots, so maintenance
is pretty straight forward. Hard to beat Excel for generating that kind of
thing, IMHO.

The PCs don't really have to know anything about the data that they are
passing, and the top level database is receiving identical data structures,
so there should be minimal editing.

This way, too, you can use the "best of breed" for each PLC network driver,
and maintain any part of the system (above the PLC) without losing historical
data.

HTH

John G. Boland, president
VisiBit Corporation

M

#### Mark Hutton

I usually quote about a day per HMI screen, but the actual time taken on
each screen is entirely dependant on the complexity of the screen.

I reasonable rule of thumb is to associate the time with something you are
more familiar with, say drawing the required screen with Visio, SmartDraw or
AutoCAD (at a stretch even MS-Paint or PaintBrush), and adding on 50% for
connecting to the I/O. (To do the same thing for a report you might even try
doing it in Excel, but you may need to spend more on getting the right data
into the right fields). This would give you an estimate of the time taken to
actually do the screen, you need to add time for specification, design, test
(including user testing) and installation. Implementation usually takes no
more than 20 to 40% of the job.

The job will cost what it will cost, and, from what you have described so
far, is not going to be cheap in terms of pounds or dollars (it is up to
'you' to justify it in commercial terms).

You have not given away enough of the requirements to make a judgement on
whether or not a SCADA package is appropriate or not. It will often be the
easiest (though not the cheapest) way of getting the data from your PLCs
into a common computer database.

I have not actually worked on a system with the diversity of the one you are
describing, usually there are only one to three different types of PLC that

I am about to quote a job very similar to this one, so I will be following
this thread with interest. Let me know how the job turns out.

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
[email protected]

S

#### Steven

Me, too. How can i find out how this project turned out?

I

M

#### Michael Griffin

How it turned out was that my budget for the project evapourated at the last minute when I was about to start spending some serious money (just before Christmas). No one is spending any money right now that they can put off till later until we see what is happening with our customers. Oh well, maybe next year. ********************** Michael Griffin London, Ont. Canada [email protected] **********************

R

#### Rick Hudson

We put in a monitoring system in a textile mill which collected run, stop, production, efficiency, rate, ect data from plant floor machinery and placed the information in a SQL Server DB. There were about 1300 individual machines which were hooked to about 50 remote data nodes distributed across the plant floor. Each node supports from 20 to 40 machines. These machine generated signals are sent via the data nodes to a group of PC's. These nodes were sectioned off into groups - each group with a data collection PC (6 PC's in all - with 6 hot backups). These 6 active PC sent data to the main server. There is also a web server with serves data throughout the enterprise via ASP pages. The system produces about 1.2 million records at the main server every 24 hours. Rick Hudson [email protected] 704-640-5427