Are wild MUL results a known bug, or is ML Emulate simply not to be trusted?

I dont know what you want to achieve by evaluating only the 15 LSB in a long int after a multiply of 16-bit ints. The resulting 15 bits will roll over whenever the value cannot be represented within 0-32767. In any application I can imagine, the correct response would be that something is wrong and halt whatever is being attempted. I guess my imagination is too narrow.

Apart from the above, you are correct in everything that you write.

What you are doing by evaluating the 15 LSB etc. etc. may work the way you expect in that particular CPU, but Rockwell cannot guarantee that it will work on other CPUs, including the emulator.
It says in the RSLogix 500 reference manual that
[S:0/1] sets if overflow is detected at destination; otherwise resets. On
overflow, the minor error flag is also set. The value -32,768 or
32,767 is placed in the destination. Exception: If you are using
an SLC 5/02 or higher processor
and have S:2/14 (math overflow
selection bit) set, then the unsigned, truncated least significant
16-bits of the result remains in the destination. For floating
point destinat
I dont think that "SLC 5/02 or higher" includes the emulator running on a PC.

I am pretty sure that the emulator merely passes the arguments to the CPU (in this case an intel x86) which then returns the result. You might be right that it returns a "wrong value", but it would be the intel CPU, not the emulator that is in the wrong.

re "stale phart".
You wrote yourself "My only purpose in opening this thread was curiosity". My response was because of the same curiosity. When arguing back and forth we may learn something. I shall not post in your threads again.
 
The help file for [RSLogix Micro Starter Lite] makes the identical claim for MicroLogix i.e. if the [Math Overflow Selected] (S:2/14) bit is set, then any overflow will result in the truncated result being placed. Yes, I understand and agree that the emulator may not make a similar claim; but I still had a need for those 15 bits, and with the help of others I did eventually get them, from the emulator; I have also been looking into buying an 1100.

The context of all of this is a Random Number Generator, specifically a Linear Congruential Generator (cf. here); such a beast relies on getting a correct truncated result of any MULtiplicative overflows. To be sure, that "need" was obscure, for an exercise, and not for a real-world, physical application. But ultimately it had purpose - for me and those I am working with.

Re: stale phart
You seem to have taken offense: did you think I was referring to you? If so, then I apologize for not being more clear, and I can also assure you I was not referring to you; I was referring to the thread itself! Specifically, that it - the thread - seems to "hang around like a stale ..." and attract more attention than it was worth, seeing that the issue was resolved in the first half-dozen posts.

Also, and seriously, whether you respond to my posts in future or not, I apologize for the general tone of snark.

Best regards.
 
I am pretty sure that the emulator merely passes the arguments to the CPU (in this case an intel x86) which then returns the result. You might be right that it returns a "wrong value", but it would be the intel CPU, not the emulator that is in the wrong.

Actually, as Mike Nash suggested, it does probably pass the 16-bit INTEGER arguments to be multiplied, but
  • it passes them as 32-bit REALs,
  • the 32-bit REAL product result only keeps at most the upper 24 bits of precision,
  • so if the integer result would 25 or more significant bits (I think the maximum possible is 31),
  • then some bits at the lower end are lost
  • and if any of those lost bits are non-zero, then the final result MOVed into a 16-bit INTEGER will be "wrong"

So the error comes from passing the 16-bit INTEGER multiplicand and multiplier as REALs instead of LONGs; surely that is a mistake in the design of the emulator, not the CPU.
 
I think the reason there is some confusion on this is not the math or the numbers but he way integers are represented in binary. PLC’s use binary to represent integers 4 bit, 8 bit, 16 bit, 32 bit and 64 bit and I assume we lwill soon see 128 bit integers when the next generation processors come out.
As a side note I read a while back that Intel already has a 128 bit processor. It’s only a matter of time before it’s available for general use.
In your case you are multiplying a pos and neg integer numbers and placing the result in an integer.
If you multiply a positive number by a negative number the result will always be a negative number.
In a plc all integers are represented by two’s complement number.
In a integer the MSBit is the sign bit, but you just strip away the sign bit and use the remaining 15 bit integer will not be the same bit pattern as it would be as positive number (two’s Complement) but the PLC will display the integer value of the remaining 15 bit binary word
Here is another link that may explain it better.
https://en.wikipedia.org/wiki/Two's_complement

Two’s complement numbers have been the standard in PLC’s for many years long before the newer PLC’s came out with floating point numbers. The reason they are still available is backwards compatibility.

You would do better to use ABS (absolute value) of your result as your final result. It converts a negative to the correct positive number and the bit patterns would be the same

Real numbers and Float numbers don’t convert directly to integers. In fact to copy (Not Move) a float to an integer requires the result to be placed in 2 consecutive integers one for the whole number part and one for the decimal number. An array of at least 2 integers is required.
This why you should never mix real / float numbers and integers in a plc the conversions don’t work.
In a computer the numbers are converted to a notation number before a calculation and then converted back for the result but they are not dealing with binary bits, Just the values.
With any math function or conversion the result always truncates the least significant numbers off to fit the data type similar to a slide rule. It’s been a while but if memory serves a slide rule is only accurate to 3 significant numbers. And that was good enough to put a man in space.
 
