You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old January 6th, 2020, 10:56 AM   #16
JesperMP
Lifetime Supporting Member + Moderator
Denmark

JesperMP is offline
 
JesperMP's Avatar
 
Join Date: Feb 2003
Location: Copenhagen.
Posts: 14,213
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
Quote:
[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.
__________________
Jesper
See my profile interests for Q&A
  Reply With Quote
Old January 6th, 2020, 12:09 PM   #17
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
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.
  Reply With Quote
Old January 6th, 2020, 12:21 PM   #18
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Quote:
Originally Posted by JesperMP View Post
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.
  Reply With Quote
Old January 6th, 2020, 08:04 PM   #19
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Quote:
Originally Posted by drbitboy View Post
(I think the maximum possible is 31),
That was wrong, it can get to 32 bits.
  Reply With Quote
Old January 6th, 2020, 08:46 PM   #20
GaryS
Member
United States

GaryS is offline
 
GaryS's Avatar
 
Join Date: Aug 2003
Location: Lancaster Pa.
Posts: 1,300
32 bits is 0 - 31 count them
32 doesn't come in to it
  Reply With Quote
Old January 6th, 2020, 09:14 PM   #21
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Wink

Quote:
Originally Posted by GaryS View Post
32 bits is 0 - 31 count them
32 doesn't come in to it
yes, I know, I was referring how many significant bits can be in the final value, not the zero-based position of the MSBit.

After all, I am drbitboy .
  Reply With Quote
Old January 7th, 2020, 01:42 AM   #22
GaryS
Member
United States

GaryS is offline
 
GaryS's Avatar
 
Join Date: Aug 2003
Location: Lancaster Pa.
Posts: 1,300
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.
  Reply With Quote
Old January 7th, 2020, 09:01 AM   #23
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Wink The thread that would not die

Quote:
Originally Posted by GaryS View Post
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

Quote:
Originally Posted by GaryS View Post
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

  Reply With Quote
Old January 7th, 2020, 10:22 AM   #24
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Wink And the beat goes on

Quote:
Originally Posted by GaryS View Post
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


Last edited by drbitboy; January 7th, 2020 at 10:35 AM. Reason: add links
  Reply With Quote
Old January 13th, 2020, 06:57 AM   #25
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
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!



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.
  Reply With Quote
Old January 13th, 2020, 01:31 PM   #26
ndzied1
Lifetime Supporting Member
United States

ndzied1 is offline
 
ndzied1's Avatar
 
Join Date: Aug 2002
Location: Chicago, Illinois
Posts: 2,494
Just for the record, CoDeSys, in Simulation Mode, gives the answer you were expecting ;-)
Attached Images
File Type: png MUL_CoDeSys.PNG (122.0 KB, 60 views)
__________________
nOrM
======================
nOrM=Norman Dziedzic Jr.
I've never been to China but my phone has.
  Reply With Quote
Old January 13th, 2020, 02:51 PM   #27
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,036
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
  Reply With Quote
Old January 14th, 2020, 06:25 AM   #28
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Quote:
Originally Posted by ndzied1 View Post
Just for the record, CoDeSys, in Simulation Mode, gives the answer you were expecting ;-)
Thank you!
  Reply With Quote
Old January 14th, 2020, 06:30 AM   #29
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 804
Quote:
Originally Posted by kamenges View Post
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.
  Reply With Quote
Old January 14th, 2020, 11:40 AM   #30
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 4,036
Quote:
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
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
RSLogix Emulate 5 and RSLogix Emulate 500 on Windows 7 Ravioli LIVE PLC Questions And Answers 4 September 29th, 2016 07:23 AM


All times are GMT -4. The time now is 04:24 AM.


.