Data Types and Country Customisation

R

Thread Starter

Ranjan Acharya

I would like the rich variety of data types (similar to those available to a
high-level programming language) such as: Boolean, single-precision floating
point (IEEE 754 32-bit), double-precision FP (64-bit), long FP (80-bit),
signed/unsigned 8-bit integer, s/u 16-bit i, s/u 32-bit i, s/u 64-bit i and
perhaps even consideration of a 128-bit integer. Many times I have had to
chain together two 16-bit signed integers in a PLC / controller with limited
data types to get a not-quite 32-bit integer. The floating point thing is
really important too -- all the way at least as far as 64-bit really helps.

Also on the subject of timers/counters, can we have them use at least 32-bit
unsigned integers so that we do not have to chain them together either.
Many PLCs are hampered by a +32767 limit on a timer preset (and a limited
selection of units too -- only milliseconds or seconds for example).

Customised data types e.g., date, time, complex (3+2j or 3+2i -- I cannot
imagine why, but why not) via some sort of structured programming (aka 1131)
would be useful too.

And let's have the language settings for all menus in a simple to change
text file so that we can easily have English (Standard), English (Canada),
English (US), German (Standard), German (Swiss), French (Standard), French
(Canada) and so on without much hassle. That way I can "Customise" or
"Customize" and "Colour" or "Color" to my heart's content. ALSO the package
should encourage the use of the ISO 860.1 date format (YYYY-MM-DD hh:mm:ss)
in all of its internal structures, revision dates and do on -- with external
format via international information so as not to confuse die-hard fans of
MM-DD-YYYY and DD-MM-YYYY. I think that the Unix date format is a little
clumsy. I guess that it will not have voice identification so we do not
have to worry about "Zed" or "Zee" for "Z".

RJ

< Stan wrote ... clip>
> Next we have integer data, normally 16 bit signed numbers.
>
>Then we have floats.
>
>Next there are 32 bit long integers.
>
>Then we have binary data. This data in general is treated as long arrays of bits.
>
>Then we have timer struts. These consist of a 16 bit word each for
>preset, and accumulated values, and 16 bits of status, eg timer timing, timer done.
>
> Counters are similar to timers, typical status bits include counter
> done, counter overflow etc.
>
> These are the most common types, there are others such as
> PID control
> files, but i think it's to early to talk about them.
>
> Can we get a consensus on these types?
>
</clip>
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ranjan Acharya

< From Stan>
> It has been my experience that the combination of 32 bit
> floats, and 32 bit longs is suffiecnt for 99% of real world apps.
</From Stan>

I have to disagree about the floating-point one (i.e., was that 99% or 98.9998%) -- I have had numerous instances where "somewhere in the pipe" -- either the controller, HMI or SCADA the loss of precision has resulted in a rounding error with only single-precision floats. It has often been "in the controller" where the problem occurred -- especially during even small
computational statements (this also brings up the issue of how the software handles floating-point mathematics internally via C libraries and so on that use the mathematics capability of the CPU to the fullest or those that do all the maths in just 32-bits with the resulting loss of accuracy). Since we are programming this for mostly Intel Pentiums and so on with built-in
derivative of the old X87 co-processor and 80-bit reals, I would hope that we would at least consider 64-bit double-precision floats (and full use of the 80-bit real for internal processing of logic containing ADDs, MULs, DIVs and so on).

I personally have not had to deal with any integers greater than signed 32-bit at the control level, but I would hate to limit us so early on.

Remember General Custer's last words: "After all, who needs more than 640KB of RAM anyway?"

Sorry for the delay in this post (it was written 2000-01-14 at 15:47). Our Internet portal is via cable and it is down more than up.

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
[email protected]



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ranjan Acharya

< From Stan>
> It has been my experience that the combination of 32 bit
> floats, and 32 bit longs is suffiecnt for 99% of real world apps.
</From Stan>

I have to disagree about the floating-point one (i.e., was that 99% or 98.9998%) -- I have had numerous instances where "somewhere in the pipe" -- either the controller, HMI or SCADA the loss of precision has resulted in a rounding error with only single-precision floats. It has often been "in the controller" where the problem occurred -- especially during even small
computational statements (this also brings up the issue of how the software handles floating-point mathematics internally via C libraries and so on that use the mathematics capability of the CPU to the fullest or those that do all the maths in just 32-bits with the resulting loss of accuracy). Since we are programming this for mostly Intel Pentiums and so on with built-in
derivative of the old X87 co-processor and 80-bit reals, I would hope that we would at least consider 64-bit double-precision floats (and full use of the 80-bit real for internal processing of logic containing ADDs, MULs, DIVs and so on).

I personally have not had to deal with any integers greater than signed 32-bit at the control level, but I would hate to limit us so early on.

Remember General Custer's last words: "After all, who needs more than 640KB of RAM anyway?"

Sorry for the delay in this post (it was written 2000-01-14 at 15:47). Our Internet portal is via cable and it is down more than up.

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 17 08:26:31 2000 Ranjan Acharya wrote...
>
>< From Stan>
>> It has been my experience that the combination of 32 bit
>> floats, and 32 bit longs is suffiecnt for 99% of real world apps.
></From Stan>
>
>I have to disagree about the floating-point one (i.e., was that 99% or
>98.9998%) -- I have had numerous instances where "somewhere in the pipe" --
>either the controller, HMI or SCADA the loss of precision has resulted in a
>rounding error with only single-precision floats. It has often been "in the
>controller" where the problem occurred -- especially during even small
>computational statements (this also brings up the issue of how the software
>handles floating-point mathematics internally via C libraries and so on that
>use the mathematics capability of the CPU to the fullest or those that do
>all the maths in just 32-bits with the resulting loss of accuracy). Since
>we are programming this for mostly Intel Pentiums and so on with built-in
>derivative of the old X87 co-processor and 80-bit reals, I would hope that
>we would at least consider 64-bit double-precision floats (and full use of
>the 80-bit real for internal processing of logic containing ADDs, MULs, DIVs
>and so on).

Speed, speed and more speed. The smaller data types should be abe to executed faster by the logic engines, and smaller for storage speed.

>I personally have not had to deal with any integers greater than signed
>32-bit at the control level, but I would hate to limit us so early on.

You are not limiting thes by declaring the maximum size of data types to be 32 bit ints. Cascadeing counters and timers is a standard PLC
technique.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top