PLC5 Average

[Falcons75 0]

I've written a few lines of code to average (using the AVE operand) 10 values which are loaded every 30 seconds. I'm uses indexing but in the help file it says I need to be careful when using indexing. My question is what do I need to be careful of and how do I avoid it being an issue? I've attached a pdf of the code if it helps. Cheers. Weight Index.pdf

[JRoss 84]

Gotcha #1: If you use indexing to access a non-existent data value, you will fault the processor. For example, if N200 is size 200 (N200:0 through N200:199), then a value of 200 or higher in N200:100 (your index value), will try to access a variable that does not exist. It looks like you've got this handled properly. Gotcha #2: You run the risk of overwriting data without being aware of it. For example, your array of data is in N200:0 through N200:9. If you let the pointer get index value get higher than 9, you are now reading/writing an existing area that you may be using for something else. This won't fault the processor as long as you stay within the range of exisiting variables, but it could give you strange behavior. Say, for instance, you have a conveyor speed somewhere in that range! Again, it looks like you've got this covered.

[Guest]

first of all, make sure that you understand the differences between: INDIRECT addressing – which uses the [ ] "square brackets" characters ... and ... INDEXED addressing – which uses the # "pound sign" character ... I'm reading between the lines here, but from your question it seems that the "book warning" that you're concerned about is related to the INDEXED (#) addressing method ... first of all ... the reason for the book's warning is that all addresses which use INDEXED (#) addressing are all required to make use of the single memory location S:24 – the "Index Register" - to act as an "offset" to reference the various data locations ... note that in your AVE instruction, the R6:1 "Control" causes the processor to automatically increment the S:24 "offset" value ... this is an example of the INDEXED (#) addressing method ... you probably will NOT be able to see this value change on the screen – since it increments much too fast – but it DOES increment whenever the AVE is executed with TRUE logic ... on the other hand ... with the INDIRECT ([ ]) addressing method you (the programmer) assign your own "home brew" address to act as a "pointer" to reference the various data locations ... note that you're using an ADD instruction to increment the value stored in the N200:100 "pointer" location ... this is an example of the INDIRECT ([ ]) addressing method ... something to think about ... the INDEXED (#) addressing scheme is older – and was "the only game in town" before the more-flexible INDIRECT ([ ]) scheme became available ... in simplest terms, unless you yourself – or your programming code – are changing the value stored in S:24, then you're probably NOT going to have any problem using the INDEXED (#) addressing method ... suggestion: read the book's warning again, and this time make a distinction between the INDIRECT ([ ]) addressing method – and the INDEXED (#) addressing method ... and yes, I fully agree – it's quite confusing that Allen-Bradley named TWO different addressing methods using the same first three letters (IND) for both methods ... (and – just curious – but why do you have a ZERO entered for the "Length" setting in your AVE instruction?) ... Edited 18 Jun 2014 by Ron Beaufort

[Falcons75 0]

Thanks for the responses. The AVE should be length of 10 instead of 0! (thanks Ron) One error I've just spotted is that the AVE is looking at an indexed integer (I'm learning ) starting at N200:1, yet I reset the actual integer to N200:0 (Indirectly) with the MOV operand. Whoops.

[daba 4]

If you think that's confusing, Ron, have a look at the addressing methods available for the 6502 microprocessor !!