The thread that would not die

I think the reason there is some confusion [...]

I can assure you that I am not in the least bit;) confused, as I have lived down in the weeds (bits) of integers and reals of multitudinous* complexions, denominations, persuasions and stripes for some decades now; I know the difference between MOVe and COPy; I am merely uninterested in the sign bit for my obscure application**; as that bit has no effect on my results when twos-complement integer operations are performed "normally" by the "hardware," I can conveniently ignore it. I do not believe JesperMP was confused about integers either, as he clearly saw that 26181 resides in the low bits of the sample INTEGER product; his only concern, and a kind concern at that, now that I ponder it, was the reason for its significance to me (I get that a lot;)).

* IBM; VAX/VMS F_floating and G_floating; IEEE 754

** the guts of which are encapsulated in this line of code

If you multiply a positive number by a negative number the result will always be a negative number. [...]

Well, not quite always; see the MUL instruction in the image below.

However, if you multiply an odd twos-complement integer by another odd twos-complement integers, the correct result should always be odd. The initial impetus for this thread was to understand why that was not true in the least bit;) for some cases when using the [RSLogix Emulate500] app; that has been solved.

The sum of the matter:
  • Look down at your ankle
  • Do you see that hand pulling your leg?
  • That's me;););););)

posnegpos.png
 
And the beat goes on

In fact to copy (Not Move) a float to an integer requires the result to be placed in 2 consecutive integers one for the whole number part and one for the decimal number.

Okay, I had some fun with you in the previous post, but the bold italics bit above is flat-out wrong; so I am highlighting that for any poor soul who stumbles onto this thread in the future.

In the image below, I have copied (via the CPW command; COP does not work on MicroLogix) the bits of two 16-bit INTEGERs, 16512 and -32768 (F080H and 8000H) to a REAL, and the resulting REAL is 4.015625. It should be obvious that neither 16512 nor -32768 are either of 4 (the whole number) or 0.015625 (the decimal number), although together, but in a more complex way, the bits in those two INTEGERs do make up the bits in the REAL. Cf. here, specifically this

CPW_INTEGERtoREAL.png
 
Last edited:
Holy cow!

Hahaha, I cannot believe this: the same thing happens in [RSLogix Emulate500] with 32-long LONGs i.e. I lose the low-order bits in some cases when a 32-bit MULtiply overflows!

emulator_overflow_error_32-bit-long.png


It still works correctly if I start with two 16-bit INTEGERs MOVed into the LONGs before the MULtiply, because there is no overflow in that case.

I would guess they put the LONGs into 64-bit double-precision floats. I can think of two reasons for this design choice in the emulator:
  1. They use the floating point result in the emulator to detect overflow.
  2. If the emulator is accurate it may affect MicroLogix sales.
To me, neither reason seems customer-focused.
 
I'm surprised the emulator did even as well as it did. It'e been a long time since I've had to work with these, but as I recall the "classic architecture" AB products (the PLC5 and the SLC family without the overflow bit set) had the alarming quality of limiting ANY integer operation to +32767 to -32768. Since the MicroLogix is based on the SLC architecture (at least as far as I was told) I would have expected the result of the MUL in your initial post to be -32768.

It wasn't until the ControlLogix architecture came along that the AB stuff started handling rollover like one would expect.

Keith
 
I'm surprised the emulator did even as well as it did. It'e been a long time since I've had to work with these, but as I recall the "classic architecture" AB products (the PLC5 and the SLC family without the overflow bit set) had the alarming quality of limiting ANY integer operation to +32767 to -32768. Since the MicroLogix is based on the SLC architecture (at least as far as I was told) I would have expected the result of the MUL in your initial post to be -32768.

It wasn't until the ControlLogix architecture came along that the AB stuff started handling rollover like one would expect.

Keith

The result is -32768 unless the [Math Overflow Selected] status bit (S:2/14?) is latched; see the first-pass rung of the example.

Wait, are you saying even the MicroLogix hardware exhibits this behavior, even with the [Math Overflow Selected] bit set? I have been trying to buy one on the cheap on eBay to experiment to test. Wow, that would be something.
 
Originally posted by drbitboy:

Wait, are you saying even the MicroLogix hardware exhibits this behavior, even with the [Math Overflow Selected] bit set?

No, the MicroLogix should work correctly as long as the overflow select bit is set. It should operate like a SLC in that regard.

Keith
 

Similar Topics

Replies
14
Views
3,344
HI All, I am trying to do some repeat logic on and existing code SLC504. The code is the same just the addresses are different, I have created...
Replies
11
Views
3,327
I am using a ML1400 to count the RPM of several items. They all use the same math to determine the RPM after 10 counts of the counter. The one...
Replies
8
Views
3,256
Hi there every one, I'm working in a PL7 program, (TSX 573623) the existing timer (FTON or %Tm) are working good. The problem is : when I add a...
Replies
2
Views
1,730
http://arstechnica.com/security/news/2010/09/stuxnet-worm-attacks-industrial-targets-could-be-aimed-at-iran.ars Great, all I need is to start...
Replies
2
Views
3,046
Back
Top Bottom