RsLogix 5k V28, 1756-L73CPU value update. (MOV) and (CLR)

[BiteBytesButes]

Hi All,
This topic it is really interesting indeed.
Hi have a doubt that is inside this kind of questions:
RSLogix 5k V28, 1756-L73CPU value update.
I came across a ladder program with a line with something that for me is a doubtful functioning.
What do you think about this at below, this works fine?
****
The ladder line have a REAL value that is MOV to an REAL Word1, (with a MOV instruction).
In the same ladder line (so..in series), the same REAL Word1 it is CLR. (with CLR instruction).
In my opinion the value that it is moved first ''REAL value that is MOV to an REAL Word1'' never it is updated and processed in the REAL Word1, because the last instruction (CLR) will clear the content.
I mean, this lines does not nothing and the result will be always ZERO....right?
Of course that during the PLC cycle, I cannot see the value to be updated in the Real Word1.
***
What do you think?
Any tips?
Thank you gents!
3B

 

[widelto]

If you move a real value to word1(real) and on the same line you clear word1, then word1 will always appear as zero.

 

[plvlce]

Is there a reason for duplicating a topic of discussion from another thread three days ago? http://www.plctalk.net/qanda/showthread.php?t=126968

 

[parky]

There are a number of scenarios here, any value that is in Tag 1 will be transferred to Tag 2 before Tag 1 is cleared, this could be populated elsewhere in the program scan so will be what value is transferred to it after or before the clear. If you cannot find any reference to the Tag 1 being written to anywhere in the program then there are 3 possibilities
1. This is done indirectly.
2. Data from communications i.e. another source like HMI, another PLC etc.
3. Yep it is a bit of redundant code that has no impact on the process.
On 2, would only have reliable data that could be reset if some comparison to enable the move & clear instruction i.e. need some logic that enables the move/clear if data in Tag 1 is valid due to communications generally is not synchronous.

 

[BiteBytesButes]

Hi plvlce,

The other topic was not mine, I was taking an thematic advantage because it was very similar to that one. when I posted here, there was still no answer on the other side.
And from what it seems to me, continue it without any answer. It doesn't bring any confusion, does it?
appreciated!
3B

 

[BiteBytesButes]

Hi widelto......Yes, it is what I think as well, tks!

Hi parky...I know what do you mean, right. But in this case it is just as I explained and it is just one word in this single line indeed, the Word1.
The ladder line have a REAL value that is MOV to an REAL Word1, (with a MOV instruction).
In the same ladder line (so..in series), the same REAL Word1 it is CLR. (with CLR instruction).

tks
3B

 

[parky]

Lets look at this in detail. Firstly as pointed out earlier the outputs (real I/O) are not what you generally set in your program but an internal memory area (map) that is transferred at some point to the real I/O, The exception to this is Peripheral update (some PLC's you can update actual I/O any time). so in general out instructions are valid at the time they are processed in the code. not to be confused with interrupts or I/O update. On-line status may not show the actual status at that point the instruction is processed because the communication will not be synchronous with the scan processing so could show true or false, depending when the status is read.
I agree if you move a value from a word to the same word & then reset it then it will always be 0, It could be that for some reason the original programmer used some other word originally, but did not use it so just to ensure it was 0 removed the original word & stuck in the same word. a bit like to make an always off contact you put a AND My_Bit AND NOT My_Bit = My_Bit. (some do this as in the early days there was no TRUE or FALSE Bits).
I have seen this sort of code a number of times even zero on timer pre-sets.
Often programmers leave things like this in just in case they need to alter it but forget or don't bother to take it out.

 

[daba]

We cannot see any code, but I have thought of a scenario where that MOV instruction may be critical.

In the execution of the MOV, the controller's arithmetic status bits will be affected, so the MOV may be just the programmer's way of testing whether the value in Word1 was positive or negative.

I would not be flagging it as "redundant" code just yet ....


EDIT : I have just checked, and the CLR instruction also affects the status bits, so what I said above goes out the window ....

 

[daba]

I often use a MOV tag1 tag1 instruction to enable me to "see" a value that may be used locally, in a CPT expression, for example, but I cannot fathom why the programmer has followed it up with a CLR, it does appear to be illogical ...

 

[daba]

If you move a real value to word1(real) and on the same line you clear word1, then word1 will always appear as zero.

That is not 100% true. There is a measurable period of time (albeit small) where word1 may not be zero.

After the MOV has (potentially) changed the value of word1, the "System Overhead Time Slice" could be executed, and word1 could be read by another system at its new value.

Or there could be a Periodic Task triggered (which has a higher priority than the continuous task), which will see the value in word1 before it is cleared once the interrupting task is complete.

Or there could be an Event task triggered (also a higher priority than the continuous task).

For a very small percentage of the time the value in word1 maybe not zero.

But for all the underlined words above, this code makes no sense, in that there is no concrete in its structure, and I cannot think of any reason it is there.

I have to say it is perhaps a "leftover" and now no longer relevant.

But to be honest - don't remove it if the rest of the code is running fine, you never know what tricks some people pull.

"If it ain't broke, don't fix it"

 

[parky]

#1 Daba, That is the conclusion I came to. If this was just something that was a quick & dirty disable of some value of redundant code then it is not doing any harm, however, without going through the entire code & what other connections there are you will never know until you removed it what the implications are, if it works then leave it.

 

[widelto]

@Daba: Your possibilities are true, but it is nonsense to do what the OP mentioned, that kind of programming is the right one to have a nice conversations with some beers nearby.
Daba thanks, anyway.