Ti 555 I/o ?

bentleya

Member
Join Date
Nov 2002
Location
NE KY
Posts
69
Hello all,
One quick question...Does a TI 555 CPU consider (for example) X1808 and Y1808 as a conflict (duplicate) I/O point?
Of course, the software will NOT flag duplicate points! (What a wonderful world) :)
FYI (if you have time to read and nothing better to do)
I'm working on an existing system with a 555, 16 RBD's (remote-base-drop) and a bunch of I/O. The previous engineer didn't duplicate any numbers, as far as inputs and outputs go. If his last input was X1505 then the outputs started at Y1506.

Any thoughts appreciated!
 
Yep. You got it. That series of TI processors does indeed consider X's and Y's with the same numbeer as an I/O conflict.

Steve
 
bently...

Steve is right, of course. The TI works with a single I/O Table. That Table contains both Inputs and Outputs. So yes, the rule is, you can not assign the same number to an Input and an Output.


Now, regarding your X1505-Input and the Y1506-Output...

WARNING !!! I had some time on my hands... so...

Most, if not all, PLC's deal in "Octal-Boundaries".

An Octal-Boundary indicates a point of separation between one octal-group and the next octal-group.

Given any integer, greater than, or equal to Zero, divide it by 8... if the result of the division leaves no remainder, OR, if the remainder is 8, then the given number is an Octal-Boundary.

Examples of Octal-Boundaries: 0, 8, 16, 24, 32,... etc.

Notice that the first member of the list is "Zero" ("0").
0 / 8 = 0 with remainder 8. Zero is an Octal-Boundary.

Now... the manner in which a particular PLC uses "Octal-Boundaries" is dependent on one question...

"Is Zero a VALID Member?"

In the strictest mathematical sense, "Zero" is certainly a Valid Value. However, there are cases in math where "Zero is NOT Defined". That is, it is declared that Zero is NOT a Valid Member.

The engineers at TI decided that "I/O-Point-Zero" is something akin to "I/O-Point-Nothing". It seemed reasonable to them that the first I/O Point should be referred to as I/O Point-1. It's simply closer to the way that we (humans) think about things... i.e., a little more "natural".

So, if, in the set of all Positive Integers, Zero is NOT Valid, then the first valid member is "1".

The first I/O point in a TI System is always "1", either X1 or Y1. That is, for this particular usage, TI declares that Zero is NOT a Valid Member!

