Control.com - Nerds in Control

I have 32 analog inputs that need to be evaulated by a c++ program and then sent to be read off a HMI and control a instrument. I have not worked with plc's, pac's, or ladder so I don't know there capablilties. One option I have is to do data aquistion with the plc, then feed it into a pc. But I would rather have a one unit system.

Any advice?

Thanks

Why are you even using a PC, can you do it all with a PLC and HMI? This would be the most straight forward. PLCs are extremely capable (depending on the type). If you need input from a PC or are doing heavy database work or something like that, you need to define a clear role for PLC and PC and their interfaces. This is really an open question.

In general (and in the past) PLCs controlled the machine, PCs did data-acquisition, logging, database, etc. Those lines are now blurred.

You can also do everythign from C++, including machine control with the help of ethernet field IO (Opto22, etc). Its really what you feel more comfortable with and if the instrument needs realtime control, ultra reliable hardware, etc.

~Ken

I assume that you are using a Windows PC to run your C++ program. If the only I/O you need to manage is 32 analog inputs then using a PLC is overkill. However, if you need to use these inputs to control a bigger system then a PLC may be the right choice.

The easiset way to monitor your inputs is using a DAQ (data aquistion) card connected to your PC. There are many options out there but my favorites are National instruments (daqMX line) and Dataq. These hardware options come in all flavors and interfaces (USB, PCI, ethernet). They also have large API libraries to interface with C++/VB/C# or other general purpose programming languages.

If you do not have strict industrial requirements for your application then stick to a standard PC for all your work. If you need the reliability and robustness of a PLC Then there are ways to either port a C++ program to ladder or use a PC based PLC module (see Prosoft Technolgies). None of these are cheap.

I've done many of these projects in both PC and PLC's.

Regards,
Gil Lund
www.lundeng.com
gwlund@yahoo.com

PLC's have quite a bit of capability for math functions, maybe you can do it all in the PLC. Of course, I have no idea what you need to do.

Or, if the values are not required in the PLC, add an analog input card to a PC and access it in your C++ program.

Can you explain better about the application?

Jerry

With 32 analog in, that one unit should probably be a PC if cost enters into the picture. Or, even it it doesn't. It will run C++ and it will service 32 analog inputs far more frequently than a PLC.

Regards
cww

Normal PLCs are not intended to run C++ programs. For what you appear to be doing, I would suggest not using a PLC. Rather, you should consider just running the entire application (data acquisition, evaluation, control, MMI) on a single PC.

Rather than using a PC or a PLC, why not use an embedded controller like the ICP 7188 (http://www.icpdas.com) Its just a box which can run C/C++ programs and which will connect to an IO (provided by ICP itslef) to interface the signals. Thats more reliable and compact than a PC and more cheaper than a PLC plus it runs C++ direct.

PS:
I have mentioned ICP here just as a suggestion.There are many such parallel products available in the market.

Vipul Shah
vipul@egenietech.com
http://www.egenietech.com

Single sourcing tends to be an issue. I ship out boxes of stuff that is no longer available. And unless I'm missing something, which is possible since I don't watch that arena as closely as I once did, high volume products are almost always cheaper than low volume ones. That's not to say there aren't places for the SBC's they are near and dear to my heart. It's just that those are the wrong reasons.

I can get a PC2500 for about $65.00 and with tools, solid state disk, off the shelf housing, etc. the cost is going to be a lot less. And it's got serial, parallel, video, ethernet, and more and I can develop on my PC with free tools. They are actually both SBCs so the reliability argument is doubtful. If your IO count goes up the non-pc product may have an advantage. Most of the cost is going to be in development and PC compatible stuff is a win.

Regards
cww