Move Bits Into Byte W/ Siemens

[DesertDog]

Using Siemens Step 7, I and wanting to move 8 sequential bits into a Byte using the label instead if the direct address so that adding/removing variables will not cause me to need to readdress everything. Is there any simple way to do this. The bits are defined in the STAT section of a function block and I want to simply move them into a Byte. I have done this many times with GE & Melsec but cant find a simple way with Step in it 7.

 

[Peter Nachtwey]

I feel your pain.

Does anyone have an answer to this problem? I want to know this too!
I ran into the same problem, and others, two months ago when I was programming/fighting the Step7. I know it is hard to write PLC programming software, but after 6+ years the product should have the basic deficiencies worked out. DesertDog and I want to typecast variables. (a C programming term ). DesertDog's and my requiest seems basic to me. What is the excuse?

Bumped to the top.

 

[tesalmin]

When using FBs you always have instance DB for that FB. You can find all the STATs you have in the FB from that instance DB.

For example: FB10 with instance DB10. If you want to move first 8 STAT bits into byte MB10

L DB10.DBB0 // DB10 BYTE 0
T MB10 // Save to MB10

I hope this was what you ment!

Hope this helps


TS

 

[Peter Nachtwey]

L DB10.DBB0 // DB10 BYTE 0
T MB10 // Save to MB10

This is not quite right.

What we want to do is this:

dwStatus  DWORD 0

          L dwStatus

          or

          A dwStatus.1       // LIKE AB.  LOAD BIT 0 of dwSTATUS

          or 

          L db dwStatus        // LOAD ONLY THE FIRST BYTE OF dwSTATUS

In the case above the DB would overide the default type DWORD of dwStatus.

Another way would be to do this would be to use an alias. ( Similar to the Control Logix ) Like this:

dwStatus  DWORD 0           // standard declaration of a dword
xStatus   BOOL  AT dwStatus
dbStatus  BYTE  AT dwStatus // Declare a byte at the same locatin
                            // as dwStatus

Now I can access the data at dwStatus as BYTES, BOOLS or DWORDS.

As DesertDog says, now dwStatus, xStatus and dbStatus location will all change automatically if another variable is inserted so the location of dwStatus changes.

Using hard coded address such as suggested is not acceptable. If a location changes then one must go through the whole program and look for all locations that changed. If one location is missed then the program may fail. This is too error prone. One should be able to access data at a location any way he wants and do it symbolically.

 

[tesalmin]

OK Now I think I understand what you want!

STEP7 seems to be working with HARD ADDRESSES so if you change the address of a symbol then you must make REWIRING to change the program so that new address is used for the changed symbol.

STEP 7 seems to be oldfashioned in many functions compared to other programs.

Somebody has told me that if you know how to work with STEP7 then you know how to work with all other manufacturers programs. Wonder if this is true???

TS

 

[Klaus]

If you still are in the Fb call you can do as follows


Lar1 p#YourDword //Loads your dword in pointer format in adress register 1

