PLC5/40 Backplane Problem?????

Allen,

The block transfers, both read and write are called in LAD2.

The block transfer read is configured as such:

Module Type: Generic Block Transfer
Rack: 000
Group: 3
Module:0
Control Block: BT13:1
Data File: N14:20
Length: 20
Continous: No

The block transfer write is configured as such:

Module Type: Generic Block Transfer
Rack: 000
Group: 3
Module:0
Control Block: BT13:21
Data File: N15:40
Length: 37
Continous: No


The conditions for executing the block trnasfer read is the BT13:1/EN bit.

We are using the 1771-IFE analog module. The setup seems ok to me, from what I remember in setting up the BTR instruction. I still have to dig up the IFE's manual and setup to confirm the settings though.

The status of the control Block bits are as such when everything is running ok:

EN - Toggles ON and OFF
ST - Toggles ON and OFF
DN - Toggles ON and OFF
ER - OFF
EW - ON
RW - ON
CO - OFF
NR - OFF
TO - OFF

Now, this is what I saw, bits might suppose to be in different states, but I'm not sure.

When this fault happened last, like I said before, I was able to write over the data table file for the analog channel that wasnt working, but didnt try any other channels on the card. BTW, this fault occurs on different cards too. The happen to reside next to each other. They are Rack 0, slots 2 and 3. Each are used for various process transmitters.

Strange coincidence...

Thanks for the help, I'll keep posting if I find anymore information.

Andrew Evenson.
 
Andy, This is about the 4th time I,ve posted this, but its going to be relevant one of these days. This sounds very familiar to a problem we had sometime ago, there was a couple of strings here regarding our situation, one was titled phantom inputs. We were also using a 5/40, our situation was that we had inputs toggling at random with no voltage applied. We chased this thing for the better part of a year. We checked every possible thing we or anyone else could think of & found many things that were not necessarily right, but none led to the solution. All inputs were in the same board, we tried moving it to an open slot & re-assigning the addresses & the problem persisted with the new addresses. Finally the solution, there was another input board in the rack that had some corrosion on it from getting wet at some point. After changing that board the problem has not occured since. I would suggest you pull each board individaully & examine them closly for any signs of damage. We were also on the path of thinking the backplane was the culprit, man was I glad we didnt change it & still have the problem.
 
"The conditions for executing the block trnasfer read is the BT13:1/EN bit."

I think the condition should be "NOT BT13:1/EN". If the read is not enabled, enable it. It will not be enabled again until it is done. This gives you continuous reads, one after another. It mat be a good idea to include the XIC of the done bit of the BTW in the BTR rung.
 
say it isn't so

Module Type: Generic Block Transfer
Rack: 000
Group: 3
Module:0
Control Block: BT13:1
Data File: N14:20
Length: 20
Continous: No

The block transfer write is configured as such:

Module Type: Generic Block Transfer
Rack: 000
Group: 3
Module:0
Control Block: BT13:21
Data File: N15:40
Length: 37
Continous: No
I notice that the BT addresses are 20 apart. Is this because the programmer misunderstood the purpose of the length parameter? Is the next used BT address BT13:58? Are there block transfer instructions using BT13:2 through 20? If not, do those structures contain any data? perhaps referencing the IFE that is giving trouble?
 

Similar Topics

I am using the following formula and I am getting error, Invalid Expression - too many closing parenthesis. when i copy the formula to notepad or...
Replies
4
Views
152
Preface: Kinda long, so I made section titles Intro: I just want to see if anyone here has seen anything similar. A PLC5-40 series C enhanced...
Replies
3
Views
365
Hi, can anyone help me get a pdf file for this RSP files. They are from a PLC5. Thanks
Replies
5
Views
516
Hello all, I am seeing this behaviour where an integer file (N46:33), has an integer in binary (11110) which is 30 in decimal. I did a...
Replies
7
Views
516
Back
Top Bottom