Number formats in PLCs

I'd like to find out what number/data formats are in use in a representative range of PLCs. I guess there's nowhere better to ask ???

We're reading values out of them across modbus. I want to know what possible formats I an expect to meet.

I don't know how much flexibility the PLCs give to the programmer when setting stuff up.... can you specify the number format for something, as you can in a C program, or are you terribly restricted?

I can conceive of meeting any of the following... anyone able to say "never" or "always" to each?

unsigned 16-bit integer
signed 16-bit integer 2's complement
signed 16-bit integer with 8000h as zero
unsigned 32-bit integer
signed 32-bit integer 2's complement
signed 32-bit integer with 80000000h as zero
unsigned 64-bit integer
signed 64-bit integer 2's complement
signed 64-bit integer with 8000000000000000h as zero
32-bit IEEE 754 floating point
64-bit IEEE 754 floating point
ASCII text

Thanks for any help you can give.

David

Hello dexdyne;

Here is a list of elementary data types available in the S7-300/400 family of Siemens PLCs:



Siemens also provides what they call complex data types, for specialized functions, such as Date_and_Time, String, etc...


Now here is a list for the Controllogix platform, from Rockwell:




On both PLCs you can build arrays and structures (called UDTs or UDDTs) based on these elementary data types.

Other manufacturers can have slightly different organisation of data, but most are now conforming to IEC61131-3, so differences are diminishing. Have a look at an intro on the following link:
http://plcopen.org/tc1.htm#IEC 61131-3 Programming Languages - providing the basis

Hope this helps,
Daniel Chartier

Most Modbus devices I have used have 16 and 32 bit integers, signed or unsigned, or 32 bit floating point. There is also 16 and 32 bit good old BCD still around by the way and the occassional signed version.

One of the difficulties with Modbus is big and little endian in devices. You finish up having to swap bytes and swap words quite often. I have only ever seen one device that had a choice of big or little endian built in and that is an Ozzie generator controller, though there may be others around.

BobB said:

One of the difficulties with Modbus is big and little endian in devices. You finish up having to swap bytes and swap words quite often.

Click to expand...

That happens when the implementers have a terminal case of stupidity. If the device doesn't work with a Modicon PLC without swapping then the device is wrong. How simple can that be? No swapping should be necessary.

BobB said:

I have only ever seen one device that had a choice of big or little endian built in and that is an Ozzie generator controller, though there may be others around.

Click to expand...

So the customers get it wrong 50% of the time.

This is a pet peeve of mine.

I do understand that different processors have different big or little endian formats but this shouldn't be a problem for the users.

Are any PLCs using 64 bit integers or 64 bit reals yet?

I do understand that different processors have different big or little endian formats but this shouldn't be a problem for the users.

Click to expand...

It would not be if there was a chaoice in the device. Different PLCs pull the info in differently unfortunately - rightly or wrongly.

Are any PLCs using 64 bit integers or 64 bit reals yet?

Click to expand...

Omron CJ1 and CS1 do. I am having a look at Control Logix shortly for a job - I think they do also but perhaps an AB guy could comment more accurately.

BobB said:

It would not be if there was a chaoice in the device. Different PLCs pull the info in differently unfortunately - rightly or wrongly.

Click to expand...

Our second generation controller used a fast 186 which is big endian. The Profibus DP protocol sends the MSB first so we had to switch the byte order in the motion controller to make it WORDs and DWORDs little endian like the 186 prefers. All manufacturers should do the same. The customer shouldn't care about the byte order.

Omron CJ1 and CS1 do. I am having a look at Control Logix shortly for a job - I think they do also but perhaps an AB guy could comment more accurately.

Click to expand...

I will need to stay on my toes and perhaps support a 64 bit real in our controller. There have been cases when it would be handy but most often it has been a case of poor technique.

