Problem with BTW & BTR in PLC-5

No, No, No,

Enter the rungs which-ever way you want to.

Enter the data manually into the BT data structure.

Double Click on the BT file, find the structure numbers you want to use with the BTR and BTW. Manually enter the Rack Group and Slot in the data monitor, NOT on the logic.

(8{)} ( .)

(Yosi)

Gsquare,

what Yosi has been advising is that you do NOT worry about how you enter the BTW/BTR rungs ... instead go directly into the data tables – while online – and try entering the “Rack – Group – Slot” information manually ... here is an EXAMPLE of the area we’re talking about ... just make sure that you use the appropriate area for YOUR system! ...

[attachment]

if the values are automatically changed back to “zero” then SOMETHING is overwriting the data table and this is what is causing your problem ...

the SOMETHING could be in your ladder logic program ... let us know if the values “change back” or if they “stick” with what you’ve entered ... then we can go further ...

I made a quick search for the most common culprits but nothing obvious appeared ... once we know the results of Yosi’s experiment, then we’ll know whether or not we need to keep looking along that path ...

also ... the SOMETHING changing the values could also be an HMI application or other operator interface which is networked to your PLC ...

and please tell us: exactly what “Rack – Group – Slot” addresses are you trying to enter? ... are the “problem” Block Transfers included in the OFFLINE program that you posted? ... if so, please tell us exactly which ones they are ... you have 18 BTW’s and 18 BTR’s already in the program ... are these all OK? ... are you trying unsuccessfully to add some more? ... or do some of these existing BTW/BTR’s “zero out” when you download the program? ...

I haven’t had time to dig COMPLETELY through the program you posted, but from what I’ve seen so far, everything in your I/O and channel configuration LOOKS OK ... I’ll keep looking as my work schedule permits ...

Thanks for posting the graphic Ron. A picture is worth 1000 words.

(8{)} ( .)

(Yosi)

Problem with BTW and BTR in PLC-5

Dear friends Yosi and Ron,

I double clicked on the BT:23 file (in Online Mode) but could NOT enter any values under R/G/S. Simply because these fields are NOT editable. Whereas the fields EN ST ........ RLEN DLEN FILE ELEM ARE editable. The R/G/S field in the BT file gets filled only when you insert a RUNG containing BTW or BTR. Just try this out at your end.

Ron special thanks to you for your graphics. It made clear what Yosi has been repeatedly asking me to try out.

So as you see the experiment has failed. But we won't give up.

Waiting for the next posting from both of you.

Kind regards,

Gsquare

GSquare,

Please check and see if BT23 is write protected.

To check this put the cursor on BT23 in the Data File tree and right-click. The Read/Write privileges are at the bottom of the window.

Good Luck,

(8{)} ( .)

(Yosi)

Problem with BTR & BTW in PLC-5

Yosi,

I already checked out the obvoius. NO the BT:23 file in NOT write protected. I am wondering how are you able to enter any data into the R G S field. I don't think that is possible (without entering rungs). Please give it a try at your end.

Regards,

Gsquare

P.S. I am missing Ron. Where is he ?

I see your point.

Regardless you should be able to move data into it.

If this is a problem you most definitely can write into an integer control block.

the 1st word of the block contains the RGS data.

Set the radix display for the Hex display.

The low byte contains the RGS value as follows:

Bits 4-7 contain the rack number
Bits 1-3 contain the group number
Bit 0 contains the module number.

If your module is in rack 0-7 you can use the integer block. For racks > 7 you'll need the BT block.

If you've got a problem figuring out the proper data, post your RGS and I'll calculate the value for you.

No, I don't know where Ron is.

Oh yeah, almost forgot. This has nothing to do with the BT problem. I was scanning through your code and noticed that you were doing a BCD to Int conversion, dividing by 10 and putting the results in a float. FYI you don't have to do this in a loop. You can use an FAL instruction to do this on one rung (like this: FAL R6:0 6 0 ALL #F8:117 (FRD #N19:117) | 10.0 )


Good Luck,

(8{)} ( .)

(Yosi)

Greetings to all,

no, I haven’t gotten lost ... just doing some money making work for the boss man ... incidentally, I don’t even have an internet or email connection at home ... it’s my way of keeping family life and my work life separate ...

anyway ... I’ve had a little bit of time to do some more exploring through the posted program ...

[attachment]

even though Gsquare hasn’t really answered all of my questions, it looks like the highlighted modules are the ones he’s having trouble with ... when I right-click the IFE and select “display module”, I can get right to the module configuration screen ... even though there are no block transfers for this module present in the ladders ...

