Are wild MUL results a known bug, or is ML Emulate simply not to be trusted?
1 Attachment(s)
Windows 10, x86_64,
RSLogix Micro Starter Lite RSLogix Emulate 500 6.00.00.07 (CPR9) RSLinx Classic 2.57.00.14 CPR 9 SR 3 See the attached ZIP: the result of a MUL instruction on 16bit Sources 20077 and 20423 is 26176; it should be 26181; the should never be even. Thanks. 
If I do the roughly equivalent in a Domore simulator, I get your "desired" result if i use 16 bit signed integers for the math. If I use reals for the sources or include a 1.0* in the equation, I get your "incorrect" integer result.
I suspect this means Emulate is doing floating point math even when only integers are used. 
Doing the math on an ordinary calculator (Android tablet default) I get 410032571. I imagine it all depends on the final conversion of the intermediate result back to 16 bit integer. Since neither is correct it seems like the difference doesn't matter.

Quote:
I suspect the real, nonemulated MicroLogix hardware doesn't do this. Thanks. 
It matters very much
Quote:
For example, a Linear Congruential Generator depends on correct behavior here; I had to reimplement the LCG in LONGs to make it work, even though the effective modulus was 32768. 
Test case
I emulated Mike Nash's suggestion, that the bits are being lost in a floatingpoint multiply, here.:bonkhead:
The results are consistent with what I see when [RSLogix Emulate500] is running, so it looks like that is the issue. The test cases suggest that no more than five bits will be lost, plus the sign bit of course. Thanks, Mike! 
Yet another situation arises that "emulate" doesn't, if you get my meaning....
I personally would not trust any AB emulator to test anything important, nor give it any credibility to reproduce what a physical controller will do. 
This may sound strange but try it using all real numbers
I remember reading someplace a while back that you should never mix int and real numbers math functions in a plc It has to do with the they are handled in a plc it is different then in a computer or calculator 
Since I'm old enough to have learned Physics on a slide rule, and programming was strictly done with Integers a decade later... Then the 'Pentium Math Bug' hit the news to show that Floating Point / Real Number math had a basic flaw, I learned not to trust any Floating Point math without a 'Sanity Check'...
I still use Integers for 99% of my programming, and imply the decimal places with Tag Names like PSI_X100 :) 
Quote:
The problem appears to be that it is not the program, but it is the EMULATOR that is MOVing INTEGERs into REALs, doing the multiply in REALs, and MOVing the REAL product back the an INTEGER result, which MOVe drops any LSBits after the first 24 MSBits, when in fact the most important part of the result is the 15 LSBITs. The odd thing is that I cannot imagine that the emulator, whether written in C, Fortran, assembler or anything else, would have any trouble whatsoever multiplying two 16bit integers and getting the correct result, so this is a design decision, perhaps to keep the freelyavailable emulator from being of any commercial use. Hah, it would be funny, and not incredibly difficult, to go in and modify the binary emulator .EXE file to do it correctly. 
Quote:
The point of the original post is that the program WAS using INTEGERs in the multiplication, but the emulator apparently overrides that for 16bit INTEGERSs; with 32LONGs the results are correct. * and good to three sig figs, could I but find the dang cursor  "for want of a cursor the Least SigFig was lost ..." 
Here are a few places to check out
https://www.dummies.com/programming/...pointvalues/ http://www.differencebetween.net/sci...andintegers/ 
Quote:

I am mystified with the argumentation that multiplying 20077 and 20423 should result in 26181. Even if you argue that it is what the 16 LSB of the resulting long INT, that is never what should be the result of trying to squeze 410032571 into a 16bit INT.
Your Micrologix should trigger a math overflow. It is the only "correct" result in this situation. I bet that the emulator is only tested to provide correct results when the result falls within 32768 and 32767. As I see it, your task requires you to multiply INTs (16 bit), which will produce a long INT (32 bit). So why bother with 16bit INTs in the first place ? 
Stale phart thread
1 Attachment(s)
Mike Nash solved this issue in the first response, yet this thread hangs around like a stale phart; I apologize for bringing it up.
JesperMP: Go back to the original post of this thread: no matter what you mistakenly believe the 16bit INTEGER product of two odd 16bit INTEGERS might be, the correct answer should never be even. Quote:
Also, to look at it mathematically, although in decimal instead of hexadecimal or binary: Code:
20077 x 20423 = 410032571 Code:
410032571 / 65536 = 6256.6xxx Quote:
Quote:
Quote:
In the end I had to go to 32bit LONGs to get the correct 16bit result from the emulator, obviously, but the point of this thread is why the 16bit INTEGER MULtiply instruction gives the wrong answer in the emulator, while the MOVe instruction gives the correct answer. I have another case where I MULtiply a 32bit LONG by 1.1G in another LONG, and in that case I am still interested in the lower 31 bits regardless of any overflow condition. Should I have to go to 64bit LONGLONGs? Are those even available on a MicroLogix controller? Why does a LONG MULtiply with overflow work correctly when the equivalent INTEGER multiply does not? Since I only want the low 15 bits i.e. I want the result of Code:
[[20077 x 20423] MOD 32768] Code:
[[20077 x (32768  20423)] MOD 32768] Code:
[20077 x 20423] OR 32768 And every other CPU, that does 16bit operations, will give me the correct result. I'm still trying to get my hands on an actual 1100 to try this out; I suspect this is an emulatoronly issue, but if not, then what the heck is going on? 
All times are GMT 5. The time now is 05:16 AM. 
.