SLC 505 BTR/BTW Gotchas in this design?

Reviewing customer provided SLC layout and has an abundance of RIO devices...So many in fact that I want to understand clearly any limitiations or gotchas I should be aware of when setting up BTR/BTWs.....

Layout:
Main SLC 505 base with 10 slot Rack and 10 slot extender
Three SN modules in Slots 1,2,3

Slot 1:
R0G0 7 Slot Rack - 2 slot addr (alternating I/O) - 1/2 rack
remaining RGs - (10) 1/4 rack weigh controllers

Slot2:
R0G3 7 Slot Rack - 2 slot addr (alternating I/O) - 1/2 rack
remaining RGs - (8) 1/4 rack PF70s

Slot3:
remaining RGs - (12) 1/4 rack PF70s

The 7 Slot Racks are discrete only, so no BTR/BTWs there. So, I have 30 devices that need BTR/BTW. I know the SLC has a max Block Xfer buffer of 32, but what I'm not clear on is that 32 BTRs and 32BTWs or is that 32 total? If 32 total, how do I ensure that I don't overrun the buffer. I've normally done bi-dirctional BTR/BTW combos and would like to continue to do so. But do I need to add additional control bits in the enable rung from the other BTR/BTWs to prohibit them from all firing at once?

Thanks!

No BTR/BTW SLC Gurus?

Have not read the manual in a while, but I believe it's 32 total.
From the help files:
When a false-to-true rung transition enables a BTW or BTR instruction, the transferring data is put into the BT buffers. The maximum block transfer request is 32. The processor runs each block transfer request in the order it is requested. When the processor changes to Program mode, any block transfers are cancelled.

Rockwell Software 2005

What I would do is this:
1. Since you only need the BTW at start up, place all the Writes in one ladder file, that is only called when when the first pass bit is true,

2. Place all the BTR in another ladder file, call this file when the first pass bit has been false for a few seconds. (give the buffer time to clear)

This will give you the 30 buffers for each task.

Hope this helps.

Ken

Ken Moore said:

Have not read the manual in a while, but I believe it's 32 total.
From the help files:
When a false-to-true rung transition enables a BTW or BTR instruction, the transferring data is put into the BT buffers. The maximum block transfer request is 32. The processor runs each block transfer request in the order it is requested. When the processor changes to Program mode, any block transfers are cancelled.

Rockwell Software 2005

What I would do is this:
1. Since you only need the BTW at start up, place all the Writes in one ladder file, that is only called when when the first pass bit is true,

2. Place all the BTR in another ladder file, call this file when the first pass bit has been false for a few seconds. (give the buffer time to clear)

This will give you the 30 buffers for each task.

Hope this helps.

Ken

Click to expand...

Thanks for the info Ken....Unfortunately, The BTWs aren't simple Analog I/O writes where I'm configuring a card. They are mostly Powerflex 70 drives configured as 1/4 racks. I have to do continuous writes as I'm sending reference to the drives (1/4 rack config only allows the BTW control word and the Logic command word via discrete). I suppose I could expand upon your idea and do the BTW for reference change only on a trigger of data change of the setpoint (it does change infrequently, but can change at anytime). I could always compare the SP to the Fdbk and if they differ outside a range (to allow for small variation, but less than 1% range of the drive SP), do a BTW.

Interesting......

As a second solution, I did find a way to get the weigh cell controllers configured in such a way that I don't have to do BTs and do commands/reads via the two word discretes. So, that cuts down the total devices I need to 20 PF70s for a total of 40 BTs. If I use then .15 bit of the alternating BTR/BTW combo as an additional enable (in addition to the normal .12 and .13 of the BT itself), does that insure that I only have 20 in the buffer at once (and not 40)?

I know RIO scanners are not cheap, but adding a second scanner would solve all your problems.

When you weigh the time and effort required to "stage" everything with one, then the additional cost may not be so great.


Each BT requires a buffer file, when you over write the file when it's reused, strange things may happen.




Ken

Ken Moore said:

I know RIO scanners are not cheap, but adding a second scanner would solve all your problems.