on the other hand, when I right-click on either of the OFE’s and select “display module”, I can NOT get to the module configuration screens ... and again, there are no block transfers for either of these modules present in the ladders ...

these conditions make me think that the entry of the IFE was somehow aborted part way through the module insertion process ... if I’m correct in this, I suggest the following plan of attack ...

first right-click on the IFE module and then DELETE the IFE module from the Chassis Display table ... if you’re prompted to “Delete I/O points” do that too ... once the module has been completely deleted, then shutdown the RSLogix5 software ... completely ... then start it back up ...

now go back and reinsert the IFE module again ... when you reach the “Enter Module Addresses” screen and are prompted for the addresses associated with the block transfers, go ahead and click the “Auto Pick” button ... BUT ... before you click the “Done” button, CHANGE the block transfer control block addresses to something completely new ... I’d suggest using a brand new BT24 file ... yes, I know that the BT23 file (named “NEWBLOCKXF”) is already available and unused ... but I’d still go ahead and make a new one ... of course this step will have to be done with the processor in the Program mode ...

now display the module configuration screen and go through the regular setup procedures ... then while still on the module configuration screen, have the software automatically add the block transfer rungs ...

finally, with the processor still in Program mode, (cross your fingers) “Accept” the new rungs ... maybe that will fix your problem ...

IF (and that’s a big IF!) this procedure works, go back and try the same approach on the OFE modules ... be sure to reinsert them one at a time ... and I’d recommend that you shut down RSLogix5 completely after deleting each module and start up fresh before you reinsert each module ... this might be overkill but what-the-heck ... and make CERTAIN that the addresses that you manually type in for the OFE block transfers are unique ... specifically, do not overlap the addresses used for the IFE ... or for the first OFE while inserting the second OFE ...

finally ... I’ve seen situations like this happen in the classes I teach ... once in awhile while installing an IFE module, a student will somehow get the system “hung-up” and be unable to continue ... it only happens on very rare occasions so I’ve never been able to identify exactly what sequence of operations causes the problem ... all I know is, when we go through all of the steps I’ve listed above, we can successfully get the thing to work ... I do know that this “insert-the-new-module-and-automatically-write-the-rungs” procedure is taken care of by an “applet” in the RSLogix5 software system ... my best guess is that when the programmer gets something in the normal sequence of events out of step, then the “applet” gets hung in a loop or something along those lines ... shutting down and restarting the RSLogix5 software seems to “make it better” ...

anyway ... I’d try this out ... if it doesn’t work, let us know what happened ... I’ll be setting up the lab this weekend for a class next week ... if all else fails, I’ll be glad to try to set up an extra chassis with an ASB adapter and try to duplicate your problem ... let me know if you need me to do this ... I should be able to have the results by Monday or Tuesday ... BUT PLEASE – tell me exactly how you have the DIP switches on the chassis backplane and on the ASB adapter set up ... we’d certainly like to be able to compare apples to apples here ...

and incidentally, I’ll try that Online “manual write” to the BT files at lunch ...

I think I might have found it!

short on time but here's the latest ...

I found an old copy of RSLogix5 version 3.2.0.0 ... I opened Gsquare's program and downloaded it to a spare PLC-5/40E ... I let the software write the BT rungs for the IFE ... I "accepted" the BT rungs in the Program mode ... it worked fine ... I let the software write the BT rungs for the first OFE ... I "accepted" just one of the BT rungs in the Program mode ... it worked fine ... I put the processor in Run mode ... I "accepted" the other BT rung ... the rack-group-slot numbers went to ZERO just as Gsquare has been reporting ...

so is that it? ... try accepting the rungs in the Program mode and see if it works ...

will try some more experiments later tonight ... got to get back to work now ...

good luck ...

The BTW and BTR problem

Yosi and Ron,

This is in reply to Yosi's post:
(1) Regarding trying out "integer control blocks". Since my Rack number is begining at 12 (which is > 7) I won't be able to use this method. At the same time I would like to learn about this method of addressing an Analog module. The 1771-IFE/C user manual in my possesion does not describe any such method. Can you please suggest some manual which I can download from the net. To be frank the method is not yet clear to me.
(2) Thanks for your tip on BCD to INT conversion. I will surely implement it on the next oppurtunity.
(3) Once again, please try out wrting R G S numbers (either in OFFLINE or ONLINE mode) to a BT file. I still maintain it is not possible.

This is in reply to Ron's post #23

Nice to have you back Ron - with very detailed explanation as usual. Here are replies to you queries and obsevations:

(1) You are right, the highlighted modules are the ones which are giving me problem. Although I have discovered ( and also told you earlier) that this problem in generic in nature and applies to any BTW or BTR in the system. At the same time I must clarify that all the existing BTR and BTW in the program (which are meant to read from older 1771-IFE and 1771-IR cards) are functioning properly.

