Colin Carpenter

Signed or unsigned?

10 posts in this topic

No matter how long I'm in this game, I keep realising that I don't know things that I thought I knew.

I was called in yesterday to see if I could change some existing software.

A change in production had meant that a setpoint now needed to be entered with a positive value that was above the normal +32,767 that I normally use as the maximum that I will allow an operator to put in.

I know that I could have used double integers to overcome that problem, but in this case it would have caused addressing problems as all changes would have been online, and I eventually sorted out an easy fix with other scaling factors, but it made me realise that I'd never stopped to think about the D registers in a Q series PLC.

I noticed from the HMI that I could select a "signed 16 bit" or an "unsigned 16 bit" type for the D register, and I know that an unsigned number can be 0 to 65,535 and that a signed number can be -32,768 to + 32,767, so I considered selecting the "unsigned 16 bit" option so that I could enter a value greater than +32,767.

But then I stopped to think about how the PLC would handle that number when it arrived, in other words, would it always view a number greater than 32,767 as being a negative number, or is there a way of telling the PLC that this particular D register is holding an unsigned integer, and therefore that the 16th bit doesn't signify positive or negative?

I'm pretty sure they will always be "signed integers", but wonder if anyone has ever proven this wrong?

 

Share this post


Link to post
Share on other sites

All in all the PLC only handles bits (zero or one). Anything else is more or less a representation of the bits put in some kind of order. Further, a signed word is only a human representation of the last bit (b15) in a single word. So in essence, the PLC actually work with bits (and then further unsigned bits).

Instructions like ADD/SUB and so on assumes that b15 is a sign bit and works accordingly. Instructions like SHL/SHR (bitshift instructions) needs unsigned words.

So to summarize; signed and unsigned is more of the human representation of a bit pattern. PLCs work with bits, however instructions may work according to signed or unsigned "rules".

And as a last note: You can also add or subtract an unsigned word, you will simply start at 0 after going over the "top" 65,535.

Share this post


Link to post
Share on other sites

I've always seen it that way too. You can do a block compare on a bunch of registers and it makes no difference to the PLC if they are signed, unsigned, float whatever, all the PLC sees is a bit pattern.

Whether the sign bit is 1 or 0 only affects how the bit pattern is interpreted by certain instructions and devices such as HMIs.

This must be interpreted by ADD instructions too because you can ADD a "negative" value to another int with the net result being a subtraction. I suppose if you SUB 65,535 from k0 you just go back to 0.

Share this post


Link to post
Share on other sites

overflow.thumb.jpg.dd69df7c22198e46659b5

It definitely handles arithmetic operations as signed. Interestingly, it won`t even let you input a K larger than 32,767 into a single word instruction. Idiot proof but not programmer proof :)

Share this post


Link to post
Share on other sites
Just now, Luke.S said:

It definitely handles arithmetic operations as signed. Interestingly, it won`t even let you input a K larger than 32,767 into a single word instruction. Idiot proof but not programmer proof :)

No, it does not. The reason you cannot enter more than 32,767 is simply because of the software and not because of the PLC itself. As said: Signed/unsigned is simply the human representation of a bit pattern.