l d [ar1,p#0.0] //Load the whole dword

L w [ar1,p#0.0] //Load the first word of the dword

L w [ar1,p#2.0] //Load second word of the dword

l b[ar1,p#0.0] //Load each byte of the dword

l b[ar1,p#1.0]

l b[ar1,p#2.0]

l b[ar1,p#3.0]

A [ar1,p#0.0] //Access the first bit of the dword

A [ar1,p#3.7] //Access the last bit of the dword

Now you can add more stat variables since you load the pointer with a symbolic name.

 

[Klaus]

Hmmm i see that the comment on the bits wasent the best. What i mean is that you can use any bit instruction. A An O Or X.... and so on

 

[tesalmin]

Klaus has a good solution.

Just use the first bits symbolic name as pointer for reading 8 bits into Byte.

LAR1 P#FirstBit
L B [AR1,P#0.0]
T MB10

 

[DesertDog]

We're getting close, thank you all so much. I think I can use this but I'm not at all familiar with STL and it takes me a good deal of time to work it out. Even if it has to be STL can it be made into a FC to use? Where BoolIn is the frist Bit of 8 to be used and Byte out is a byte with the bit pattern of the 8 bits. Reversing this would also be useful but I should be able to figure that out once I understand this way.

Example:

------------------|-------|----

                  |       | 

           BooIn  |       |  ByteOut 

                  |       | 

                  |_______| 

OR

------------------|-------|----

                  |       | 

          ByteIn  |       | 

                  |       | 

          BoolOut |       |  

                  |_______|

 

[DesertDog]

Will This Work? It's really simple if it does.

------------------|--MOVE-|----

                  |       | 

        P##BooIn  |       |  #ByteOut (Or Word/Dword as needed)

                  |       | 

                  |_______| 

This shows like this in STL:

  L    P##BoolIn
  T    #ByteOut
  NOP  0  //I do understand this is only because it came from LAD

 

[DesertDog]

It is not that simple, It does Not work that way But the code below (Adapted from tesalmin & Klaus) works fine. Thank's everyone... but can someone explain what exactly is going on to a ladder type person (me) and is this possible to do in a ladder format?

  LAR1 P##BoolIn
  L    B [AR1,P#0.0]
  T    #ByteOut

 

[Peter Nachtwey]

DesertDog needs to use a little STL

DesertDog, I think you need to learn STL. A STL is sooo much more efficient and is obviously necessary to do anything tricky. In any case I declare some variables called:
dwTemp DWORD
lTemp LONG
wTemp WORD
nTemp INTEGER
bTemp BYTE
xTemp BOOL

I would the use the STL load instruction to fetch the data I want to convert and store the data in the ?Temp variable that matched the way I wanted to access it.

L IntegerData // CONVERT INTEGER TO WORD
T wTemp

DesertDog, this means you only need to use two STL instruction to copy the data from one type to another. Then you can use LAD on the next rung. Yes, you can mix LAD and STL. I use to do it all the time until I became comfortable in STL.

Klaus' trick is good, but it doesn't alway work. Inside an FB the inputs and outputs are not static memory, but pointers to the data. STL does not let you get a pointer to this data. Inside a FB I copy the inputs into a temp register using the trick above.

Ok, now everyone knows I have a work around this problem, but I shouldn't need to. More importantly, DesertDog should need to. I am surprised that none of the other real S7 programmers jump on this.

 

[DesertDog]

Thank you, I am trying to decipher STL but I've only used Siemens for a year. With the GE & Mitsubishi I've used almost a decade I don't have to resort to this level. With them it's like DOS vs Windows, nice to know, comes in handy but not really necessary. Siemens expects you to use STL and doesn't have all options available as LAD.

 

[Klaus]

Tesalmin thank you for the correction above. I was in a hurry and dident read the text correctly. I somehow got the impression that you wanted to read bits from a dword.


Desertdog. Its possible to do the block that you described but im afraid just as earlier repliers stated it wont work with symbolically adressed in/out parameters. Step7 will still use the "hardcoded" adress. If you for example use "Symbolicnamefordb1"."Symbolicnamefordbx0.0" as In and then add a byte instead of the bits in db1.dbb0 Step7 will still use db1.dbx0.0 as in parameter. I dont know any way to fix this but that dosent say that it cant be fixed.


------------------|--Your-|----
| Fc |
#BooIn |In Out| #ByteOut
| |
|_______|

If you still want to code the above described block let me know and i can show you how. And if so should #BooIn be the msb or lsb.

 

[RRobbins]

I think I know what you are looking for. I have attached a way to examine the bits in a byte, set or reset them and put them back into the byte. That byte can be addressed in the program for other uses. The function attached does not have to be in a FB, but will work fine in a FC using the TEMP area instead of the STAT area. Since the value is loaded in at the beginning and transfered back at the end of the function, there is no need in using an Instance DB for it, unless you have other data you want to store.