What are my best options here?

What are my best options here?

I need to acquire data from 15 Injection Molding Machines, 4 Furnaces and about 5 small-automated assembly machineries.

They all have different PLC makes and models like Koyo / Siemens / GE 90-30 and AB. I need to bring the productions and faults data to several HMI’s located in 4 management offices within the plant.

I will like to save the time and expense in hard wiring all of these machines and will like to go wireless. Would you install a serial Wireless Cellular Modem on each PLC? Is hard wiring my only option? How would you do it?

Thanks

Andy

Hard wiring will be the most reliable in the long run, but comnpanies tend to be near-sighted when it comes to spending money, so you will probably wind up with a network or some wireless modems. I understand that the new ALlen-Bradley 5/05 PLC will accept network modules of many types, so this might be an option. I have not used that one myself yet. I usually wait until the bugs are worked out and paid for by others before trying something new.

It depends on what you want to collect. Is it data you need collect or just know if the machine is running, faulted, stopped, etc... I've run into this problem a few times in large plants where they have many different PLC's or outdated models that can't be networked. A solution for this is a main PLC with remote I/O modules in each machine. I've used Omron CPM2C-S100C PLC's with remote I/O modules. This PLC has a built-in Compobus/S connector. It's pretty easy to use because there is no set-up required. You select a node address for each module. There is a memory area in the PLC that is reserved just for the remote I/O so you just use the bits as if they were directly on the PLC. Once you have these inputs in the PLC you can do anything you want with them. I usually put an operator interface with a Ethernet port to bring the data from the PLC to a main server where the data can be monitored with something like Wonderware. Cimrex makes a nice screen with an Ethernet port. The only problem with this is you're limited in the amount of remote drops you can have. You'll have to see what number of I/O's you'll need then verify if you can do it with Omron. I have a plant with 20 Injection machines on this type of network. I put a remote module in 10 of the machines then hardwired between them. You could also do the same thing with a devicenet network.....

Can we use Wireless Ethernet Modems for this application?

We need to collect data inside the PLC variables like Counters for production, maintenance, scrap, PPM and if the machine is running, faulted or stopped.

Andy

Wireless or not wireless is only part of the problem. And it is not part of the solution.

If you can bring all of your PLCs on some Ethernet protocol (and not necessarily the same Ethernet protocol), then you could also put it on wireless if thats your fancy.

The main problem for you is to find out how to collect and distribute the data. The answer is "OPC".
OPC is a standard that allows applications (aka OPC "clients") to connect to network drivers (aka OPC "servers").
You could have one or several PCs gather the data and then distribute it to other PCs. Its a typical distributed SCADA application.
I would recommend ICONICS GENESIS for two reasons:
1. It is based completely on OPC.
2. It is not tied to a particular hardware platform or vendor.

Dont stare blindly on ethernet and wireless. The smallest problem is to lay a network cable to each device.

OPC is a great solution for this problem however the price may be a determining factor. You have to have the OPC software for each PLC manufacturer, set-up a network for each brand or install an ethernet card at each PLC to bring the data to the server. All these different softwares can end up being a programming nightmare. You'll also have to collect the data from each OPC software with a software like Cimplicity, Genesis or Wonderware which is also not a cheap solution. I've had compatibility problems with OPC in the past when using so many PLC vendors. If you use a main PLC with remote I/O all you have to do get the info out of one PLC. 1 OPC software. Done. Do all your calculations for PPM, counts, etc in that PLC. The network (RS485) cable you have to pass between each machine is a 4 conductor. But I must agree with JesperMP if money is no object OPC is the best way to go for future growth. OPC is the most flexible approach. Possibly you could do this for the most popular brand of PLC you have and hard wire or use remote I/O for the rest... Wireless can be used also but be carefull if the environment has electrical noise or if the distances are long or obstructed...

Shawn,
how in the world can you take an existing and working machine, strip out its PLC, put in Remote IO of another make, rewrite the PLC program to the other make, possibly rewrite the HMI for the same machine .. for less hazzle and cost than the price of an OPC server ????

About trouble getting several OPC servers to work together: Get all OPC servers from the same vendor. Check Kep's OPC server list for example.

JesperMP is right I was thinking all the time in buying either TopServer of KepServer for this application. Now back to the question:

Assuming hard wiring is not an option then what are your suggestions.

I know that a similar thread was bought up a couple years ago. I thought I ask again so new technology can be taken into consideration.


These are the available options, which one would you pick or add;



1. RS232 to Ethernet Converters
2. Power-Line Modems
3. Cellular Wireless Modems (not a GPRS always on connection but instead a dial up connecting and updating the HMI every five minutes)

Guys... hello. The remote I/O is just there for collecting the digital inputs and outputs. The existing PLC remains and does its job untouched. The remote I/O only gets inputs (or sends outputs) from the existing machine (from the PLC or other components). This way you do not have modify the existing PLC program. Normally there are outputs available to let operators know when there has been a fault, when the machine is running, cycling, etc... Some wiring has to be done to input these signals to the remote I/O but it's usually pretty straight forward. With many brands of PLC's in one plant it can be an option..... it not the only solution.

