Sign in to follow this  
Followers 0
CanaanP

Indirect Address Problem on ML1200

6 posts in this topic

Hey I'm trying to use indirect addressing in an EQU in my program and it's acting strangely. The number in the integer file that I'm referencing is not showing up as the same number in the source of my EQU statement in the rung. Is there a reason for this that I'm not aware of? I took two screen shots so you could see that it's not different by the same number each time, like it was being offset or something, it is different for each number. In my program N7:101 starts at 10 and increases by 1 each time a timer is done, stoping at 19. However, 11 in N7:101 shows up as 7 in Source A of my EQU. You can see from the screen shots what some of the other values show... but there does not seem to be a pattern. I thought perhaps I could fix this with indexed address, using the S:24, but this processor does not support it. I should mention I have this very same setup in another subroutine that is incrementing N7:100 in the same way with a timer, except it starts at 0 and stops and 9 and that is working perfectly, the numbers go to the Source A of the EQU statements in that subroutine without any errors. So what gives? If this is something I'm going to have to work around, any ideas on how that could be done? Edited by CanaanP

Share this post


Link to post
Share on other sites
You need a screenshot that shows N7:10 through N7:20... You might use a custom data monitor to put those and N7:101 all on the screen at once.

Share this post


Link to post
Share on other sites
In your the first screen shot, it appears the value of N7:101 is 13, so the EQU instruction is looking at N7:[N7:101] since N7:101= 13, you are comparing the value in N7:13, which appears to have a value of 8. Same thing is true for the other screen shot as well. Except N7:101=19, So you are comparing N7:19 which equals 9 to 11.

Share this post


Link to post
Share on other sites
never mind, I figured it out - I'm retarded... it was showing those values because I had put them in there, and had a mistake elsewhere... jeez I feel stupid.

Share this post


Link to post
Share on other sites
CannanP - One other word of caution about Indirect Addressing. It is always advisable to limit check your "pointer" before scanning the instruction that uses it.

Share this post


Link to post
Share on other sites
I would have to ask why you are using indirect addressing with so few indexes. It seems plugging in 10 rungs would not be all that cubersome and would eliminate pain and suffereing now and in the future. I look at index addressing as something that should be used rarely. My number 2 concern in programming is how easy is it going to be for my client to follow what I have done (number 1 being that it works correctly). If you had something that really needed to churn through some registers or possibly you have some complex logic on the ouput side of the rungs you have shown us, then it makes sense. Also I would be even more wary programming with indirects on a processor that doesnt allow online programming changes. If the logic does get hairy (technical term) and you have to troubleshoot a problem, you will want the flexibility to be able to add a little code to see what is going on. Russell

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0