R
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
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