PLC5 to CLX

[Ken Moore 23]

I may be working on a project to migrate a very large PLC5 installation to CLX. I know in the past there was limitations on the amount of analog I/O you could access with CLX to a remote chassis, I assume this has been addressed and I am bringing up old problems that are no longer relevant, right ????

[OkiePC 14]

I believe they have resolved this with a newer faster module, but I think there are still limitations on analog...the original DHRIO module, I think is limited to 32 "Logix" connections. Research the 1757-ABRIO...I think it has a lot of powerful features and support more than 32 connections.

[BobLfoot 302]

Are you using CLGX I/O or keeping the 1771-analog I/O? There are or were certain flavors of 1771-analog which did not play well with CNET on CLGX.

[Ken Moore 23]

I'll know more later this week, right now we are in the "talking about it" stage.

[Ken Moore 23]

Okay, they are going all the way, replacing the 1771 I/o. Our local AB rep came by and demo'd the i/o migration hardware. Looks pretty good. You can keep the 1771 Swing arms and connect them to a migration adapter. Saves having to rewire. Of course they only handle standard I/O modules, special modules will have to be rewired, such as CFM's.

[BobLfoot 302]

Ken now I'll add another 2 cents. Depending on the cost of downtime and such there is an approach I've found quite elegent for conversion. Stage 1 - Install a CLGX Rack with CPU and Network Cards, replace the PLC5 Processor and all ASB modules with 1771-CNB or now 1771-AENT. During Stage 1 you can run your PLC5 program with ASB during the week for production and on weekends shake down the CLGX code with I/O CHeckout, Dry and Wet run phases until you're ready to go live. Each Monday Morning you reinstall the PLC5 CPU and ASB and go back for another week of production. Stage 2 - After the CLGX CPU with 1771 Hardware is "burned in" and all your routines are shook down. You repalce the 1771 hardware racks one at a time during downtime weekends until the 1771 I/O is history. Unless you're scrapping CFM Cards the programming done in stage 2 should be minimal. Just food for thoguht. In our case a 12 weekends of downtime was cheaper than 4 weeks of solid downtime. Of course this approach is more work for the Integrator, but lees risk to the end user.

[Ken Moore 23]

The name is Ken Bob, not Keith, LOL. (to many night shifts ?) This client runs 24/7, so while the weekend option would be nice, it isn't an option.

[BobLfoot 302]

DOOH ! DOOH !