If you add 0.001 to a number a 1000 times should you expect it to add up to 1.000? It does with a 64 bit float but not with a 32 bit float. This is because 0.001 cannot be represented accurately with only a 32 bit float. The correct way is to add 1 to a DINT and multiply the DINT by 0.001 after converting the DINT to a REAL usint DINT_TO_REAL. The problem is that many of our customer have not had numerical methods. Having 64 bit REALs would reduce the problem. 0.001 can't be represented accurately in a 64 bit real either but the errors don't show up as soon.

Customers don't like round off errors. They are spoiled by the 17 digit precision the PCs give them in Excel, Mathcad, Scilab, VBbasic, C, C# and C++.

BobB

I'm looking at an Endress+Hauser flowmeter which allows one to select one of 4 endiannesses.

Peter,

I pretty much agree with everything you've said. Numerical methods 101 is sadly missing. I had to have a discussion with a customer the other day about why asking me to put on a mimic a number coming from his PLC with 12 digits and 2 dec places was raising questions in my mind.

It's not really the "it don't add up straight" one that worries me, it'sd "my counter stopped counting accurately at 2million, now it has reached 16 million and the machine's still running but the counter has stopped completely" one.

Modbus as a communication protocol just passes 16 bits of data. It should not care what those 16 bits represent nor how they are structured. But it is true that the words in Modicon 984LL have an endian issue. Any manufacturer writing a driver that is Modicon 984LL compatible should address the endian problem so that their customer does not have to.

dexdyne said:

unsigned 16-bit integer
signed 16-bit integer 2's complement
signed 16-bit integer with 8000h as zero
unsigned 32-bit integer
signed 32-bit integer 2's complement
signed 32-bit integer with 80000000h as zero
unsigned 64-bit integer
signed 64-bit integer 2's complement
signed 64-bit integer with 8000000000000000h as zero
32-bit IEEE 754 floating point
64-bit IEEE 754 floating point
ASCII text

Click to expand...

I'll answer for the A-B processors.

unsigned 16-bit integer
signed 16-bit integer 2's complement
These two are effectively the same, the only difference is how you interpret bit 15. Both usages are common. A-B processors treat 16-bit integers as signed to the best of my knowledge. However, a Panelview can display the same data as signed or unsigned.

unsigned 32-bit integer
signed 32-bit integer 2's complement
Same as for 16 bit, they are effectively the same. I mostly see the signed version, since +/-2 billion covers most needs.

signed 16-bit integer with 8000h as zero
signed 32-bit integer with 80000000h as zero
Never seen these before.

64-bit integers
Haven't seen any for general use in a processor. Some internal functions may use a 64-bit integer.

32-bit IEEE 754 floating point
Common.

64-bit IEEE 754 floating point
Haven't seen one of these yet.

ASCII text
Common.

Mellis,

thanks ever so,

> signed 16-bit integer with 8000h as zero
> signed 32-bit integer with 80000000h as zero
> Never seen these before.

they come out of some AtoD chips I've met. I just put them in in the hope I'd get the "never never never repsonse so I could forget about them

> 64-bit integers
> Haven't seen any for general use in a processor.
> Some internal functions may use a 64-bit integer.

> 64-bit IEEE 754 floating point
> Haven't seen one of these yet.

It looks like the new Omrons can use these - which I assume means they can emit them on a modbus or similar.

I've got a customer who's threatening things like accumulating 16000 litres/hour for 15 years. The numbers involved either require them to think ( which they seem to find hard ) , or use a big representation like 64-bit. If they blunder off trying to do it with 32-bit FPT, there will be tears.

> ASCII text
> Common.

I'm beginning to work that out, and it's quite a lot of work to add it. Annoying

David

Daniel,

belated big thank you for your helpful post.

I think I've got to grips with this now, as far as individual values go.

I don't want to think about structures... mainly because if I am to avoid trouble, I'd need to fetch them across the modbus in a sinbgle transaction. That would involve telling my master s/w that a particular block of registers were monolithic, and I don't have a syntax for that yet.

Wroth adding to the list of features to be doen eventually.