Question about tags values stored in memory after PLC scan

Hi. I'm a beginner at programing and my question is about the MOV instruction at RSLOGIX.

First of all I dont have any practicals issues with this question, it is more related to understanding how a PLC scan works.

I got a program from a client and now this program is offline. A MOV instruction has a source value of.. let's say.. 30. But the destiny here has a value of 40 while the program is off.

My first thought on this subject was that the program should have other instructions using the destiny tag before the end of the program. But I checked it and didnt see any instruction related to it.

So the only other thing I could think of is that when the PLC took the picture of the values to show it on the screen, maybe it got the processed value from the destiny tag, but a newer value of the analogic input (which is the source tag) that is now different from the value used to move to the destiny tag earlier.

Is that how it really works or am I getting things here wrong?

I believe you got it correct. A value in memory will not change unless the instruction is executed or manually put in. (Memory Retentive Area)
The PLC usually scans from left to right, top to bottom with the results available for the next rung.

https://accautomation.ca/who-else-wants-to-know-how-a-plc-scans/

Regards,

If the MOV command had any conditions before it then possibly those weren't true at the time and the Source value had changed.

...or someone went into the data monitor and manually changed the value in the destination to 40 with the plc in program mode. OR someone did the same thing to the offline file. Either would result in what you are seeing.

Keith

My money is on Bernie's suggestion.

But if the MOV instruction in question here did happen to be unconditional (no other instructions on the same rung) then it is "possible" that the last save occurred mid execution before the destination tag was updated. It does happen.

Revnus said:

...RSLOGIX...My first thought on this subject was that the program should have other instructions using the destiny tag before the end of the program. But I checked it and didnt see any instruction related to it...So the only other thing I could think of is that when the PLC took the picture of the values...

Click to expand...

I'm not sure if you mean "RSLOGIX" as in RSLogix 500 or RSLogix 5000? But seeing as you are mentioning "tags"...

The key aspect to learn or take note of here is that tag values, no matter where they reside, be it in within the Monitor Tags window, or assigned as operands within logical instructions, may change value from other sources irrespective of the current execution status of said instructions. This is especially so with live process values which may be constantly changing. Tag values are not solely governed by the execution of instructions. Think also the likes of HMI terminals, Message instructions (MSG) or Produce/Consume data which may also update tag values from sources external to the controller, whether or not they are assigned as instruction operands.

Instructions are just one of many ways to influence tag values.

Regards,
George

I am using RSLOGIX5000 with FTviewSE.
The value of the source or destiny tags weren't manually changed, neither by manually changing it in the controller tags, nor via FTview.
The variable in question is a measure of current (A) of a VFD.

The source tag it is a "mirror" (dont know if this expression is correct) tag from the physical input tag with the value of an output current (A) calculated by the VFD.

The destiny tag is used on an add-on Instruction without any other calculation/computation after the MOV instruction. The Supervisory System uses the destiny tag so it can show the value of the VFD output current.

Geospark said:

then it is "possible" that the last save occurred mid execution before the destination tag was updated. It does happen.

Click to expand...

Maybe it is this.
But what about my suggestion of the PLC updating the value of the source tag (output current from the VFD) after the MOV but before taking the picture of the values in the end of scan? Can it also be true?
In this case the value of the source tag would be the last while the the destiny tag would still has the tag value got from the earlier source tag.
"END OF SCAN" would has the following order:

[Update Input tags-> Picture of the last scan tags with updated input tags]

Instead of:

[Picture of the last scan tags-> Update Input tags]

Revnus said:

...[Update Input tags-> Picture of the last scan tags with updated input tags]...

Click to expand...

Lesson 2: the scan of I/O is asynchronous to the scan of the program logic.

This means that the input tag will update its value each time the RPI (Requested Packet Interval) of the input source elapses, irrespective of where the program scan is at any given time. So yes, after the MOV instruction has executed, and before the end of the scan, for instance, the input value may have updated, but the scan has not returned yet to the MOV instruction to execute and update the destination tag (Not "destiny" - different word altogether!). A save could be performed during this brief interval. As I said, it does happen.

However...

Revnus said:

...The source tag it is a "mirror" (dont know if this expression is correct) tag from the physical input tag...

Click to expand...

This is known as a "mapped" tag or we would say "mapping" has been used. Another term often used is "buffer I/O". Essentially, you are taking a copy of the asynchronous input tag value so that a program may use it without it changing value before a program is finished referencing it.

In this case, the mapped source tag for the MOV instruction is not asynchronously changing. Its value is updated according to whatever other instruction is mapping the raw input value to it. This could be in the same program but could also be in a dedicated mapping program routine (it usually is). Now you are into the scan order of separate programs within a Logix 5000 project.

I'll leave it there for now - lunchtime...

G.

Geospark said:

Lesson 2: the scan of I/O is asynchronous to the scan of the program logic.

Click to expand...

Very interesting

Geospark said:

Not "destiny" - different word altogether!)

Click to expand...

Oops. In portuguese it is the same word for "destiny" and "destination", sorry.

Geospark said:

In this case, the mapped source tag for the MOV instruction is not asynchronously changing. Its value is updated according to whatever other instruction is mapping the raw input value to it.

Click to expand...

This is happening. The source tag is mapped previously from a physical input in a dedicated mapping program just as you said. This dedicated program executes first, before the program that has the routine where the MOV instruction is located.

At first, when I saw your last reply I thought that the crucial point was the asynchronous thing that was making the different values in the MOV, but after I read what you wrote about mapping, I dont think so. It just might be a save during mid execution as you suggested.

Thanks a lot for all answers till now. I learned a lot.