SLC BTR/BTW to Powerflex 70 Troubles - Suggestions Please...

Setup:

SLC 5/05 with three 1747-SN Modules in Main Rack. Two of the three modules are controlling about 23 Powerflex 70 Drives (10 on one module, 13 on the 2nd). Baud at 230K, proper resistors installed. Powerflex 70's are all installed in a Centerline MCC.

I have the drives all configured as 1/4 rack, so I have to pass the reference via BTs. I read the speed feedback and amps. So, all the BTW instructions pass 1 word (limiting overhead), and all the BTRs read 6 words (fdbk + amp + spare).

I started with standard bidirectional BTR/BTW using bits 12 and 13 to fire the BTRs and BTWs. I started running into what I feel are 'overload' issues, so to reduce the # of BTR/BTWs firing I did the following:

A BTR/BTW only fires if the drive is on-line
A BTW only fires if the current speed is different from the setpoint (only on Setpoint change) and if the drive has a start command.

Now to the problem: The BTRs seem instantaneous on updating. If I give the drive a start/stop command, I can see the speed feedback and amps ramping up/down. The BTWs however seem to be another story. It takes up to around 3 to 5 seconds for the drive to accept a new speed reference. That I can live with. However, there are a few drives that it might take upto 5 MINUTES before the reference finally shows up at the drive. To diagnose, I've done:

Monitored the .ER bit and the Error Code: I get no errors on the BTR or BTW instructions. The # of transmitted words is either 0 or matches (toggles). The DN and EN bit are also toggling as expected.

Tried different approaches of when to fire the BTR/BTW instructions with little difference.

Lastly, I decided to shut off all the drives except for a few. Suddenly, the drive that was taking 5 minutes to update the reference was now updating with a few seconds. Turn all the other drives back on, and it goes back to 5 minutes. That means it could be back to BTR/BTW overload or maybe noise from all the drives being on? Remember, the BTR/BTW only fires when the drives are on-line (using the M file status word).

The worse drive is the next to last drive in the string. It's BTR/BTW is somewhere in the middle of all BTR/BTW operations. So, I am pulling my hair out on this one.

Any suggestions on where to troubleshoot next? Is there anything I can look at that would be indicative of noise on the RIO link causing lost transmissions (EDIT: I found the retry counters, so I'll look at them in the morning)? Again, the actual BTR/BTWs are not in error. I'm going to look at the routing of the blue hose since it does sake its way around the MCC and is very likely near many 480VAC feeds.

What about slowing down the baud? I do have an I/O rack hanging off the module with 10 drives, but I don't think 56K would be a big deal. I know typically in noisy environments, lower baud sometimes means lower retries.

Next time, its ControlNet or nuttin on SLC, no matter what the customer says

Action Plan:

1) Check Retry Counters
2) Ground Shield (I don't think this was done) to Chassis
3) Check routing of BlueHose near 480VAC feeds
4) Reduce Baud Rate to 115K (found tech note about 230K and Drive BT issues)

Anything else?

Your on the right track, my guess is that you have serious noise issues.

This should work no problem.

robertmee said:

What about slowing down the baud? I do have an I/O rack hanging off the module with 10 drives, but I don't think 56K would be a big deal. I know typically in noisy environments, lower baud sometimes means lower retries.

Next time, its ControlNet or nuttin on SLC, no matter what the customer says

Click to expand...

I have gotten around noise issues on DH+ by going to 57.6k. I had identical machines with both operating speeds and could not tell the difference in their operation by going slower.

Since your network is broken into 1/4 racks on 3 different cards, it does not appear that you are grossly overloaded. More likely, it is cable routing leading to noise. Just an inch or two of increased physical separation can make a world of difference on the blue hose networks.

The retry counters should show where the problems are. I have had good luck isolating RIO problems using those diagnostic counters. More than once, I have found a 'bad' adapter module causing havoc, but still functional. "If in doubt, swap it out"

As for alternative networks, don't forget devicenet. We have a 5/05 with 5 SDN cards controlling dozens of powerflex drives and it seems to be much more capable and reliable for a large network than RIO.

Also, I would not ground the shield of the blue hose (unless recommended by A/B), but make sure that the chassis are properly grounded.

Just an update...

I checked all the retry counters and they are stable as a rock. None increasing other than a couple of drives that are currently offline :-(

I grounded the Blue Hose (it is shown in the install of the SN module) with no help.

Tech support at AB is now reviewing the program just to make sure I don't have some weird coding issue (unlikely).

One thing that is really bizzare....The DN bits on all the BTW instructions are cycling even when the rung and the EN bit is false. Why is that? I've cross ref'd (individual and the entire file) till I'm blue in the face and there is no walkover. It seems the DN bit and the EW bit continue to toggle with the rung false. Could it be the buffer is so full it takes that long to empty? I don't see how as we're talking hours that these bits continue to toggle.

Are your scanners series B?

They are the latest...

Anyway, problem solved and I'm ashamed ;-) Hopefully my miscue will help those in the future...

The issue was that I used the same buffer # for the M0 and M1 files in the BTW/BTR combos. I was under the false impression that each M file had its own separate buffer. Not true. Even though you use M1 for BTR and M0 for BTW, you cannot use M1:2.100 and M0:2.100 (as an example) in a BTR/BTW set. It needs to be M1:2.100 and M0:2.200. There are actually examples in manuals that do show using the same buffer # for BTR/BTW but those are only suggested for analog I/O where you write the configuration once. Don't apply that to a continuous operation like drive control where each BTR/BTW needs its own space.

I do take solace that it took three AB engineers looking over the code and reviewing several manuals before it was thought to be a problem.

Don't be ashamed, you had a lot of us stumped here because this should just work without a lot of hassle. RIO is pretty forgiving. I'm not sure I would pick up on it right away if you had posted your code either. This kind of thing sometimes just happens.

robertmee said:

They are the latest...

Anyway, problem solved and I'm ashamed ;-) Hopefully my miscue will help those in the future...

The issue was that I used the same buffer # for the M0 and M1 files in the BTW/BTR combos...

...I do take solace that it took three AB engineers looking over the code and reviewing several manuals before it was thought to be a problem.

Click to expand...

Well, that explains why the DN bits were diddling, since they weren't actually isolated. I know that the BTR/BTW are different in a SLC vs. the PLC5 (with which I am much more intimate). At least you did not have to do them the old fashioned way by writing tons of ladder logic to manipulate the M0/M1 files. I used to work on some SLCs with analog I/O done that way (pre-BTR/BTW availability) and it was a real bear to troubleshoot.

Thanks for letting us know what you found, and don't be embarrassed, we are all human, and what you are doing is not exactly simple.

Paul