Host Engineering Forum
General Category => DirectSOFT => Topic started by: MikeS on November 19, 2009, 10:59:04 AM
-
We're having an ongoing internal discussion about the relative value of numbering PLC elements in Decimal vs numbering them in Octal. Each has it merits, and each has issues. Tell us what you think, and why.
And as always, there will be a prize for the best answer - as determined by our panel of highly skilled and dedicated developers (if they are too busy them zimboo our trained code monkey will randomly pick one).
-
Decimal numbering is better than octal, beating it by 2. (That's 10 to you, Mark)
-
Octal, Hex, BCD, and Binary are for low level development.
Like I told Greg the other day, Here I am working on a project with incredible computing power and memory, and I am converting numbers on a $1 calculator... nuff said!
-
Until computer busses are in decimal (how I don't know) natural divisions in areas and usage will tend to fall on boundaries dictated by the binary nature of the addressing lines. As long as you stay well away from limits it's probably not much of a problem. If the areas are denoted by a name and a decimal number then people don't have to work out the absolute addresses.
But this is not a question for the end processor but for the development system. Computing power being what it is it would be trivial for the development system to provide a hex/binary mode and a decimal mode for address entry.
The problem comes when a CPU has to respond to inquiries from third party development and HMI's. What number system will accept inquiries in. Look at the addressing mess when attempting to read data from the DL line using MODBUS.
I'm stuck in hexadecimal mode from my microprocessor days. The octal of the classic DL systems are no problem at all.
-
These are always fun discussions. Some understand, many don't, and hardware is an unfathomable black box to most.
In any computing platform, there is variable encoding and there is variable rendering. For DL PLCs, there are 3 primary encoding formats: 2s complement integer (aka 'binary'), floating point, and BCD. Within the binary encoding, there are many possible renderings...decimal, octal, binary, and hex. The decision to render I/O references in octal in no way affects the encoding, but was chosen to simplify slot addressing. The mention that octal is useful for low-level development is exactly correct and precisely why octal was chosen for I/O numbering.
Is octal best? That's highly subjective, but in fact is the whole reason for this poll.
I'm still reluctant to go into detail, but I will say that those of you who like decimal I/O will like where we are going. The new PLC that Host is developing uses decimal numbering everywhere it makes sense, and only uses octal where absolutely necessary: in memory types that are specifically provided for interface with existing DL hardware. Integer constants, on the other hand, can be entered as octal (0NNNN), decimal (NNNN), or hex (0xNNNN)...whatever is best for that particular value. I would personally routinely use decimal and hex, although octal tends to get used only for compatibility with octal I/O...which for the most part won't be present.
So...in short...we listened, we heard, and we're doing something about it.
-
As long as BCD is put out to pasture I'll be happy.
-
Out to pasture? Definitely. The words 'glue factory' come to mind though...the pasture is too nice a place.
-
As long as BCD is put out to pasture I'll be happy.
Just conversions to/from BCD are there for working with data from legacy systems that use BCD. No BCD math. No BCD analog. No BCD timer/counter presets/accumulators. 2's complement (aka decimal) and REAL with a few other conversion routines (e.g. STR2REAL to convert an ASCII string "3.14" to its REAL equivalent 3.14, great when doing comm with a device that sends ASCII numeric values)
-
Even when I was working with embedded bus systems, we never used octal. What you couldn't do in decimal, you could manipulate it in Hex or straight binary. Even the IO was in Hex. Come to think of it, are there any other PLC's that use Octal memory addressing? I guess Koyo was a real trailblazer for octal numbering. Maybe those guys had 8 fingers?
-
Check out the Zilog Z80 (I know - ancient history). It had eight primary registers and octal numbering was everywhere. As long as people understand it's just different ways of counting the same thing it's ok. It's when people don't understand the number systems at all...
-
Ironically, if memory serves, the GE Series 1/TI 305/DL 305 are all Z80 based. It is becoming clear how octal and BCD were both influenced by that processor. Of course once stuff becomes 'standard' it is like pulling teeth to change things, and the Japanese are a bit less software friendly than us in the US. Not quite German bad, but they do tend to hang on to the 'if it ain't broke...' philosophy. Germans leave it hard for the sport of it. ;)
Host, on the other hand, isn't nearly as set in our ways. Our biggest single concern is how to move the product forward, while minimizing disruption to the fine folks that use our products. On the new PLC, we pretty much put everything on the table and said from the beginning that compatibility wasn't a consideration. Again, I'm not willing to go into details here just yet, but we think ADC's customers are really gonna like this controller. I can't wait to say more. :-X
-
Integer constants, on the other hand, can be entered as octal (0NNNN), decimal (NNNN), or hex (0xNNNN)...whatever is best for that particular value.
Will the display follow the entry mode? If I enter "0x10" as a constant, will the box show "0x10" or "16"? Or is the display radix user controllable for the entire session? Not sure what the "right" answer is, just curious.
-
Even when I was working with embedded bus systems, we never used octal. What you couldn't do in decimal, you could manipulate it in Hex or straight binary. Even the IO was in Hex. Come to think of it, are there any other PLC's that use Octal memory addressing? I guess Koyo was a real trailblazer for octal numbering. Maybe those guys had 8 fingers?
Allen-Bradley has it in the PLC-5 family. LG uses Hex.
-
Will the display follow the entry mode? If I enter "0x10" as a constant, will the box show "0x10" or "16"? Or is the display radix user controllable for the entire session? Not sure what the "right" answer is, just curious.
Yes! The numeric format is stored in the opcode along with its value. Note that a small number of instruction parameters only take one specficic format, e.g. only decimal, or only take real. The ones that only take real will promote a decimal "7" to "7.0", for example. However, you can't enter 1.5 for something that requires a decimal number.
Some examples of these anomalies include the Modbus Unit ID that only allows decimal 0-255, or the Time Constant in a FILTER instruction where we promote any integer to its REAL value in DirectSOFT so that the PLC instruction does not have to do this int to real promotion logic EVERY scan.
-
Cool. After giving it some thought, I think that's probably the best answer.
-
I concur on the putting BCD in the grave. In a program with Reals, BCD, Binary, Octal, Integers, what have you, BCD just adds one more layer to the conversion confusion.
In the middle of a massive programming project right now and taking a focus break.