I have a project that requires that data be collected for a large group
of chemical tanks that are currently isolated from the plant. Presently
the instrumentation and control is isolated in stand alone controllers.
We are an "Allen-Bradley" plant and it was suggested that I use a SLC
5/05 (simply because that is the De Facto standard) to receive the 4 -
20 mA signals (level, pressure, and pH) for the tanks. Approx. 74 analog
inputs will be required. Ethernet connectivity is what I'll use,
RSHistorian will collect and log the data.
I'm intrigued by the Micrologix 1500 and it's price compared to the SLC
solution. With IF4 cards and an ENI (Ethernet) card I think I can
achieve the objective at a reduced cost compared to the SLC platform.
The 12K user program memory is worrisome, but I'll only be scaling the
analog inputs and it's my guess that the Micrologix 1500 and the
required analog expansion cards would be an ideal cost effective
solution for the project.
Being unfamiliar with the Micrologix 1500 platform I'm wondering if
there are any "gotchas" I'm missing. Seems like a no brainer to me. Has
anybody else utilized the Micrologix for a similar project?
Thanks in advance,
Walkin' tall machine gun man
They spit on me in my homeland
I believe the micrologix supports only up to 16 I/O modules, which
gives you only 64 analog points. Also, you would have power supply
issues with the micrologix base unit, requiring multiple power
supplies in the I/O bank. The 1761-NET-ENI module will work fine, but
you are limited by a 19200 connection to the PLC.
When you compare the cost of 2 1769-IF4 modules to a 1746-NI8, the
cost per I/O point is close as well. If the scope of the project was
smaller, it would be beneficial to go with a micrologix system, but
with as large of a project as you are looking at, you should stick
with a SLC system.
Without any intention to question your choice, I would like to ask you
the following: have you ever considered an embedded PC based solution with
open-source/free based software? 74 inputs can be handled by such a beast.
And, presumably, such solution should be easier on the budget. I am aware
that this OSS/PC control is a relatively new thing, so one should be careful,
but would you please point out some reasons not to consider it, besides the
obvious company policy towards hardware standartization? Thank you very much.
My $0.02 worth:
I've been involved with imbedded controls for some time now, and one thing
that never seems to change is the seemingly irresistible lure of the
solution that involves the PC and some boards, or the really cheap and
oh-so-nice single board computer being sold by some guy/gal out of the
garage. It's really easy to lose sight of the advantages of using "standard"
hardware/software that someone can understand, maintain, and get ready help
with after the person/people who developed it are long gone. But it's a lot
easier to wrap one's head around the simple dollars-and-cents difference in
hardware cost than the "softer" costs involved with maintenance, realistic
usable lifetime, etc., so it often does happen, I believe to the ultimate
regret of the poor unknown soul who has to fix or understand it down the
Now, I would be about the last person to ever say that A-B hardware or
software is bargain-priced. However, they are a large presence in a lot of
places, they support most of their stuff (provide repair/replacement/etc)
for a very long time, and the odds of being able to find someone who can
understand and fix an A-B based system are a lot better than many other
possible choices of hardware. You just have to keep your eyes open and try
to think about all the consequences.
I agree with the previous comments about the limitations of the MLX1500,
that number of analog ins probably stretches its intended scope of
application. Just a general feel on my part, did not look at any specs or
run any numbers.
I have a reason(s). Who is in-house to support it when it goes down. What
happens when a card goes bad but is now obsolete and can't be replaced. Who is
going to perform any programming updates when they are needed, and they will be
needed. If you are willing to hire someone to perform the above you should be
fine. If not - Good Luck. You can send a guy to a training class covering the
programming and hardware. Then six months later call on him to fix a problem
and he will look like a deer in the headlights. It's like throwing a thimble of
water onto a raging fire. You will evetually put the fire out but how long will
Sorry - been there.
First of all, I would like to thank John and Mike for their insightful
responses. I have been looking into PC open source based solutions for
quite a while. However, my own (although successful) experience is limited to
research environments, where the budget is strict and flexibility is demanded,
and where such systems really help.
I appreciate your opinions because they contain constructive critisism and
show the feelings in the industry towards PC/OSS control.
Would I be wrong to summarize your responses saying that the main problems
are uncertainty (supplier goes out of business) and higher demand on in-house
staff? These two may be solved/alleviated by a system integrator that takes
the responsibility of setting up and maintaining and eventually
troubleshooting the system. Also, appropriate training should be provided
to the in-house personnel. Does it make sense or it is not worth the trouble
from an industrial standpoint?
What you say is true, but I think there are a few factors that would cause
1) Even the best system integrator that can provide installation, support,
troubleshooting, and whatnot may go out of business themselves, and the loss
of a supply source for replacement boards, etc. can't typically be overcome
by a single integrator - odds are pretty low that they would have the means
or knowledge to manufacture or repair io boards, etc., and even just
swapping out a PC chassis/mobo can sometimes result in unanticipated
problems due to BIOS differences and whatnot..of course even large
corporations like A-B are not immune from going out of business or
discontinuing products and leaving the end-user high and dry, but certainly
their odds are better - it's generally presented as at least part of "why
the cost is what it is (high)".
2) There are generally limits to what a typical current in-house staff
can/will handle in terms of knowledge acquisition. If one could somehow
accomplish, for example, a shift from a PLC environment to some sort of
PC-based open source controller solution across the board, it would still be
a big shift with a lot of the inevitable organizational inertia to change.
More realistic would probably be a mixed environment, with some
"traditional" equipment and some "new" equipment in different spots, which
is a lot tougher to keep sorted out, increases the chances of extended
downtimes, etc.. Thus usually organizations try to standardize on a vendor
or a type to minimize foul-ups due to someone not
realizing/knowing/remembering relevant things about the flavor of
controller/hardware/etc they are working with right now. It's probably not
optimum, but it probably is the path of least resistance to just have "all
the same stuff".
When talking about development/troubleshooting/etc, I think a big thing to
keep in mind is that in the academic environment, variable labor cost is
"cheap" and fixed hardware cost is "expensive". In the industrial
environment, it's pretty much just the opposite, especially since the cost
of development/troubleshooting labor time has more components than just
wages (lost production time, etc.). Other than the strict educational angle
of getting some experience with particular hardware, I would imagine that in
the academic environment the higher fixed cost PLC would hurt it severely in
a comparison with a PC-based open source approach that might require larger
amounts of labor effort to get the same task going, but that increased labor
is generally much lower cost overall when you have academics (grad
students?) doing the work.
Of course, no controller hardware/software is immune to "aging", and sooner
or later some sort of change/upgrade has to be undertaken. It's probably
logical to break it down to hardware and software, and many/most of the PLC
vendors out there offer some sort of soft plc that runs on PC hardware, but
priced so that they still make their "usual" profit (or more). Usually the
same/similar programming software is needed, plus the soft plc "engine" and
the semi-dedicated PC hardware to run it on, typically adding up to about
the same $$$ as the traditional solution, though in my experience execution
speed is lots higher running a soft plc on the PC hardware vs the hardware
equivalent (for example, A-B PLC5 vs the SoftLogix5 equivalent - this could
vary in different scenarios). Relative reliability is a whole different
discussion that I'll ignore.
I'd think that an open source approach to machine control ("Open PLC") at
this point is lots more subject/vulnerable to the capabilities of the
end-user than the traditional. I believe that such an approach is doable,
given the right people and capabilities, and I know such solutions are
running out there - but I think that plant managers overall tend to get
really nervous if they get the feeling that they could really be in a tight
spot if a few (or one) key individual(s) left to live on a desert island,
and they get that feeling a lot less with a bigger, more standard approach,
even if it is more expensive up front. It'll be interesting to see how the
open source/system area develops overall, be it Linux or an OpenPLC or
whatever, I would guess that it'll be coupled with the increasing general
technical capability/willingness of "all of us". In this example, it really
boils down to how much "difference" there is to an end user between buying a
replacement board and plugging it in to solve a problem, versus finding a
compatible replacement board, writing or modifying a driver or other source
code, and troubleshooting/supporting/publishing the result. And how commonly
available those skills are.
and that's about all I've got to say about that. :-)
When I was a system integrator I was always interested in economy and fit
the minimal plc to the application - and trying out things like imbedded
control and pc boards was interesting - and building our own controllers.
But, now I am the process control engineer for a plant and a day of downtime
is worth a couple of years salary. So I stick with common components with a
minimal of variety - the few bucks saved with various brands, etc cost more
than they save when it comes to having enough spare parts on hand as well as
my electricians knowing how to troubleshoot and get things moving again.
I suggest that if you use the slc 5/05 throughout your facility then you
should stick with that one. You may save a couple bucks with the 1500 but
its a whole new thing that you have to learn about and worry about design
and spare parts and supporting it. You should look at the big picture of
what it is gonna cost you to get the new stuff going and then to support it
as opposed to using what you already know.
Ursa Major wrote:
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.