Followers 0

# extracting remainder and unrounded quotient

## 9 posts in this topic

Im trying to do a divide, and extract the remainder and unrounded quotient My S:13, and S:14 flags dont seem to be doing anything. Must be missing something stupid? TESTDIV.RSS

##### Share on other sites
I'll have to assume that you are online (I really mean that, I've thought there was a problem often while I was actually just offline) and that you are triggering B3:5/0. Try different numbers (other than zero) in N7:10 Edited by b_carlton

##### Share on other sites
I'm definatally online Icon is spinning, but yes been there before aswell I have 11 in N7:10 dividing by 3 rounded result (N7:6) = 4 ' makes sense as its being rounded S:13 (I would figure would be 2) is 0 my trap N7:7 is also 0 S:14 (I would figure would be 3) is 0 my trap N7:8 is also 0

##### Share on other sites
Ah - this from the Micrologix 1100 Instruction set manual - So put S:13 as the destination of the DIV and re-try. As a note, all the Micrologix instruction set manuals except for the 1000 mention this requirement. Edited by b_carlton

##### Share on other sites
Beauty! that's got it! Thank you sir

##### Share on other sites
When considering program scan, if I were to do this in rung 1, would the result be available in rung 2 of the same scan ?

##### Share on other sites
The results, in the math register S:13, S:14, would be correct until another instruction is executed which used it. Just being the next rung shouldn't affect it. It's possible that an interrupt with complex math might though.

##### Share on other sites
So with the exception of the interrupt scenario the entire 500 rung ladder would not need to be completely scanned before S:13 and 14 are updated, similar to how I/O is evaluated? hypothetically I could use S:13 and 14 in Rung 3 for another calculation. and then repeat all this again in rungs 100 with a completely different set of numbers?

##### Share on other sites
S:13 and S:14 will remain at the last values that were put into them, until another instruction is executed that changes them. Although to be on the safe side, I would MOV them to my own storage registers immediately, and not rely on them being changed. Future edits could undermine the philosophy that they remain unchanged. It would be an exceptional gaffe by A-B if the important things in the status file were not saved and restored at the commencement and end of an STI or DII interrupt. I've always believed them to be stored away safely, although I haven't seen any documentary evidence to that. I can also imagine there would be thousands of angry users if status data is not preserved during interrupt processing.