I have a project I am working on for which I would like some advice. The following is a rather lengthy letter, but I wanted to make sure that you have enough information to make an informed opinion. We are planning to implement a system which automatically monitors production equipment for values such as cycle time, down time, numbers and types of faults, etc. The type of production we do is assembly work, often involving parts transported on palletised conveyor systems. We have not made any definite decision on the software which will log the data and create and present the reports, but we are reviewing several very promising possibilities. I don't believe a typical MMI solution (e.g. Wonderware, etc.) is a good fit for us. Briefly though, at the highest level the system will be software which runs on a PC server and the results can be viewed through a web browser on any PC in the plant. This software will communicate with the manufacturing equipment via OPC server software. The server PC would preferably be located in our computer room with all the other network servers. At the lowest level, we will need to make certain programming changes in each PLC to create some times, counts, and alarms for this software to monitor. The majority of PLCs are Siemens S5, with some Siemens S7-200, and a small amount of AB, Omron, GE, etc. as well as a number of computers. We may decide to not monitor the really difficult cases. Our initial project is to create a prototype system with about 10 machines, but the system chosen must be scalable. Most of the Siemens S5 PLCs have a Profibus FMS port, as we have been considering doing this project for several years now and have been specifying our equipment accordingly. The problem I would like to discuss is how to make the connection between the two levels. I am strongly leaning towards interposing a "data concentrator" device between the two levels, with one data concentrator for each line or zone (about two dozen altogether). This device will be responsible for polling the individual PLCs and presenting the data in a consistent way for the top level. The equipment in the plant is constantly changing and moving, so I would like to isolate the top level to some extent from the differences in hardware. The data concentrator may also be called upon to perform some of the calculations (e.g. timing and some boolean logic). This may be especially useful with lines which require interfacing a variety of simpler devices which don't have good networking abilities. In this case we could use digital I/O (possibly using ASI) to get a limited amount of information. I would like this data concentrator to be readily available equipment that will be rugged, reliable, and consumes a minimal amount of space (cheap would be nice too of course). It should also be easy to program. I don't have any fixed ideas on what this device should be. One possibility which has been suggested is to use a Siemens S7-300 PLC with a Profibus card (to connect to those PLCs which have a Profibus port), and an Ethernet TCP card (to connect to the top level). The Ethernet TCP card may be able to connect to our existing office network backbone, which I believe has gigabit capacity. I would like to point out that no control functions are being contemplated, only monitoring. I am told that we have plenty of excess capacity on this backbone. All of the precision timing is being done at the PLC level (or in the data concentrator) so a high polling rate or deterministic response is not required. The purpose of connecting to this backbone is strictly one of convenience. The top level will poll the middle level at regular (settable) intervals. I expect to have the information required to calculate the amount of data traffic within a few weeks. One advantage this system may have is that it is a technology which is readily understandable to the type of people who will deal most directly with it (PLC programmers to implement the system in existing equipment, machine builders for new equipment). I intend to perform all the work for the initial system myself, but further implementation will be done by people we will hire for the job to work to our detailed spec (with the first system as an example). New lines will have this installed when they are built. I have spoken with our Siemens rep about this application. The local rep was very helpful and understands what I want to do, but he doesn't feel he has the necessary background to give me the best advice on this subject. He passed me on to someone at Siemens in Toronto. This second fellow unfortunately seems more interested in trying to sell me WinCC than in listening to what my real question is (which is how to make the connection in the middle using their hardware and software, regardless of what is at the upper end). Any advice or opinions on any of the above would be appreciated. I am not fixated on any particular solution, but I do want something that is simple, flexible, and reliable. Michael Griffin London, Ont. Canada email@example.com
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
computer. The advantage of this scenario is that you'll have access to
pretty well all of the present and future PLC's, without having to find an
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.
206 Bloor Street West, Suite 7
Toronto, Ontario, Canada M5S 1T8
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
If you need further infos please feel free to contact me directly.
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,
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
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
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.
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.
At 14:08 30/11/99 -0500, Mark Wells wrote:
>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.
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.
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.
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,
etc.) could add to this.
The company putting on the demo should be able to give me some
additional general application advice based on previous installations. They
haven't done anything involving Siemens hardware though, which is why I was
conducting some research ahead of time.
However, you did raise an interesting point about the advantages of
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
London, Ont. Canada
At 11:48 01/12/99 -0500, Hurd, David L wrote:
>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.
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.
Having read your message, I realise that I need to investigate
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
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:
>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
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
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?
London, Ont. Canada
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
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.
London, Ont. Canada
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
> 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.
Looks like you already have.
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.
Work Phone: 61 2 97106701
Work Fax: 61 2 97106789
Elan SS s/e 45/7616
Whether or not you use a concentrator on each line, and whether or not you
use a PLC or a PC with SCADA or non-SCADA application.
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
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
Wow that's alot.
We have used Allen-Bradley's ControlLogix Gateway. It allows gatewaying
DH+, Ethernet, and DeviceNet - Allen-Bradley systems. You can also buy
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.
Your comment about short cuts is very important.
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.
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 : vquillet@wanadoo=2Efr
Hello, the list!
Warning: L O N G .
Michael Griffin asks two further questions about a production data monitoring
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
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
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
John G. Boland, president
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.
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
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 firstname.lastname@example.org **********************
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@example.com 704-640-5427