PLC 5 problem

Hi, I need HELP.
I have CPU PLC5 80/E with 9 remote chassis with REMOTE IO. One of the remote chassis has AO and AI modules. I read from the AI and Write to the AO, and i have 3 seconds of delay.

I move the AO module to the local chassis and I haven´t delay.

I need URGENT one solution of this problem.

Thanks and sorry for my English because i´m from argentina.

Gustavo Barenbaum

First thing that comes to my mind is to check the termination of your network, for bad cable or even for exessive cable length.

what type of logic are you using to "trigger" the Block Transfer Reads and Writes? ... some programmers use a Timer Done Bit to trigger these ... when there is a LOT of remote I/O, the timer is often set to cycle the done bit only once every few seconds in an attempt to cut down on network traffic ... could this be your problem? ...

Hi all

First of all I would like to wish ever one a happy new year.

I agree with the last reply.If you use the not (XIO) enable bit of the bt in your message block.If your message block is not enabled it must
be done and I dont know of any faster way to trigger your block.

Hope this is of some help

Donnchadh K.

I move the AO module to the local chassis and I haven´t delay.

Click to expand...

The local chassis is updated synchronously at the end of the program scan and takes about 1 msec +/- and includes all block transfers for the chassis.

Remote chassis are updated asynchronously at approx. 9 msec. per adapter (ASB). This time is extended for block transfers. The adapters are scanned in the order set in the scanning channel's scan list. Only one block transfer is serviced per adapter, per I/O scan. Note that adapters can appear in the scan list more than once, permitting faster updates for particular chassis (and slower for the rest).

Given your configuration, the base update rate for the remote I/O is approx. 80 msec. Add another 1-2 msec for each block transfer. If there are several BTX modules in a chassis, the fastest update rate achievable for each is no_of_modules * 80 msec.

I wouldn't expect this to account for 3 seconds, but it will be part of it.

A little off-line discussion with Ron Beaufort brought this to mind:

Block transfer requests are queued in the PLC5 for execution during I/O scans. If the requests are made faster than they can be completed, the queue fills up. When the queue is full and requests continue, things can get very slow.

If the BTX's to the remote I/O are programmed as 'continuous' or otherwise triggered at a rate faster than they can complete, the queue will fill up.

You could also trigger your block transfers from bits in a timed interrupt routine. The timed interrupt would set/reset the BTW/BTR instructions at a predictable rate. Then you wouldn't have to relocate your I/O modules, saving the cable installation cost.

GregM got me thinking about something. Are there any BT instructions in the STI? The 'new platform' PLC5's (of which the 5/80 is one) will put BT's from inside an STI at the front of the queue and pause the STI until the BT completes. So, if you are using an STI, the STI has an aggressive STI time relative to the STI file scan time AND you are executing any BT instructions from inside the STI you can really hose yourself on other BTs, not to mention faulting on an STI overrun if the BT fails.
It doesn't sound like the case here but it might be worth a look.

Keith