(2) When you right-click on the IFE module and select "display module", you get right to the module configuration screen. The reason is that there is an intermediate screen which allows you to "Auto Pick" or manualy insert addresses forthe module. I have already passed through this intermediate stage of assigning "BT" and "N" addresses hence you come directly to the "insert ladder rungs" (or configuration) screen.

The same thing does not happen for the OFE modules because I went through the entire steps for these modules and when theI addresses became zero I simply deleted the modules. I again re-inserted the OFE modules before sending them to you and Yosi.

(3) I kept on inserting modules... configuring addresses...inserting rungs... all becoming zero on "accept"... finally deleting the module so many times, I may have stopped somewhere in the middle. Hence the process may SEEM "aborted"

This is in reply to your Ron's post #24

As of now I simply cannot go to program mode because the Mill is running and the Pumps would trip. I think you have just hit the nail on head. I have to wait till 26th July (Monday) to try it out( there is a Mill Shutdown). Please wait till my next post on 27th July. Do you have any more suggestions ? Meanwhile can you please try to write R G S numbers to a BT file in OFFLINE/ONLINE mode and confirm if that is possible or not ?

Many thanks and regards,

Gsquare

Hi GSquare,

I checked and indeed, you can not write directly to the .RGS register in a BT block. You probably can, however, use a MOV instruction to write into that register.

What I recommend that you do is as follows:

1) Find a BTX that uses the BT data structure. Make sure that it addresses a rack number >= 10.

2) Write a MOV instruction that moves the .RGS register into an integer register.

3) See how it's formated in the integer register and MOV the value back to a free BT structure's RGS register. Monkey around with it until you've got the proper RGS.

Hope this helps and keep us posted.

Good Luck,

(8{)} ( .)

(Yosi)

bingo! ...

Greetings, Gsquare and Yosi,

I had some extra time last night and I think that I’ve nailed it down completely now ...

when I used RSLogix5 version 3.2.0.0 (the same “older” version that Gsquare is using) I had the following results:

every time I “Accepted” a Block Transfer rung while the processor was in Run mode, the entries in the Block Transfer would “zero out” exactly as Gsquare has been reporting ... this was true both with the copy of GSquare’s program AND ALSO with a brand new program with NO rungs other than the Block Transfer rungs ...

every time I “Accepted” a Block Transfer rung while the processor was in Program mode, the entries in the Block Transfer would NOT “zero out” ... specifically, the software worked correctly as long as the processor was in Program mode when the Block Transfer rungs were “Accepted” ...

I also wrote several Block Transfer rungs Offline ... these rungs could be “Verified” and then compiled with no problems ... I could then download the program containing the Block Transfer rungs to the processor with no problems ...

also to be noted: I tried Block Transfer control blocks using both BT-type addresses and N-type addresses ... the results with the N-type control blocks were the SAME as those obtained with the BT-type control blocks in ALL cases ...

going further ...

when I used RSLogix5 version 5.50.00 (a much later version than the one that Gsquare is using) I had the following results:

every time I “Accepted” a Block Transfer rung EVEN while the processor was in Run mode, the entries in the Block Transfer would NOT “zero out” ... this was true both with the copy of GSquare’s program AND ALSO with a brand new program with NO rungs other than the Block Transfer rungs ... specifically, the newer version of software worked correctly in ALL situations ...

based on all of this, it looks like a “bug” in the older version of RSLogix5 software has been causing all of Gsquare’s problems ... naturally I suggest that he upgrade his software to the current version ... in the meantime, a simple work-around appears to be that the new Block Transfer rungs could be “Accepted” while the processor is in the Program mode ...

[attachment]

finally, personally I learned that you cannot write directly to the Rack/Group/Module area in a BT data file ... I’d never tried this before and I just “assumed” that you could ... well, you know what they say about “assuming” things like that ...

thanks to Gsquare for an enjoyable exercise on the darker side of RSLogix5 ... and to Yosi for his assistance and especially for keeping the troubleshooting project on track ...

Way to go Ron!

Here's your cigar.


(8{)} ( .)

(Yosi)

BTW & BTR

Ron and Yosi,

The Mill shutdown has been postpnd to next week. I am about Ron's findings are correct. Will give it a final try next week and let you guys know the result.

Regards,

Gsquare

Why don't you give us the desired RGS for the module so that we can give you the proper value to move to the .RGS register.

That way you'll be able to program the BTR/W even if you don't have the upgraded software.

Ron, any comments?

Good Luck,

(8{)} ( .)

(Yosi)