Micrologix 1500

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.

Andrey Romanenko

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 road somewhere.

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.

good luck,

-john

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 it take?

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?

Andrey

What you say is true, but I think there are a few factors that would cause problems, current-day:

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. :-)

-john

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 > I have a project that requires that data be collected for a large group