PLC5 to CLX conversion problems/question

Hi all,

im currently working on a PLC5 to CLX conversion and have ran into a number of communications speed problems.

Due to operational availabilty, im only able to do work on the system when the site is shutdown (12hrs/week), and as a result i have to do the upgrade in 2 stages.

1st stage involves converting the PLC5 program to a CLX program, and using the existing IO as Remote IO. RIO was choosen as there were already RIO nodes on the network, and the client is a tightass and didnt want to spend more money on a controlnet PLC5 adaptors.

2nd stage involves converting the PLC5 IO over to Flex IO communicating to the CLX over Ethernet.

The process is quite time critical and as such any communication delays in the 1st stage will be detrimental to the performace of the system.

I have tested the converted program on site and everything works well except 1 part of the process, which works too slow.

Luckly for me, everything to do with that process is located on one RIO rack, and that rack is currently of a Flex IO hardware.

If worst comes to worst i will convert that Flex Rio adaptor to an Ethernet RIO adaptor and hope that this will cause the speed to be adequate, however before i go down that path, i want to know if theres a way i can initiate the CLX processor to read that RIO nodes input and output image when i trigger it via a ladder program. That way i can manually update the image table of the IO cards before i start executing the code in the PLC, and then update the output table of the IO cards when i have finished executing the code.

Similar to the IIN and IOT instructions in Logix5/500

I know that Logix5000 has the IOT instruction but havent found anything similar to an IIN instruction.

Does anyone out there know of anything that could help me??

I have seen that you can configure some inputs to be used as event generators, so that they lead to a event task. Event task are executed inmediatly, I also know that there is a restriction on how many event tasks can be used.

The problem with RIO is there are two asynchronous scan cycles going on. The adapter does its normal sweep and update and I don't think there's anything you can do about it. Then the scanner reads the adapter data on a more controllable basis, but it could still be stale data, depening on your definition of "fresh" enough to perform as desired.

The best bet is to use local I/O for time ciritical stuff, and get the guy to buy some extra 1756 cards for those.

I think your ethernet migration path is a good one, but make sure the installation is very good and that you keep I/O traffic separated from other ethernet traffic for best results.

to answer a specific question:

I know that Logix5000 has the IOT instruction but havent found anything similar to an IIN instruction.

Click to expand...

with native (1756-style) ControlLogix hardware, the COS (Change of State) function is the "replacement" for the IIN instruction ... the bad news is that in most (all?) cases it won't work for "non-native" modules ... specifically, I don't think this is going to do you any good with your problem ...

note that COS is a "configuration" feature included in an input module's setup ... it is NOT an instruction in the ladder logic ...

basic idea: if an input point which has COS enabled changes its ON/OFF field state, then the input module "broadcasts" its data to the backplane - and the input bits for that module are updated in the processor's tags ...

going further with your main problem ...

secret handshake: the 1756-DHRIO is NOT a "solution" ... actually it is a "patch" ...

the recommended method for "moving up to ControlLogix" is to scrap any existing old-fashioned "Universal Remote I/O" (as in "blue-hose" type stuff) and replace it with $omething newer ...

but ...

since many customers aren't financially able to jump right into the deep end of the pool, the DHRIO module provides a temporary "sort-of-works-ok-in-some-situations" patch between the new ControlLogix processor and any existing blue-hose I/O ...

think of it as something like the Mickey-Mouse spare tires that come with most new cars ... top speed 45 mph - just to "get you home" ... once you start looking at the DHRIO module that way, then your game plan will usually fall into place ...

There are two "other" options for Remote I/O communications on CLX platforms. A new 1756-RIO module that was released a year or so ago. I haven't used one. It does RIO only, no DH+. Another option is a 1757-ABRIO module. Have used these before. You create data maps to the 1771 I/O. The module handles the BTR/BTW for you.

How many RIO racks are there? Are you using the 1756-DHRIO? How did you break up the channels?

We finished a rather large PLC5 - CLX conversion, had about 40 RIO drops, some of it Flex, some of it old block IO, as well converting the PLC5 Local rack to use a 1771-ASB to create another RIO node. Everything went rather well, but you do have to be aware of how fast (or slow) the RIO updates, and program it so the IO goes into a buffer, avoiding the asynchronous IO updates.

There are 7 RIO racks configured in the project..

Rack 0-1 is a 16slot PLC5 rack (which had the original PLC5 processor, now an ASB module)
Rack 2-3 is another 16 slot PLC5 Rack - ASB Module
Rack 4 is a card which communicates to a couple VSDs.
Rack 5-6 is an old PV1200
Rack 7 is the Flex Rack in question.

I know in the old PLC5 program they had to force Rack 7 to be updated several times during the RIO scan number of times.

For example in the RIO channel config in the PLC5 software, where you specify the racks, they had to do the following:

Rack2
Rack7
Rack3
Rack7
Rack4
.
.
.
etc



DHRIO card is set up as ChA 57.6k DH+, ChB as 57.6k RIO Scanner.

And just so everyone knows this site is very badly engineered to begin with.. the PLC program im converting has 1 Routine of 600+ rungs, so ive learnt to expect the unexpected

and i would have used the standard 1756-RIO card, however they have a DH+ network on site also, so inorder to save money we tried to reduce the hardware so just got a card that did both, hence why we are using the 1756-DHRIO card

If Rack 7 is the problem child, what about changing just that one to ControlNet? Or make it the first one to migrate to Ethernet.

Other general comments.

On the DHRIO, when you use the A and B port you do not get double the RIO data transfer. That "buffer" is shared. To get more speed you need another DHRIO module. I have just completed a job with a 1756-RIO module and it appears to very closely match the RIO capabilities of the PLC5 series. That may be an option for just the Rack 7 and keep it alone, depending on how easy it is to isolate that section of blue hose. But the RIO module is quite expensive, around $2K here in the US.