TI (and most other PLC's) expects Inputs and Outputs to be assigned relative to "Octal-Boundaries". But, if Zero is declared NOT Valid, then how is the Octal-Boundary relationship maintained?

The Octal-Boundary relationship is maintained by specifying that the first member of any Octal-Group is equal to an "Octal-Boundary + 1". That is, the entire set of Octal-Boundary numbers is offset by +1. This produces the following set of numbers...

"Octal-Boundary + 1": 1, 9, 17, 25, 33,... etc

TI requires that the FIRST I/O point on any given card must receive a specifier number equal to an "Octal-Boundary + 1". On the first card, that would be Input-1 or Output-1 (first Octal-Boundary "0" + 1 = 1).

This means that an "Octal-Boundary" identifies the LAST I/O Point on the previous card. Octal-Boundary "0" would indicate the last I/O Point on the previous card if there was one... there is not a previous card.

The particular boundary number that applies for any particular card depends on the type of cards that have been used up to that point. You could have used any combination of 8-, 16- or 32-Point I/O Cards. (Then there are the Special Function Cards... Let's stick with digital I/O...)

An 8-Point I/O card is a "Single-Octal-Group".
A 16-Point I/O card is a "Double-Octal-Group".
A 32-Point I/O card is a "Quadruple-Octal-Group".

Inputs and Outputs DO NOT exist together in the same "Single-", "Double-" or "Quadruple-" Octal-Group.


blah, blah... blah, blah... blah, blah, blah...

Yeah? So what the heck is the point?

If 1505 is supposed to be the LAST I/O point on a card then it should be EQUAL to an "Octal-Boundary".

Then, if 1506 is supposed to be the FIRST point on the next card, it should be EQUAL to an "Octal-Boundary + 1".

Let's assume that you have used all 8-point I/O cards - that will expose all octal-boundaries.

1505 / 8 = 188.125

188 = the 188th octal-group
.125 = the first of eight in the 189th octal-group.

Note: The first Octal-Group is "0". This is clearly exemplified by those PLC's that designate Inputs as I0.0, I0.1, etc.

This means that 1505 is the first point following the 188th octal-group. That is, 1505 is the first point in octal-group 189.

That also means that 1506 is the second point following the 188th octal-group. That is, 1506 is the second point in octal-group 189.

Both of these points are in the same octal-group (189). That is, you have an Input (X1505) and an Output (Y1506) in the same octal-group... not good!

The actual octal-boundary (last point in the previous group) is 188 x 8 = 1504.

The first point following the previous group should be... "Boundary + 1" = 1505.

I/O Point 1505 should be an Output (Y1505)!

If the 189th octal-group has been assigned as an OUTPUT CARD then referencing point 1505 as an Input is useless. Referencing the remaining seven points as Outputs will work as expected.

If on the other hand, the 189th octal-group has been assigned as an INPUT CARD, then only the first point will work as expected - as an Input. The remaining points, referenced as Outputs, will not work as expected.

Now... what I'm curious about is... how did that last Input specifier end up in the wrong octal-group?

When I/O is configured on the TI (at least, through TISoft), slot assignments automatically show the appropriate "Boundary + 1" specifier! That is, if you tried to assign the 189th octal-group as starting with 1506, TISoft would automatically correct it, downward, to a valid specifier... i.e., to 1505... that is, unless 1505 already exists... actually, I don't know what happens then.

This appears to be a case of the programmer "mis-using" an I/O Point Specifier... That is, I think, if you look at the I/O configuration, you'll see that 1505 is specified as the First Point on the card, i.e., "boundary + 1".

There are two concerns:
1. Referencing incorrectly (input as output, or vice-versa)
2. I/O point 1505 might indeed be wired, in the field, to the wrong kind of device (i.e., Is Input Device, should be Output Device, or vice-versa).

So... referring to X1505 is a programmers error... the program should be referring to Y1505.

Then, even if the reference is corrected... that is, the program is now referencing 1505 as an Output (Y1505), if that I/O point is wired to an Input Device, then that I/O point is still useless!

On the other-hand...

...if you simply pulled those numbers outa yer A$$, then, never mind.

... maybe somebody learned something anyway.
 
Terry,
Great reply!
I know the old TI 305 units are octal. I still have one in operation (but not for long).
The TI505 series are based on (16). Pretty much like most others with the exception of not using 0, of course.
As for "pulling the numbers out of my a##"....you are correct. I was just giving an example of using consecutive numbers, which by the way, wasn't correct for a TI505 series either. I believe it should have been 1504 & 1505. One card (16 IO) would be X1505 through 1520.
The next card would be (X or Y)1521 through 1536.
I must have been having one of those cranal (lack of) moments.
Any way, I appreciate the detailed description. I'm sure it will help some get an understand of how it works.
 

Similar Topics

Hello, Anyone here have any suggestion for a nice fail over user program for the SEL RTAC. Specifically having two RTAC sharing one 2440 Axion...
Replies
0
Views
103
I still have three applications using the 1756- L55 Processors on some new clients and in the need copy of Firmware ControlLogix 5555 1756-L55...
Replies
9
Views
4,187
Hello Guys, I´m try to upgrade from an old TI-555 plc to CTI-2500: 1. Program has been downlaoded to CTI-2500 without any errors. 2. I/O config...
Replies
12
Views
2,520
We are pulling our hair out trying to figure out this issue. We have an AB*MPL-A330P-HK22AA servo motor that started randomly throwing E22 and E24...
Replies
4
Views
2,552
After uploading the program from a Siemens 555 processor and comparing it to the file that was saved from the last time someone was online a few...
Replies
3
Views
1,513
Back
Top Bottom