Understanding M files

Need a little help understanding M files. I have an SLC 5/03 with a 1747-SN in slot 4. On the other end are two racks, one 3/4 and the other a 1/2 rack. Each has a 1747-ASB Ser A in slot 0.

In the 3/4 rack:
1747-ASB
16 point 120VAC input
8 point 120VAC input
8 point relay output
8 point relay output
1746-NI4
1746-NI4
in that order from slot 0 to slot 6
1747-ASB dip switch settings in this rack:
SW1 - All on
SW2 - All on except 3 and 7
SW3 - only 2 and 5 on

In the 1/2 rack:
1747-ASB
16 point 120VAC input
8 point relay output
1746-NI4
8 point relay output
In that order from slot 0 to slot 4
(This is actually a 7 slot rack but the last 2 slots are empty and the G file is configured as a 1/2 rack)
1747-ASB dip switch settings in this rack:
SW1 - All on except 6
SW2 - All on except 3 and 8
SW3 - only 2 and 5 on

So....in the program there is a COP instruction reading #M1:4.310 and copying it to an integer location. This seems to me to be reading channel one of the second NI4 in the 3/4 rack (slot 6). This is an analog pressure transmitter. My question is, how was it determined that .310 of the M1:4 file was the place to get the value of channel 1 of the NI4 in slot 6 of the 3/4 rack?

Thanks,
Shawn

What you're looking at is the old style of Block Transfer programming in the 1747-SN /B module. "M1" is the "Input" data to the SLC, and "M0" is the "Output" data to the Scanner.

The 1747-SN scanner has 32 buffers of 64 words each, which are used for Block Transfers. To make them slightly more human-readable, they start on 100-word boundaries. Where the 1747-SN is in Slot 4:

M0:4.100
M0:4.200
M0:4.300...
M0:4.3200

Generally you use a pair of these (M0:4.100 and M1:4.100, for example) for a Block Transfer instruction. The M-file blocks hold the function and address information as well as the actual data payload.

You'll probably find another COP instruction that copies data into M0:4.300, length 3. That's the Block Transfer Read command and address block.

So why does the first channel of the 1747-NI4 module data begin on M0:4.310 instead of on word .303 (after the three Status words for that BT) ? I'm not totally sure. I can start looking if it's important.

The 1747-SN module User Manual is really very thorough about the use of Block Transfers in the module. The Knowledgebase also has numerous RSLogix 500 examples.

About the "old style" programming: all that M0/M1 file logic was wrapped up into the BTR and BTW instructions in the SLC-5/0x operating system about seven years ago with the introduction of the "Series C" SLC-500 operating system.

You can still run the old logic and it will work fine in a modern SLC.

I did find a nice concise Knowledgebase document describing the introduction of those instructions: AID #31770.

That document reminded me of something that the 1747-SN user manual only implied: a 1747-SN/B block transfer buffer is laid out like:

M0:s.0 - 9 Status Words
M0:s.10 - 74 Block Transfer Data Payload
M0:s.75 - 99 Unused

That's why the 4-word block of Input data from your 1746-NI4 module starts at M1:4.310.

Thank you Ken!

In the 3/4 rack:
1747-ASB
16 point 120VAC input
8 point 120VAC input
8 point relay output
8 point relay output
1746-NI4
1746-NI4


So why is the NI4 in slot 6 word 300? There are not 128 words of data preceding it. Do the I/O in slots 1 thru 4 reside in word 100, the NI4 in slot 5 in word 200 and the NI4 in slot 6 in word 300?

Shawn

You have to separate your thinking about those M0 and M1 files from the Input and Output data files in the SLC. They're selectable "buffer" or "mailbox" type resources.

You have to execute a Block Transfer Read or Write in order to get data to or from an analog module. You choose one of the 32 buffers for each BT instruction you put into ladder logic.

They don't have to be used in sequence and aren't related to the slot number of the module they're targeting.

The first four I/O modules in that chassis will be "mapped" by the 1747-SN Scanner into the discrete Input and Output data table for the 1747-SN. But the Analog modules can use any of the buffers, and can use any Integer file in the SLC for the source or target.

Yes, that makes perfect sense about the discrete I/O.

On to the block transfer. This program does not contain a single BTR/BTW. Are you saying that, in my case, using COP to copy data to/from the M files is the equivalent of a BTx command? Where would I find whatever in the program configures the NI4 in question to use the .300 word addresses?

Thanks,
Shawn

You're exactly right: the original method for block transfer involved COP instructions to and from the M0 and M1 files. Look for COP instructions that reference M1:4.300 and M0:300.

The SLC operating system "Series C" added the BTR and BTW instructions. They really just encapsulate the copy logic.

Ken Roach,

I like some of your posts. Are you still responding these days to questions?

Yes, Ken is still an active member.

Hello everyone,
specially @ Ken Roach and @shawn_75. I followed this interesting thread as I have a very similar situation, and kind of have the feeling that this question was not answered.. So, I do have the same question.
Where would I find whatever in the program configures the NI4 in question to use the .300 word addresses?
I hope someone can answer it for me.. Thanks very much in advance..
Really good thread

Welcome to the PLCTalk forum !

In order to let very old threads stay dormant, I have created a new thread with your question that should appear at the top of the Q&A page right now:


https://www.plctalk.net/qanda/showthread.php?p=934131


Please make your follow-up posts under that thread.

Just curious, i don't remember using BTR and BTW commands with the 1746-QS. We just used COP commands. When were BTW and BTW commands introduced and what did they do that COP commands didn't do?

I wrote the assembly code that handled the data transfers between the PLC and the M files and the M files and the motion control CPU. I know it wasn't very efficient because there was a lot of hand shaking that had to go on to keep the PLC and motion control CPU from accessing the M files at the same time. Transfers had to be small to keep from "hogging" the M files for too long. I/O registers were very efficient. They were double buffered.

The SPIOGA chip handle the I/O for the scanner and other I/O intensive modules like the 1746-QS. SPIOGA stands for special purpose input output gate array. Some one at Rockwel had a sense of humor. The SPIOGA chips were stamped potato as in potato chip.

The BTR and BTW instructions were added to the SLC-500 instruction set in about 2005, as part of the "Series C" operating systems for the SLC-5/03, /04, and /05.

That was roughly coincident with the last big hardware change to the SLC family, the addition of a 10/100 Ethernet daughtercard on the SLC-5/05. You need a 1747-SN Series B to use block transfers of either old-style or BTR/BTW; there was no 1747-SN change made to support those instructions.

All they did was encapsulate the buffer-handling logic in an instruction that was easier to use and similar in look-and-feel to the way those instructions appeared in the PLC-5.

Thanks Ken, the explains a lot and why I didn't know about the BTW and BTW. I can see why these instructions were added. These must have broken down big transfers that would happen over several scans. As I said above, the PLC or motion controller CPU couldn't "Hog" the M files for too long and I mean microseconds.