5/03 number will not move to N file

the move instruction will not move the assigned number to the N file.
I can put the number in the file and it works. If I make the rung go true the move instrution doesn't move the number.

Suggestions.

wish i had more information. I work on first shift and was given the information by second shift. i did not have the time to look for myself. They told me that my addressing was correct and that everything should of worked fine. Please help.

if your using an slc 503 OS301 or higher you need to place # in front of the destination address

if your using an slc 503 OS301 or higher you need to place # in front of the destination address

Click to expand...

Not in the 5/03's I have worked with. The # is used for certain addressing techniques, such as indexed addressing and is required by some instructions as in the SQO. The MOV does not require the # sign in any AB processor that I am familiar with.


Now, you are getting second hand information and have not seen what is going on for yourself. There are lots of reasons the data is not getting moved to the N register you are using but most often the culprit is the fact that the data is being moved, just written over or cleared so fast that you, or someone is not seeing what is actually happening. The processor speed is much faster than the rate at which the communications link to the programming terminal. You will have to investigate this for yourself and not take the word of the others, unless you have to. I can assure you that the operation is taking place but it may seem as if it is not. Check all the lines of the program that write to the same register, or control the rung that writes to it. This problem hits most of us sooner or later and it can be very difficult to isolate. One method of proving that the MOV is taking place is to change the destination address and have it write to another register. Patience is required here to find this little bug.

What ladder file did you put the rung in. If it is not ladder 2,
then make sure the subroutine is being called. You probably alreadly
know this but its easy to overlook.

Troubleshooting tip:
on the same rung as the move instruction, add a branced output right underneath the MOV and then fire a bit, then see if the bit is being energized. If it is the the move instruction is being completed, and some other instruction is overwritting your register.

Ken Moore said:

Troubleshooting tip:
on the same rung as the move instruction, add a branced output right underneath the MOV and then fire a bit, then see if the bit is being energized. If it is the the move instruction is being completed, and some other instruction is overwritting your register.

Click to expand...

And, if B3:0/1 is brief, like for one scan only, create B3:0/0 as a latch and reset it via the data table monitor before testing. This will capture the condition which activates the MOV.

Not in the 5/03's I have worked with. The # is used for certain addressing techniques, such as indexed addressing and is required by some instructions as in the SQO. The MOV does not require the # sign in any AB processor that I am familiar with.


That was a direct qoute from the SLC instruction set.

I have experienced this problem in the past; If the conditional logic triggering the MOV is momentary, it is a scan issue as suggested in an earlier post. Place an OSR instruction between the conditional logic and the MOV and it should start working.

MOV instruction

Troubleshooting tip:

Click to expand...

Good tip, Ken and Right on Doug. It is often a good idea to make the condition that makes your rung "true" a oneshot for these kind of instructions. If the problem is as one suggestion mentioned that the value is being overwritten by another MOV instruction, then oneshots are definitely your friends.

Mickey mentioned that omitting the "JSR" instruction in LAD2 is a basic but easily overlooked cause of instructions not executing in other files. Every now and then, I still forget this, or I have a list of them at the end of my LAD2 file, and have one of them with the wrong number in it. I hear all the laughter out there, but I know I'm not the only one. (It's the same part of the brain that malfunctions when I send e-mails and forget to attach attachments).

The built in SLC instruction help is actually more helpful than I originally expected. It has become my friend, too, as I have been a "freind in need".

That was a direct qoute from the SLC instruction set.

Click to expand...

The quote is saying that you must use a # in front of an N if you're using the integer word as a FILE address, which is different than an ELEMENT address.

Feedback?

Greg,

Please let us know what the bug was, assuming you found it. If not, let us know what you have already tried.

CB

Enter the following parameters when programming this instruction:
• Source is the program constant or element address. The file
indicator (#) is not required for an element address. When using
either an SLC 5/03 (OS301 or higher), SLC 5/04 (OS401), or SLC
5/05 processor, floating point and string values are supported.
• Destination is the destination starting address of the file you
want to fill. You must use the file indicator (#) in the address.
When using either an SLC 5/03 (OS301 or higher), SLC 5/04
(OS401), or SLC 5/05 processor, floating point and string values
are supported.


Rube your correct on the source address Is that also the correct interpretation on the destination?

Detectives.....

mordred:

The text you posted is from the Help file on the FLL instruction. I thought that the discussion was about MOV.

The '#' symbol in any instruction means that the address is indexed. That is, the value in S:24 will determine how many registers offset from the base address will be used when the PLC gets/puts the data in the register.

Some instructions, such as COP, FLL, SQO, FAL, DDT (i.e., any instruction that requires you to enter a "Length"), co-opt S:24 for their own internal bookkeeping. The instructions initialize S:24 to zero (or R6:xx.POS, if used) and perform its task. Without advancing in the scan, it then increments S:24, checks to see if it exceeds the length (or R6:xx.LEN), and does it's function again, and repeats until the length is reached.

Therefore, the instruction FLL #N7:0 #N10:0 10 is functionally equivalent to COP #N7:0 #N10:0 10. The value in N7:0 will go into N10:0, N7:1 to N10:1, and so on up to N7:9 going into N10:9.

On the other hand FLL N7:0 #N10:0 10 (without the '#' in the source) will populate all of N10:0 through N10:9 with the same value (N7:0). This is its intended function.

Now, you CAN do something like MOV #N7:0 #N10:0 (with #'s in front of either/both of the Source and/or Destination), but what happens is that you may not have control over S:24. If it still had a value of 10 (from when the above FLL instruction left it), then you would be getting a move, not of N7:0 into N10:0, but of N7:9 into N10:9.

If Greg Webb has the #, that could be why his "move instrution (sic)doesn't move the number."

---

Note that he said:

I can put the number in the file and it works.
If I make the rung go true the move instrution doesn't move the number.

Click to expand...

If he can put the number in, then nothing is overwrtting the MOV.
That means that either the thread's tangent accidentally but accurately diagnosed the problem (rogue '#' symbol), or the logic isn't being scanned (most probable).

There are four ways that logic isn't scanned:

1. No JSR to the subroutine that the logic is in (discussed)
2. MOV logic is between a JMP and a LBL, and the JMP instruction is true;
3. MOV logic is between two MCRs, and the logic on the first MCR is false;
4. The PLC is in program mode (on second shift, you never know).

Actually Allen that was copied from the writup under the Mov instruction. I also recongnize that it won't solve the problem at hand. I was merely asking if my interpretation of that statement is wrong or not. From what I gather it probably was incorrect. Also the source of the text was the SLC instruction set pdf.

I was tempted to jump into this thread until I noticed that mr. Webb hasnt responded to any of the posts that has suggestions for him to check out. And it is 4 days since he posted.

You guys are too nice.