If "many" is > 100 then forget about PLC. A dedicated micro-processor board will be the best way to go. You can have any speed and any complexity you will ever need at something like a tenth of the cost of a PLC with the same specification.

Micros can handle any analoge signal and any communication protocol. The direct connection to sensors makes "raw" sensors like NTCs and monolithic pressure sensors possible instead of going through the 4-20 mA or Hart or any other standardized interface.

A typical instrumentation that is being implemented using PLC and standardized sensors will probably cost you USD 2000 - 3000 each and it will need space. A custom MCU board and "bare" sensors will cost 10 - 20 percent of that sum. And you can have any form factor so the board can be tucked away in some available space.

For prototyping and testing, an Arduino board is very efficient. There are lots and lots of "shields" for solenoids, motors, sensors, communication and panels.

Just do it!

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

You appear to have a student project. Many small micros are more suited to this than a PLC. One example would be the Arduino UNO. Cheap but powerful they have A/D, PWM and communication capability. An isolated current sensor like an ACS712 would easily tie in. A current shunt would increase current capability. A simple FET could drive externals. Once program is developed a custom board could be made with the bare essentials.

Skogsgurra & Opera House - This is my first post on ENG Tips so I didn't want to overwhelm anyone until I saw a response. I am an EE and Systems Engr. with 40 years of experience, but zero with PLCs. I have build systems from the chip level up for all kinds of applications and programmed in most available languages. In addressing the PLC Community I had some specific goals because what we are building is a unit for distributed power generation and will be interfacing with various power utilities. I understand that about 50% of such applications use SCADA. Cost is critical because there will be over 10,000 units. I am trying to get smart on PLCs from a system engineering standpoint so I can embrace or dismiss the approach that specialists are likely to arrive at. My first impulse was non-PLC and just use a microprocessor based system. I would liked to buy canned sensor and actuator interfaces where possible. Your thoughts are valuable. Thanks.

Follow your instincts!
We do not need to tell you any more. Fourty years! You must have been using the 4004 then! Or 4040. Like me.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

Heathkit H8 followed by a lot of Motorola 6800. My instincts were a general purpose Microprocessor with I/O for ADC and DAC, but the PLC SCADA string kept appearing in he world of Corporate Power.

I must be half as old as Skogsgura. I started on Intel 8088s and 8086s.

There is an argument to be made for COTS (Commercial Off The Shelf) PLCs vs Greenboard controllers. A PLC buys you flexibility to change your design, readily available replacements and an easier time of finding qualified people to service your products in the field.

It would be disingenuous for me to make a recommendation on products considering that my paycheck comes to me twice per month form one of the industry leaders. But suffice to say that in the world of PLCs, bigger can be better if you are looking for the things I mentioned above. All of the major suppliers now offer low cost small PLCs that can probably handle this task and that come with easy to implement communications capabilities like Ethernet and embedded web pages. Total up your I/O count, determine the level of accuracy you need in your analog data (i.e. 8 bit, 12 bit, 14 bit, etc.), fully describe all of your sensor needs and think about how you will want your end users to interface with the control system. Then take all of that data and contact manufacturers directly. They will want to handle a request of that size themselves, even if they ultimately run the business through a local distributor.

But in evaluating this, make sure you pay attention to their processing capabilities. You are looking for what appears to be a high ratio of analog to digital I/O and analog processing takes a lot of number crunching. sometimes in the pursuit of cost reduction, you can get yourself in trouble by asking too much of a cheap processor.

"Will work for salami"

I'd have to pitch in with Skogs on getting your own rolled. There will be no comparison in pricing between the two. You also get to protect your IP waaaaAAAAAy more than with a PLC. PLCs invite competition by showing your competition how to do it. They simply copy down all the part numbers and find a code jockey. You can easily get all the connectivity you desire with a 'green board' not to mention you'll never have to worry about something like a Stuxnet attack.

Keith Cress
kcress - http://www.flaminsystems.com

Well. Jeff. That makes me 110+ years old. Or sumthin'

Field service should, in my opinion, never include code. A system where there are 10000 or more individual units needs to be tested to death before being shipped. If there's a SW problem, you cannot handle that by sending out people to work on them all. If you do, you will create hell for all involved, including yourself, the end-user and the customer.

For a one off, or a few, yes a PLC is fine. But never for 10000+

I have been doing lots of assembler programming. But if you look at the simplicity and almost object oriented principles that the Arduino environment offers - together with a very C-like programming language and a plethora of code for applications ranging from A to Z - you find yourself working less and less with assembler and more and more in "sketches". I have done entire projects without using any self-written assembler code. There may be assempler snippets. That, I wouldn't know because they are somewhere in the include files that I borrowed from the user library.

There's one problem with this approach: You do not get your own look-and-feel and you may feel like you are using code that isn't reliable. If that is your problem, then write your own code and do all the testing and QA work for yourself. I find it a lot safer to use community tested and verified code than writing and testing your own code in-house. Look-and-feel? That is hardly something that will bother you in an embedded system. And even if you are using display drivers written by someone else, you are in charge of the dialogues and can also usually customize character size and colours quite easily.