The PLC handles everything as bits, futher any operation is performed bitwise, hence 32,767 (2#0111111111111111) ADD 10#01 equals -32,767 (signed) OR 32,768 (unsigned) and the bitpattern for these two are the same: 2#1000000000000000. So again; the bitpattern is exactly the same, the only thing that "changes" is how you look at the number with human eyes through the software itself.

That is exactly why it is not interesting to monitor a PLC programs "signed" or "unsigned" devices in the monitoring software since the format is not "selectable". However in a HMI it is critical so that the representation of the bitpattern is as expected.

Share this post


Link to post
Share on other sites
5 hours ago, kaare_t said:

No, it does not. The reason you cannot enter more than 32,767 is simply because of the software and not because of the PLC itself. As said: Signed/unsigned is simply the human representation of a bit pattern.

The PLC handles everything as bits, futher any operation is performed bitwise, hence 32,767 (2#0111111111111111) ADD 10#01 equals -32,767 (signed) OR 32,768 (unsigned) and the bitpattern for these two are the same: 2#1000000000000000. So again; the bitpattern is exactly the same, the only thing that "changes" is how you look at the number with human eyes through the software itself.

That is exactly why it is not interesting to monitor a PLC programs "signed" or "unsigned" devices in the monitoring software since the format is not "selectable". However in a HMI it is critical so that the representation of the bitpattern is as expected.

I agree with what you're saying, and I would imagine it could lead to some confusion to the uninitiated if the HMI was set up to display "unsigned 16 bit", so it would be showing 32,768 while the PLC would be working on a value of -32,767.

I just wondered if there was some obscure command in the software that could be used to tell an individual D register that it should behave as an unsigned D register, but I guess that is the reason for double integers at the end of the day.

I did come across a similar issue once with some software that someone else had written when a Q PLC was reading a 4-20 ma signal into an analogue input that was set up for 4-20mA = 0-12,000 bits, meaning that when the sensor was hovering around the 4mA mark, occasionally the PLC would read a negative value as the sensor dipped slightly below 4 mA.

The SCADA system was set up to read in an "unsigned 16 bit value", so instead of showing a slightly negative value, it would immediately jump from "close to zero" to a very large figure .... which led to an interesting graph!!

Changing the tag to a "signed 16 bit value" cured the problem.

 

Share this post


Link to post
Share on other sites

What kaare_t says is spot on. No matter which you are dealing with, the programmer is responsible for staying within the bounds. If you going to stay within the bounds of an Unsigned Integer then the math in the PLC will be the same whether it is an Unsigned Add or Signed Add. No Two's Complement math will be performed if no negative numbers are present. After all, 1 + 32767 does not equal -32768 but this is what the PLC will show you. We've just busted the bank. The PLC is doing exactly what is should, H0001 + H7FFF = H8000.

I don't find this confusing all. I would find it more confusing to think that the PLC will behave differently if we simply called it something different. It would be easier to understand if GX Works allowed you to view it in it's unsigned format. Omron was like that a long time ago. We used to view most in Hex. Now Omron allows Signed, Unsigned and Hex.

 

 

 

Share this post


Link to post
Share on other sites

Yes in the purest sense when the bits go to the adder transistor circuit on the chip it will change the requisite bits in the bit pattern accordingly. But on the PLC  programming level to pass what the user interprets as an "unsigned int" to a program with single word commands could cause chaos.

It's really interesting to think about this because (obviously I hope) you always program to make sure overflows can never happen. I didn't know that the programming tool displays the value of the register depending on what instruction it is being used with. Of course with the HMI you tell it how to display the contents of the register.

Share this post


Link to post
Share on other sites

I can see that this discussion might lead to some confusion in several aspects, so to try to enlighten it a bit more, a possibly better example is floats (REAL in Mitsu PLC's).

A float number (IEEE754) consists of a predefined bitpattern (I'm using single precision - 32bit - since most PLC's use this), where you have the sign bit, exponent pattern and mantissa pattern. The PLC uses it's special instructions for handling these numbers since the bit pattern is different than regular words. In my example we simply don't care if we add, subtract or use any other command on the value of the register(s), so this doesn't matter.

Now, there are two ways of representing an IEEE754. We have the decimal representation and the scientific representation. For most of us, the decimal representation is the easiest to use, and if we use the number 100.0 this pretty much explains what we are looking at. However there's also the scientific representation of the exact same number which is 1x102. Or in a Mitsu PLC it would most likely look something like: 10.0e+1 (or something similar). Some HMI's can define to present the number as decimal or scientific.

The bitpattern for both numbers is: 2#01000010110010000000000000000000
The hex value for both numbers is: 16#42C80000

So for an IEEE754 there's more than one way to present the bitpattern, the same goes for words.

Share this post


Link to post
Share on other sites

I don't know if it's still of interest to the OP or anyone else but I was looking up an instruction in the FX5U programming manual today and noticed that instructions now do have an unsigned version. It even has a nice explanation of overflows as was described above. I suppose it's the same on the iQ-R too to bring it inline with other vendors.

As far as I'm aware it is not possible to specify unsigned on the Q or FX3 series. I was just surprised by the way the tool dictated the programmer's use of the register by not allowing integer representations over 32,767. Surely that's our call!?

570e353a64e05__U.thumb.jpg.341940f5227ad

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now