Back to blog

Configuring 1747-SN Block Transfers to PowerFlex 70 via RIO

Configure a 1747-SN and 20-COMM-R without confusing discrete I/O, block-transfer I/O, and explicit messaging. This guide covers processor revisions, buffers, fault actions, diagnostics, and safe co...

A PowerFlex 70 can exchange command, reference, status, feedback, and selected parameter data with an SLC 500 through a 1747-SN Remote I/O scanner and a 20-COMM-R adapter. The difficult part is not creating one transfer. It is keeping three different data paths separate: the RIO discrete image, block-transfer I/O, and block-transfer explicit messaging.

The original project must be inspected before any edit. Record the SLC processor catalog, series and firmware; the 1747-SN slot and series; the logical rack and group allocation; the 20-COMM-R configuration; and the PowerFlex control source, reference source, masks, fault actions, and enabled Datalinks. A generic example cannot replace those installed details.

1747-SN scanner communicating with a PowerFlex 70 through a 20-COMM-R adapter

The 1747-SN owns the RIO link; the 20-COMM-R maps that link into the drive’s DPI command, reference, status, feedback, and Datalink data.

Confirm the supported architecture

The 1747-SN is the RIO master in the SLC chassis. Rockwell’s 1747-SN Remote I/O Scanner User Manual states that Series B or later scanners support discrete and block transfers. It also documents a maximum of four logical racks of discrete RIO data, with the exact adapter allocation configured in the scanner G file.

The PowerFlex 70 does not connect directly to Blue Hose without the appropriate interface. The 20-COMM-R is the RIO adapter described in Rockwell’s 20-COMM-R Remote I/O Adapter User Manual. Verify the adapter catalog and firmware rather than relying on an informal “RVC” description used in old drawings.

Before wiring changes, document RIO baud rate, rack address, starting group, rack size, termination, cable polarity, and the single-scanner ownership of the link. Use the cable and termination requirements in the manuals. Do not invent a star branch or long drop to accommodate a new drive.

Separate the three data paths

Discrete I/O

The discrete image is the cyclic control path. The 20-COMM-R manual places the Logic Command or Logic Status word in the discrete image and maps reference, feedback, and enabled Datalinks according to the configured rack size and adapter parameters. The exact bit definitions depend on the connected DPI drive, so use the PowerFlex 70 definitions in the adapter manual.

Command ownership must be explicit. Confirm the drive’s selected command and speed-reference sources, logic masks, and permissives before testing. A correctly changing RIO word cannot start a drive whose local input, HIM, or another port still owns control.

Block-transfer I/O

Block-transfer I/O moves the cyclic reference, feedback, and Datalink image when that image is configured for block transfer. The 20-COMM-R recognizes transfers of 18 words or fewer as I/O transfers. This corrects a common mistake in field notes that describes every transfer as a fixed 16-word block.

The distinction between scanner and processor revisions also matters. Series B or later applies to the 1747-SN scanner’s block-transfer capability. Native BTR and BTW instructions are tied to supported SLC processor series and firmware; Rockwell’s examples specify Series C processor firmware revision 3.xx or later. Older processor implementations use control and status buffers allocated in the scanner’s M0 and M1 files.

Explicit block-transfer messaging

Explicit messaging is for configuration or monitoring data outside the cyclic I/O image. The adapter manual distinguishes recognized explicit-message sizes from I/O transfers. It also warns against repeatedly writing parameter data to nonvolatile storage because frequent writes can consume the storage lifecycle. Frequently changing operating data belongs in Datalinks or the cyclic image, not repeated nonvolatile parameter writes.

Build the buffer logic deliberately

For a processor that supports native BTR and BTW instructions, configure the rack, group, scanner slot, control block, data file, requested word count, and M-file buffer address exactly as the manuals describe. Each block transfer needs a separate buffer region. Do not overlap control blocks or reuse a buffer before its prior transaction has finished.

For older processor logic, copy the application control and data structure into the scanner M0 buffer and copy M1 status or returned data into normal processor files. Access to M files adds processor scan time, so use multiword copy instructions as recommended rather than scattering individual M-file bit references throughout the program.

Regardless of implementation, expose enable, done, error, timeout, and last-success information to diagnostics. Re-enable a repeating transfer only after the preceding transfer has completed or errored. The RIO scanner processes one block-transfer request per remote rack scan, even though multiple requests can be initiated. An uncontrolled set of continuously retriggered transfers can therefore increase latency for every device on that rack.

Define communication and idle behavior

The 20-COMM-R has separate responses for a communication fault and for the controller leaving Run mode. Those actions may fault the drive, stop it, hold the last command, or apply configured data depending on the approved settings. Holding the last speed command after loss of communication can be unsafe in many applications; automatically stopping can also be unsafe where coast-down creates another hazard. The machine risk assessment and drive manual must decide the response.

Test both conditions during commissioning. Disconnect the RIO link under a controlled, non-producing state and confirm the configured communication-fault behavior. Place the SLC in Program mode under the approved procedure and confirm the idle-fault behavior. Verify the HMI shows communication quality separately from drive running or ready status.

RIO scanner diagnostics and PowerFlex status used during block-transfer commissioning

Scanner status, adapter status, transfer control bits, and drive state must be read together; no single LED proves the control path is correct.

Commission from the physical layer upward

Prove the RIO link

Confirm one scanner, correct polarity and termination, matching baud rate, valid rack and group allocation, and stable active-device status. Review retry counters and scanner diagnostics. Do not assign meaning to an undocumented hexadecimal code; use the error table for the installed scanner and adapter revision.

Prove receive data before enabling commands

With the drive safely inhibited, verify Logic Status, feedback, and any enabled Datalinks against the HIM or independent observation. Confirm 32-bit Datalink word order from the adapter manual. A plausible but incorrectly assembled value is not acceptable.

Prove command ownership and scaling

Send a stop command first, then a bounded reference while the drive remains inhibited. Confirm the adapter receives the intended command and reference. Only after status, ownership, masks, and scaling are proven should the approved low-speed run test proceed.

Prove recovery

Test cable loss, drive power cycle, scanner reset, SLC mode change, and restoration of communications. Confirm that commands do not resume unexpectedly after recovery and that a deliberate operator action is required where the risk assessment calls for it.

Document the interface as a maintained asset

Store the G-file allocation, rack and group map, discrete words, BTR and BTW control blocks, M0 and M1 buffers, Datalink parameter assignments, fault actions, and acceptance-test results with the RSLogix 500 backup. Relevant replacement hardware can be reviewed in the PLC and PAC systems collection, while cabling and interface components belong in the communication and networking collection.

Legacy RIO can remain serviceable when its data ownership and failure behavior are visible. The most important improvement is not more ladder logic. It is removing ambiguous series claims, undocumented status codes, overlapping buffers, and untested drive behavior from the maintenance plan.

Leave a comment

Please note, comments need to be approved before they are published.