As I said before, the Arduino way has changed much to the better. Easy and reliable and perfect for prototyping. Use it together with the built-in monitor for lowest cost or use Tek, Yokogawa or Agilent logic analyzers and scopes if you need to make the development cost high and impressive.

When development and test is ready, you can easily produce your boards at a fraction of the cost of a PLC. And if field support is needed for some obscure reason (put diagnosis and calibration routines in the system for easy maintenance) then you do not need to buy and maintain expensive software for your field support girls and guys. It's available for free anywhere you go.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

GEIP makes the RXi processor using Profinet I/O for just such systems.
Look at the PAC System RXi

Automation Direct has some very inexpensive PLCs. However if you decide to go with a PLC the platform will most likely be determined by the communications protocol needed. Also implementation of various communication protocols such as Profibus, Industrial Ethernet and DPN3 can be quite hard and expensive. In many cases to get specifications etc you must become a member of that organization ($$$). However the cost of that will be spread over many units.

A comment to djs' comment:

You do not seem to need a direct and high speed connection with the systems. You also do not seem to need bus communication with any of your sensors or other peripheral devices. So, even if a field bus is standard and good to have in a large plant, it will only complicate matters in a small fuel cell controller. CAN or other simple serial buses may be a good idea. But not sure if they will bring any benefits. Keep it simple.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

If you want a plc supplier

Automation direct
Siemens
Allen Bradley
Schnieder Electric

Why dont you call up your distributor that handles these plc?
PLay them off each other and get a platform that fits your needs.
See who has the support level that you need?
Where ever this goes is support provided there by these?


If you looking for code security most plcs now adays give you this so that any joe can not get at the code to modify it.

Kravdave, look at embedded PLC manufacturers. There's an impartial comparison page here. At least one of those vendors will tailor make a controller to your requirements.

With a custom built controller you will get exactly what you need, at the best possible price, and by definition serious support. This includes on-board sensors and/or conditioning circuitry and the proper drivers to suit your equipment. The most difficult part of the process is probably that you will need to understand all the peripheral bits that connect to the controller, in order to work out a good specification for the controller. You can program it yourself, or have the vendor program it for you.

The NRE can be amortized through unit savings over very few units, so don't let the word "custom" scare you off.

Of course, the very cheapest is to make you own microprocessor based controller from the ground up, using maybe an Atmel or PIC chip, if you have the skills. That means understanding the peripheral devices (sensors, actuators), and performing some sophisticated programming. You can also start with something like an Arduino, but you will still need all the electronic skills, and hobby grade devices like that are, well, hobby grade. They lack things like industrialised I/O, multitasking operating system etc. You can add those on of course - if you have the skills.

BTW, I have been doing this for 40+ years

David Stonier-Gibson

Splatman
I agree completely with what you say. This is more or less an encore of what I said 3 Mar 13 23:45.

I can see that you are quite new on this site and it is only natural that you haven't quite understood how the site works when it comes to commercial aspects. But if you look to the right of the submit button, there's the text "No promoting, selling, recruiting or student posting". That is how it works. And since most of the posters are involved in development of products like your CC18 boards, the situation would be very difficult to handle if we all tried to market our products instead of keeping discussions on a product-neutral and principal level. There are probably dozens of us in here that develop control boards like yours and the site would quickly turn into a flaming hell if we all tried to market our products here.

I will not RF your post. But I am afraid someone else will. So, don't be surprised if it goes. Your other post is OK. So, I am convinced that your "marketing effort" is just a minor slip based on the fact that you are a newcomer.

Welcome! BTW. My first processor was an intel 4004 "system" with three 256 byte EEPROMS and no other memory than the internal register file. That was before the 4040 was available. And it must have been around 1972 or 1973. Fourty years - how time flies!

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

Ouch!

David Stonier-Gibson
http://splatco.com

No probs, I hope. Let's see how it develops. You acted in good belief - that's positive.

Gunnar Englund
www.gke.org
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

Splatmanoz
I actually found your post useful. I have built a controller from the chip level and actually got a patent on it. Since I hadn't done it at that level in a while I reached out to this forum which I just happened to stumble upon. What I needed most were some current examples of the state of the art. I guess that is hard to do without mentioning products, but through the various replies, I was able to pick up some options that I couldn't find on the web. I have pretty much decided to go the custom micro route and am just surveying small modular systems where I can get the right I/O modules. All sensor/actuator leads will home run to the controller. I am not worried about the network end as much as the autonomous controls. FUel Cells are tricky to start up and shut down depending on the type, but the run phase is mostly safety and some fuel tweaking. Just to mention an interesting problem, think about relays needed to switch the power side. You might have a 28 VDC FC module running 150 amps, or as you parallel units you might have higher switching currents. There are vendors, but the price is steep. Given high production rates, costs can come down if the planning is sound. Appreciate this forum and the help.

I have seen where some people just take their special made controller surround it with 3rd party IO and comms modules. So all your doing is writing to a 3rd party backplane protocol that your controller is talking to in a 3rd party plc rack. That way your not redesigning the wheel for all that 3rd party io structure and have support for all that hardware. It throws the risk off of you onto some corp structure that makes most of your hardware. And you have your controller locked down with your code.

I believe robot manufacturers have gone this route with 3rd party manufacturered servo axis.