Block Transfers Executing Very Slow

I am trying to fix some comms issues on a slc 5/04 system with a pv 1000 standard ,2 flex i/o racks and 7 PF700 drives communicating via RIO.

The original program has many comms lockups and i have a theory that it may be because it has 25 old sytle block tranfer instructions and 15 of those were being fied at the same time. It is my thought that only one blocktransfer should be executed at a time. Is this correct? or can multiple be executed at one time? If so how many at once?

I changed this code to the new box style block tranfer instruction and i have them firing one at a time using a counter as a sequencer when i get the done bit from a btr/btw then i update the counter which allows the next one to execute but it is taking 3-5 second for each instruction to execute and give a done bit. Which makes the pv comms time out. Why would it be taking so long with only one instruction executing at once?

Any ideas? is there a max amount of block tranfer instructions that can be used in the slc 5/04? Am i over that limit with 28?

There are some unsed words so i may be able to get it down to 24 if needed.

You can have one block transfer per logical rack. So, I would only interlock those that are assigned to the same logical rack.

You are limited to 32 block transfers in total.

I would also take a close look at the status counters for the 1747-SN. If you are getting a bunch of retries and/or errors, there may be a cabling issue or electrical noise.

You have to copy those M1 addresses into a data table in order to view them. They can be copied from M1:e.16 through M1:e.31 for the primary I/O where "e" is the scanner slot number.

Paul

So it is okay to execute all locial racks at the same time but just interlock the transfers for each rack?

Ab support had told me on only execute one block transfer at a time so thats why i did it that way but they did not tell me that was per rack. I have some downtime friday and i will try this.

I have the old style transfers in another sub that is not be scanned so i can switch back and forth and the old sytle work well as they allways did.

I checked for errors and retries using netdecoder and everthing is as it should be just the speed is causing the pv to time out.

Thanks for the tips okie.

The Plc Kid said:

So it is okay to execute all locial racks at the same time but just interlock the transfers for each rack?

Click to expand...

Yes. If the destination racks are unique, then the transfers should be able to occur simultaneously.

The Plc Kid said:

Ab support had told me on only execute one block transfer at a time so thats why i did it that way but they did not tell me that was per rack. I have some downtime friday and i will try this.

Click to expand...

Look in the 1747-SN manual chapter 5. Also, in the chapter that details calculating throughput, it says "The RIO network allows only one BT per logical rack (not logical device) per RIO scan. Therefore, if multiple BTs are performed on devices within the same logical rack, BTs will have to wait in the queue until any previously scheduled BTs for the same logical rack have been completed."

The Plc Kid said:

I have the old style transfers in another sub that is not be scanned so i can switch back and forth and the old sytle work well as they allways did.

Click to expand...

So the original programming has comms lockups, but works better than the new style? Can you better describe the comms lockups?

You may want to consider switching the Panelview to DH+ and putting it on channel 1 of the 5/04. It means buying another panelview and running a separate blue hose, and might be affected by the current deployment of that channel...

The Plc Kid said:

I checked for errors and retries using netdecoder and everthing is as it should be just the speed is causing the pv to time out.

Click to expand...

I think you should be able to only interlock the transfers on a rack by rack basis. That's how I've always done it and have not had problems. I have not had 25 of them in one SLC though.

Another thing to look at is to make sure all of your buffer numbers are unique.

"BTR/BTW Buffer File - Block transfer buffer file address; i.e. M0: e.x00, where “e” is the slot number of the scanner and “x” is the buffer number. The range of the buffer number is from 1 to 32. Each BTR and BTW instruction uses both the M1 and M0 files for a specific buffer number. M0 is used for BTR and BTW control and for BTW data. M1 is used for BTR and BTW status and BTR data."

Hope this helps,
Paul

Paul

They have a btr using m1:1.1400 then a btw below it using m0:1.1400 so if i understanf you correctly this is a major problem? Because the first btr is using m1:1.1400 and m0:1.1400 correct?

They also have some where they use buffer file m0:4.410 but why starts at 410 vs 400? is there a reason for this? many of them are this way.

With the buffer files like that how is it working with the old style or the new? I don't see how it couldbe working at all but it does?

When you say copy the m files into the data table to view them do you mean copy to an integer file of the same element length?