PLC5/40 + 1771-SDN/C + BTR/BTW = No Joy

[rdrast]

This one has me climbing the walls right now...
Should have been simple, toss a SDN scanner into the PLC rack, configure it up with RSNetworx, download everything... good so far.

Enable BTW/BTR in the PLC though, and the scan times jump up from 20msec to 4500 randomly, averaging around 2000 msec. The BT's are using dedicated BT file control blocks, and the SDN is set up to read and write 62 words into brand new integer files.

I seem to be getting -5's and -9's as error codes in the BT data file (DLEN Element), and the BT's themselves never seem to set their timeout bit. CPU status doesn't show any errors (except watchdog timeout which is now set to 10,000msec while trying to figure this out.

The CPU is a PLC5/40-D, Rev B.

I **seem** to remember the same problem from way back, and there was a very simple, quick, easy fix, but can't find anything about it on the Rockwell site.

Any of you fine folk have any ideas?

On the road and desperate!

 

[rsdoran]

I was confused on this at first because I havent used Block transfer with dnet. You did configure the run bit in block 62 for the SDN?

 

[Ken Roach]

If you're getting CRC errors that badly, there's something seriously wrong with your PLC-5 or your backplane. Check the ground on the chassis first !

What you're probably thinking of is the "Local BT" bit that could slow down block transfers for very old BT modules when you upgraded PLC-2 to PLC-5 controllers. That's not the problem here because 1771-SDN/C is a very new module.

Do you have any other block transfer modules in the system ? Do their block transfers work ?

Do you have the option to try another PLC-5 or upgrade the firmware (Series D, Rev B has to be 7 or 8 years old) ?

I have used 1771-SDN/C in a mix with other older modules and PLC-5 Series E controllers with no problems.

 

[kamenges]

I would certainly agree with Ken's point about a backplane problem, especially grounding. That would be my first check.
Please don't be offended, but are you sure you are transfering to the coreect slot? Is it possible the addressing mode is 2-slot or 1/2-slot and the logical and physical slot locations don't match up?
Another thing that caught my eye is that your BT woes are influencing scan time. I think the only way this can happen is if the BT is in the STI. In that case the STI waits for the BT to complete. Unless you have a good design reason for it I would suggest not putting the BT's in the STI, just due to the program freeze thing.

Keith

 

[rdrast]

Update: Problem Solved

After a few more hours on site, I pulled another module from the rack (it's full, of course) and put the SDN in that slot. Of course it worked fine. Left me thinking there was a bad slot in the rack.

Fortunately, digging deeper proved that not to be the case, it was actually that the slot I was using (which had a completely unused 16 ch digital input module) was configured for a PII on the input word.

After deleting the CPU's PII, the scanner worked like a champ in the original intended slot, and scan times are back down to sub 20ms.

The moral of the story, is never assume anything, and PII's do not work well with Block transfers in a PLC5 lol.


To answer other questions here, yes, there are 5 other modules in the rack using block transfers in the local rack, and another 10 or so pairs of BT's to remote racks, all chassis and modules were set to single-slot addressing.

The SDN Scanner channel run bit was for this problem not an issue. Even unplugging the DNet cable and killing the network should have absolutely no effect on SDN to CPU data transfers.

With regards to the 'Troubleshooting Technique' thread here, it would have been smart to try a different slot about 30 seconds after the problem showed up, but as the local rack was completely full, I spent more time trying to figure out what was wrong. /sigh. Just like circuit design, it's all well and good to spend hours calculating out a resistor value, but 99.2% of the time, hooking up a decade box and dialing it till you get the right output of a circuit is usually more time-efficient.

Live and Learn
Thanks for the suggestions guys!