Analog Block Transfer Issue

[BobLfoot 302]

Ran into a unique situation tonight. Will take some time to explain so bear with but I need ideas as to where to go next. This System tan as a PLC Controlled System and has run for the past year since we converted it to ControlLogix. Now we are having an issue. PLC CPU is a 1756-L63 Rev 16.7. DHRIO Card is a 1756-DHRIO/D Rev 6.3 running channel A @ 57.6k and channel B @ 115.2k. RIO Adapter is a 1771-ASB {Can't get rev and stuff while running, but was new less than 1wk old} Hardware Rack is PLC 5 17 slot rack. Out Card is a 1771-OFE {Can't get rev and stuff while running, but was new less than 1wk old} Channel 0 goes to an Allen Bradley 1305 VFD Channel 1 goes to an Allen Bradley 1305 VFD Channel 2 goes to an Allen Bradley 1305 VFD Here is my problem. The system will work of a while and then suddenly it will take anywhere from 30 seconds to 45 mintues for the new analog value to reach the VFD. The BTR and BTW instructions are not showing any errors and are set to occur alternately at 250 ms intervals. There is one device on the wire which is faulted for code 16#312 Invalid Link Address but inhibiting this device has had no affect on the system performance or the problem. The only thing that give me some hope is the occaisional link status idle error. But this may be a red herring. One other strange thing. When I inhibit the faulted adapter which does not show as faulred in the 1756-DHRIO Properties window, it also does not show as inhibited. Any ideas now are appreciated.

[Ken Roach 194]

I think the Inhibit indication and the faulted adapter are the red herrings, actually. The Link Idle is alarming. I've seen the DHRIO RIO scanner Link Status screen fail to correctly indicate Inhibited devices. The RIO Scanner Object correctly reports them, and the I/O tree shows them correctly, but the Link Status tab doesn't. I think this feature is seldom used so RSI's GUI programmers haven't gotten around to fixing it. When you Inhibit an adapter, only the CIP connection between the controller and the 1756-DHRIO scanlist object gets inhibited. On the RIO side, the 1756-DHRIO keeps on scanning the adapter and the Timeouts value for the scanner keeps on incrementing. That's why you need to monitor (or view) the Timeouts counter for each adapter to determine intermittent timeouts to that specific adapter. Now the long delay between apparent BTW's taking effect is super-strange. I assume you're counting /DN bits and /ER bits, rather than viewing them online ? Could you be exceeding the cached MSG connections per ControlLogix CPU for DH+ (16) and BTR/BTW (16) instructions ? Link Idle should mean exactly that; it's like the DHRIO scanner itself has gone into Idle mode, like when the ControlLogix goes into Program mode. Weird. I have some sample code for programmatically monitoring the DHRIO scanner and adapter objects if you're interested. It's based on the examples in the knowledgebase and was going to replace them, but I never got the time to write it up and do a peer review and lab test. Edited 11 Nov 2010 by Ken Roach

[BobLfoot 302]

Based on your input Ken - I plan to clean up the BTR - BTW Messages and make sure we're not flooding the connection buffer. Any hints suggestions? Also I might replace the 1756-DHRIO Card and check for firmware revs.

[CMike 0]

Hi BobLfoot, I would like to know whether reducing the number of msg instructions did the trick in your case. thank you in advance and more helpful posts :) Edited 6 Jul 2013 by CMike

[nehpets 19]

Not sure if the following is of any help:- A while ago whilst adding a node to DH+ channel A on a 1756-DHRIO/D I inadvertently duplicated a node address, no problem just put it all right and got the new node talking everything was fine, happy days. However a few hours later, one or two anomalies started to appear with other nodes (not turning outputs on and not receiving input signals), but it appeared to clear itself and run ok again. Later, again it started playing up seeming to get worse. When I viewed the message enabled signal it was very erratic, normally taking 0.5 sec to complete, sometimes taking 25 secs to complete eventually taking so long that the process stopped. My answer to the situation was a complete power cycle of the whole system, it all came up running normally and has run fine for a year now, prior to my node duplication issue, the system had run for 9 months without a hitch. Steve