Using the CLR with Control files

Hi, I hope someone can help. I have an old program written in 1991 for a plc5. When using rslogixs to move the program from one plc to another it runs a verify and tells me it does not accept the CLR command for R (control) files. it says i have to specify them to word level then it won't let me input the file as R72:0.0. I have tried using the RES command instead but it didn't respond too well. Can anyone help me out or point me in the right directin to find the info to reprogram these files to Clear. I'm not sure if the CLR clears out the whole word 0 or just the internal info. this is driving me crazY!!!! any help would be appreciated.

Try the MOV and move a zero, or the COP for multiple words.

the mov still does not clear up "the address must be specified to word level".i need to be able to clear the contents of the r control files.

I suspect you have to clear the elements of the file rather than the file themselves. I.e. CLR R72:0.POS, CLR R72:0.LEN, etc. You could even use indirect addressing to clear a bunch at once, i.e. CLR R72:[N7:0].POS. For the bit elements like DN use OTU.

no i think it wants to clear the whole file. rslogix won't even recognize the element names when i use them. it still is telling me that it is not addressed correctly. i'm at a loss??? would you know how to get programming info?? i've looked on line and it is not clear where to get manuals or info????

Try here:

http://tinyurl.com/orh3j

I've not encountered anything like you're describing. CLR R72:0.POS should work. OTU R72:0/DN should work. If RSLogix5 isn't even recognizing the element names something more is going on. Corrupt file on your disk? Is file 72 really an R file or is it something else?

CLR, for reference, just moves 0 into the destination (functionally equivalent to MOV 0 destination). RES only works with timers (T) and counters (C).

when i type in r72:0.1 it reverts to the len which makes sense then i type in the r72:0.2 it reverts to r72:0.pos, which is also correct, when i type in r72:0.0 it says it is not address in word level, i think it's a bug in the program??? what do you think??? i got on to the rockwell site and left a message maybe they will get back to me. it doesn't look like rslogix5 is going to let me clear this file the way it used to be done. i've tried the mov going into r72:0 and is does the same, even if i use r72:0.0.

No, R72:0.0 wouldn't be a word, those are the control bits -- EN, EU, DN, etc. You can't use CLR or MOV to clear those bits. You'll have to use OTU instructions to clear each bit that you need to clear individually (note not all instructions use all of these bits; FD is only used by FSC, UL is only by BSL/BSR, etc).

And it's best if you stick to the correct element names (POS, LEN, EN, DN, etc) rather than punch in .0 or .1 and expect the software to "translate" for you, not just for R files but for all of the special ones (T, C, MG, PD, etc). You may get a translation you're not expecting.

Are you really sure that you want to clear (CLR) the .LEN word? I can understand that you might want to reset the position (.POS) and the status bits but resetting the length seems unusual.

The RES can be used to reset the position but it may or may not reset all status bits. That will depend on what instructions are using the control address.

As mentioned earlier, you should use the standard element naming conventions such as .POS or .LEN instead of the word numbers. When troubleshooting this logic the user won't be able to find any reference to R72:0.1 but they will likely find and see R72:0.LEN.

OG

What, exactly, is the aim of this clearing? Since control registers are involved, what are the instructions they're used in?

the instructions are for moving message data from the plc to data highway. so we move the data then clear the control file when done.

???

You should be using a MSG instruction to send data out over DH+ if it's to another PLC, and you can't use an R register to control a MSG instruction. Only an N or MG register.

Unless you mean you're formatting the data before sending it out, via a FAL instruction or something similar?

from post #7:

Techqueen said:

when i type in r72:0.1 it reverts to the len which makes sense then i type in the r72:0.2 it reverts to r72:0.pos, which is also correct, when i type in r72:0.0 it says it is not address in word level, i think it's a bug in the program??? what do you think??? i got on to the rockwell site and left a message maybe they will get back to me. it doesn't look like rslogix5 is going to let me clear this file the way it used to be done. i've tried the mov going into r72:0 and is does the same, even if i use r72:0.0.

Click to expand...

I'm still a bit unclear on this. Is the intent to clear the 'buffer', that is, the collection of words which was sent with the message instruction? Or, is the intent to reset the control structure (R72:xx)?

If the former then if a MSG instruction is used there is no absolute need to clear the buffer - the MSG control bits will handle the internals. All you need do is load/format your outgoing data and trigger the MSG (make the rung go true).
If the buffer absolutely, positively must be cleared, there are any number of ways to do this.

If the latter, there's a way to clear control files also. The elements in the control word (pos, len, ctl) comprise a structure. The programmer is allowed direct access to only two of these elements, POS and LEN. To access CTL you need a separate file instruction with LEN=3. As in;

new control len source destn
FLL R6:73 3 0 R6:72.POS

<excuse the formatting, this editor will not allow multiple consecutive spaces>

I don't remember which element is specified in the destn, you'll have to experiment or wait 'til I refresh my memory at work.

With a properly built FAL, you could also pull out the three elements into another three words for observation.



On a side note, the RES instruction does work with control registers. The only thing I've found it won't do is clear the INhibit on an FSC instruction

Just wanted to thank everyone who helped. I used the OTU commands for all the internal elements of the R file and it looks like the program is working correctly. Thanks Again!

You Guys Rock!