integer value = bits on

[drewcrew6]

I believe this is what you are looking for. 1 rung of logic.BST DCD N9:6 N9:7 NXB SUB N9:7 1 N9:8 BND I tested this on a SLC504.Using a Decode function, DCD N9:6 (Source) into N9:7 (Dest)

Input value of 15 faulted my proc.
(-32768) - (1) =(-32769)


There is always that one number that gets ya!!!

Anything else??

It seems so simple in thought but................

I to prefer short and sweet. Since its only for me I'm not to worried about getting a call in the wee hours of the morning that its broke down. I'm also not worried about the logic being above someone's head only mine!!!

Thanks
Drewcrew6

 

[Eric Nelson]

Yes, it would be nice to find a 'short and sweet' way to do this, but all the 'tricks' have hit roadblocks so far (mainly because of that damned 'sign' bit). I don't have any AB stuff 'laying around' (they're busy making money!), so I can't do my own investigation.

Have you tried AK's 'brute force' idea? I tend to use 'tricks' to save code myself, but I have nothing against his method (assuming it works), because if the documentation somehow 'disappears' in the future, the next guy can probably figure out what is being accomplished by the logic.

One possible 'patch' for the sign bit problem (using Mark's version):

|    N9:6 > 15                   +------------+

|--------] [---------------------| MOV        |  When input > 15, 

|                                | Source: 14 |  change it to 14 

|                                | Dest: N9:6 | (for use in Mark's code 

|                                +------------+  so it won't fault)

|

|

|-------------------------> Use Mark's Code      It will 'think' the input is 14,

|                                                and turn on bits 0-13 

|

|    N9:6 > 15   

|--------] [--------------------------( Bit 14 ) When input > 15, turn 

|                                                on bit 14 manually

|

|    N9:6 = 16   

|--------] [--------------------------( Bit 15 ) When input = 16, turn 

|                                                on bit 15 manually

Wish I could test it myself...

beerchug

-Eric

 

[Peter Nachtwey]

It appear my first instincts are right.

This is why I like the lookup table. It is fast and I don't have to get involved with all the deficiencies of the particular PLC. The lookup table would be understandable by anyone an memory is cheap. It just requires on indirect or indexed instruction and a register file to place the lookup table.

Programmers that use one particular PLC tend to know the quirks of their PLC inside out. Those that use many PLCs tend to use least common denominator programming. The look up table and my techniques tend to be in the later category.

 

[Jnelson]

Ok, Amatuer question.

Could someone explain the operation of a lookup table, for say a SLC. I assume that it involves pre-mapped constants stored in a integer location, but I cant seem to grasp the rest.

Thanks in advance

 

[ejessen]

That's really a neat way to do it Mark. Didn't think of that way to solve it.
Either I'm not smart enough or maybe I'm just work with too many different brands to make the smart programming and tend to make programs that will work in most PLC's, like Peter.

I must say that I like to make programs that calculate their way rather than making a look-up table. The calculation saves rungs but is harder to read for the next guy, but small calculations like this one is easy to see through and easy to explain in the rung comments.

I've attached the ammendment to get the value 16 going as promised, and it is done like Eric Nelson also have described it (I'm just not using Mark's smart code).

A funny thing though, watching the scan time increase due to the FOR-NEXT loop as the value increases. As the value increases, the scan time increases by approx. 5ms, but dealing with the sign bit increases the time by only 2ms.

 

[ejessen]

..and here's the code

 

[Doug_P]

Ok, Amatuer question.

Could someone explain the operation of a lookup table, for say a SLC. I assume that it involves
pre-mapped constants stored in a integer location, but I cant seem to grasp the rest.

Thanks in advance

You're correct so far (the TABLE part). The LOOKUP part comes from the input value.

To LOOKUP a value in the table (it doesn't necessarily have to be a constant),
the input value is used as an 'index' into the table. You have a
table of ten values and some operator input, say, 1-10, which tells
the program which numbered value you want.

First, subtract a value of one from the input given so the
instruction will access the 0th through 9th elements of your table.

You may at this point want to do some validation of the input value
to prevent processor faults. In any case, the conditioned input value
is now applied as an indirect or indexed address to get the lookup value.
As Peter Nachtwey states, it's fast, and, the execution time
is the same no matter what value is being used.

N7:0 = 34
N7:1 = 27
N7:2 = 401
N7:3 = 93
N7:4 = 66
N7:5 = 5280
N7:6 = 119
etc.

   one_shot        SUB

-----] [---------+------------------+

                 | A: INPUT         |

                 | B: 1 (CONST)     |

                 | DEST: WORK WORD  |

                 +------------------+



 INDIRECT EXAMPLE

WORK WORD becomes a variable address component which 'points' to a

designated address. In contrast, N7:1 points to an address also,

you just can't change it on the fly. IF WORK WORD holds a '2', the

value returned will be '401'.                            

                   MOV

-----------------+------------------+

                 | N7:[WORK WORD]   |

                 | OUTPUT_WORD_1    |

                 +------------------+



 INDEXED EXAMPLE                            

                   MOV

-----------------+------------------+

                 | WORK WORD        |

                 | S:24 (IX REG)    |

                 +------------------+



 CROSSHATCH '#' DENOTES INDEXED ADDRESSING

Here, the value in the index register is added to N7:0.

If IX=3 the instruction's effective address will be N7:3

and the value '93' will be returned.                            

                   MOV

-----------------+------------------+

                 | #N7:0            |

                 | OUTPUT_WORD_2    |

                 +------------------+



INDEXED INDIRECT

Some A-B processors allow this additional addressing mode.



If IX=3 and WORK WORD=2 the instruction's effective address

will be N7:5 and the value '5280' will be returned.                            

                   MOV

-----------------+------------------+

                 | #N7:[WORK WORD]  |

                 | OUTPUT_WORD_2    |

                 +------------------+

For what it's worth, most any file structure can be used. You could
just as easily look up canned text messages in a string file using
indirect addresssing like so: ST9:[WORK WORD].

 

[Jnelson]

Thanks allot Doug, that was a really great explanation and I fully understand this now, except for one part. In your forth example you use a # sign to indicate a indexed address. Could you give me an example of how this would be entered into the processor, as I have never seen this method used. I was not aware that you could enter other instructions ahead of the integer address. I guess in a way I have been using this all along in the simplest form, I just didn't know what it was called. Darn that fancy, shmancy wording anyway!

One quick edit also, How do you make the work word a variable address? I mean how would it be entered in the move instruction?

Thanks again for the excellent explanation

 

[Doug_P]

John,

Indexed addressing is specified with the '#' sign (shift-3). Indirection is specified with square brackets [address].

If you've never applied these addressing modes before, I suggest, if it's possible, that you experiment with an 'offline' processor. With the power these addressing modes supply comes responsibility. Mainly, the responsibility of making sure you don't exceed file boundaries and fault the processor. Good luck!

 

[Mark Buskell]

Decode addition

Eric's way would work find in preventing the error. However there is another way that I believe should be used instead. At the end of every SLC program that I write, I have an unconditional rung that simply uses a OTU of S:5/0. This is the minor fault reset. Besides the overflow it also prevents devide by 0 errors.

Like I said, I use it on every program and have never found a good reason not to use it. If there are any counter-arguments against using the unlatch, please respond and teach an old dog new tricks.

Mark
esystemsusa.com

 

[ejessen]

When I come across a program that uses the unlatch at the end of the the program, I usually see that as a sign that the programmer have had some problems with his program, but couldn't find the answer to it.

I usually use the LIM instruction or simular code to check a value before it gets out of range. That way I newer get into dividing by 0 or a false operator input or an unespected value from a network device. I figure that I would rather (sure - depending on the situation) run with the old value than change the value into an acceptable one.

But I fully understand the use of it. Why jeopardize a production, when it could be prevented by a small unlatch instruction?

Hopefully the programmer send some warning to the operator or other onsite personell - in most cases its due to a faulty sensor.

 

[drewcrew6]

Okay I will probably use a modified version of marks 1 line example. It is short sweet and reasonably easy to understand. A second rung should Be able to work around the "15" fault ,And the "16" resulting in 0. Simple leq in rung 1 And geq with lookup table style in a branch in rung 2. I don't feel bad now that I couldn't get any simple code to do it all on my own,After the amount of time and effort by everyone on here.

As far as the "OTU of S:5/0" I don't like to use them to make the code work. The code in my opinion should be self sustaining.
But usually include them with a counter to track how often it does get set in case of program mods in the future and people just learning trying to make program changes.

I think this was a useful thread do to the attention and other Q's getting answered. If anyone does see another way don't let the post die.


Thanks Everyone
Drewcrew6

 

[RRobbins]

WOW, that's a lot of work. I thouth there must be an easier way. So I created a library function in Step 7 for anybody who wants it. Enjoy

 

[Peter Nachtwey]

Doug P, you will scare away the rookies.

This should be very simple. Put the data from drewcrew6's table in N9:0 and use this rung. Don't for get to check the result OK bit before using!

 

[Doug-P]

How do you make the work word a variable
address? I mean how would it be entered in the
move instruction?

If I understand you correctly, you can't. Current
A-B processors (at least the ones I'm familiar
with) do not allow an indirect address to contain
another indirect address. This is referred
to as double indirection. I'm pretty sure the
PLC-3 does allow multiple levels of indirection
but, it's clunky at best. And, a it's good thing
it's not available because what's going on can
quickly get out of hand when more than one level
of indirection is used!

Some computer languages, C is one, I believe, do
allow multiple levels of indirection.