When you weigh the time and effort required to "stage" everything with one, then the additional cost may not be so great.


Each BT requires a buffer file, when you over write the file when it's reused, strange things may happen.




Ken

Click to expand...

I've got three scanner modules, not one. One is allocated to 10 Weigh controllers, the other two to the 20 PF70s. I knew that I had 32 M file buffers per module, but does that mean I have 96 total or is the PROCESSOR itself still limited to 32. That's where I was getting confused. The way I read it, there are only 32 TOTAL buffers for BTs in a SLC PROCESSOR, regardless of how many scanner modules you have to disperse the nodes. Not to be confused with the 3200 M File Locations PER Scanner. Or maybe it is confused.

My mistake.

I think you might have to contact AB on this question. I would guess that it's 32 per scanner.

You could also "cascade" your BT's.


Ken

robertmee said:

Thanks for the info Ken....Unfortunately, The BTWs aren't simple Analog I/O writes where I'm configuring a card. They are mostly Powerflex 70 drives configured as 1/4 racks. I have to do continuous writes as I'm sending reference to the drives (1/4 rack config only allows the BTW control word and the Logic command word via discrete). I suppose I could expand upon your idea and do the BTW for reference change only on a trigger of data change of the setpoint (it does change infrequently, but can change at anytime). I could always compare the SP to the Fdbk and if they differ outside a range (to allow for small variation, but less than 1% range of the drive SP), do a BTW.

Interesting......

As a second solution, I did find a way to get the weigh cell controllers configured in such a way that I don't have to do BTs and do commands/reads via the two word discretes. So, that cuts down the total devices I need to 20 PF70s for a total of 40 BTs. If I use then .15 bit of the alternating BTR/BTW combo as an additional enable (in addition to the normal .12 and .13 of the BT itself), does that insure that I only have 20 in the buffer at once (and not 40)?

Click to expand...

It sounds like you have a good handle on it. EDIT: since you're set up as 1/4 racks, then you only need BTR/BTW for drive status. I would watch the standard input status words to determine if I needed to execute a BTR for example to retrieve a fault code, and stagger any BTW that were required to change settings outside the standard I/O handled by the scanner.

Also, be sure to read up on the pending comms service control bits that will let you decide whether to complete pending communincations at every housekeeping session...at the expense of ladder scan time, or limit the number that are processed to preserve a stable shorter ladder scan time.

One more note, I am not sure about the SLC, but the PLC5 lets you examine status bits that can tell you how many block transfers are in queue so that you know how close you are to maxxing it out.

In a PLC5 with a dedicated comms CPU, you would not have to stagger them, but in my experience with high end SLC setups with lots of comms, you will drop block transfer requests if you try to do too many of them at once.

Edit: your setup looks very manageable, but I haven't seen the code or the required responsiveness of the application.

Ours that have had comms limitations problem are handled by timed ring counters and it is not a big deal. Ours also have lots of messaging too which all must be handled by the SLC during housekeeping.

Personally, I like to know motor current, and use the drive "at speed" bit to tell me when there is a speed error.

Motor current is hugely valuable to predictive alamring and maintenance but especially troubleshooting (future downtime <) when you can display it.

You can do a lot without having to have block transfers.

Paul

OkiePC said:

It sounds like you have a good handle on it. EDIT: since you're set up as 1/4 racks, then you only need BTR/BTW for drive status. I would watch the standard input status words to determine if I needed to execute a BTR for example to retrieve a fault code, and stagger any BTW that were required to change settings outside the standard I/O handled by the scanner.

Click to expand...

I think maybe you're confusing 1/4 with 1/2? On a PF70/20-COMM-R, 1/4 Rack gives you two Input and two Output words. They are:
Input Word 0 - BTR Status
Input Word 1 - Logic Status
Output Word 0 - BTW Control
Output Word 1 - Logic Command

So, on a 1/4 rack config you HAVE to use BTR/BTW to do even speed reference and speed feedback. On 1/2 rack configs where you get 4 words then words 2/3 are the 32 bit feedback and reference respectively.

Yes, you are right, I was thinking 2 useful words in and 2 out, and forgot about the BT control words...