We ran into a similar problem back in 1993. We have 23 injection mold machines and 14 presses that we need information from (they have different control systems). We placed GE Fanuc Genius I/O blocks (nothing but remote I/O) at each machine. We have a central PLC (we call it a Data Concentrator) that controlls all the remote I/O. We programmed outputs from each machine that are inputs to the Data Concentrator PLC via Genius I/O. These outputs tell us machine counts, cycle times, manual mode, auto mode, fault mode (some case certain faults). The Data Concentrator PLC was tied into the SetCim software via MMS Ethernet. It is now tied into the Database via TCP/IP from the same Data Concentrator PLC. We are about halfway from converting the SetCim Software over to a GE Fanuc Cimplicity / SQL Server solution. The original data still provides valuable information from discrete outputs from completely different control systems. In some cases, we also installed remote analog input blocks for critical process information (temperature for example). We also use this system to alphanumeric page supervisors , engineers, & maintenance when a problem occurs. Besides this system, we have over 150 more PLC's tied back into 5 more Data Concentrators that are seperate from the one's I described. Can you say information overload? But, if anyone wants any data, from any machine, I can have it to them!!

Shawn,
its still much more expensive to build in remote IO in several machines, than to purchase one OPC server per type of PLC.

And your solution is totally inflexible, how can you assume that you can "hardwire-peek" the values that must be brought in for datalogging ?
Normally there is 1 (one) alarm lamp or output for all alarms on a machine. The precise alarm number is typically displyed on a local HMI. The only way you are going to extract that number is from access to the PLC memory.
And that applies to most other values that must be logged.
Which operator is currently in charge of the machine ?
What part is being processed on the machine ?
etc..

And to Annibal's question:
How about bringing the data into a datalogging server via traditional network cables. Then from this server you can connect to the office clients and possibly laptops in the plant via wireless.
This seems to me to be costeffective and easy.
I would only try to put all the machines on Ethernet + Wireless if there was a truly compelling reason for it (not just nice-to-have).

We are using Iconics Genesis 32 software for our SCADA system. One of our OPC servers communicates with about 80 PLC (3 ControlLogix and rest is SLC-5/05).
rmor
What do you use to do alphanumeric paging?

JesperMP seems to have it out for me for some reason? I think rmor understood right off the bat. Please read the first question in the thread and then my response to it. They have many different PLC's, possibly older models. I asked him what type of data he needed to collect... If he would have said word values, etc. I wouldn't have made my suggestion. You have to remember that some PLC's are not OPC compliant due to the fact that they are outdated or discontinued. In a perfect world everyone would use the same brand PLC and there would be 1 standard for data collection. Until then, we have forums like this to discuss alternative method to get around problems we integrators face daily. My method is a solution for these types of problems or for a plant with many PLC brands. I did a plant with 20 machines that had outdated PLC's from the 80's. The customer didn't want to replace the PLC's and MMI's due to the cost of reprogramming, rewiring and redocumenting. I did a price comparison for both methods and it was significantly lower to do it with a central PLC collecting data. But I do agree with you and always have that OPC is the most flexible method for data collection. The amount of data you can collect is not limited with OPC. I guess I work for customers that have budgets. Have you priced the OPC software, ethernet cards or network cards from some manufacturers? Costs can be incredible if you have many different brands. PaulB has all AB in his plant and uses OPC to collect data and that's the way to do it. I have a customer with 75 AB PLC's and I installed an ethernet network with Wonderware to collected data using OPC. When it makes sense....you do it.

New Rule

I suggest a new rule for question posters, to avoid excessive
bandwidth.

State the problem.
State all the solutions that are not acceptable.
State all the solutions that are too expensive.
State clearly all available resources.

Save all the rest of us lots of time.

Please note: The FREE solutions available are usually
worth exactly what you pay for them. NOTHING is free,
not even the 'time' of the in-house guys who can
'throw together' anything in nearly no time at all.

Shawn Cassidy said:

You have to remember that some PLC's are not OPC compliant due to the fact that they are outdated or discontinued.

Click to expand...

OPC IS NOT A FUNCTION OF THE PLC!!! It is a function of the communication driver on the PC.

BTW, I like jdbrandt's rules. In addition I suggest that links are provided to products for which support is requested. HOwever, what difference will it make. NO ONE READS PHIL'S NEW HERE? link.

I save bandwidth by NOT RESPONDING UNLESS I WANT TO. I DON'T HAVE TO RESPOND. NEITHER DOES ANYONE ELSE! If someone doesn't post a question the way you want, DON'T RESPOND! No one is forcing anyone to respond to questions that don't follow jdbrandt's rules. I don't complain about stupid or incomplete questions because they will ALWAYS exist. I just don't respond. It is that simple.