S7 and Data Blocks

[sduck 0]

Hello everyone I am trying to develop my first significant S7 program and have a question about the use of Data Blocks (global). As I come from the Rockwell world I am having some trouble adapting. My question is this, Is there anything wrong with using Global datablocks to sort of divide memory areas to sections of the program. For example, if I have an FC called "Conveyor 1" and I create a DB to use for all the associated internal memory. Am I headed down the wrong road here? Thanks Steve

[ianbuckley 0]

That is one way to go. You can use one DB and a bunch of FC's by function. You might also want to consider using an FB instead of an FC, since it has an associated DB with the call. For example, FB1 with DB1. You assign the local memory as part of the FB (in the top declaration area) and assign the instance DB as part of the FB call. If you have more than one set of conveyors (to follow your example), you could use DB1 for the first set and DB2 for the second set. I have swtiched to using FB's for most everything and I usually have one global DB also. There are certainly people with more Siemens expertise on this board, but that is my preference. Some other suggestions: Use IEC timers (SFB4 for TON, SFB5 for TOF) and counters (SFB0 for CTU, SFB1 for CTD, SFB2 for CTUD). These can be found under Libraries->Standard Library->System Function Blocks. The S5 timers and counters are very different from A-B. The IEC SFB's work much the same as A-B. Note that timers are edge triggered - if the condition for the timer is true when the logic scans it the first time, the timer will not start. This can be confusing if you don't realize it ahead of time. Also a timer with a PV of 0 never passes power, instead of always. So make sure PV is always positive. If you use an FB for the logic, you can declare memory space (STAT) as a timer or a counter to avoid using an instance data block for each TON or CTU call. OB1 is the main routine. OB100 is the power-up or intitialization routine. Pay close attention to the data types assigned to addresses because the bytes in each variable are stored backward: MB0 is the MOST significant 8 bits of MW0 or MD0. When you do a MOV command (or T in STL) the processor will store the data according to the data type of the target address. You can turn off the data type checking for the ladder editor, but it will not change how the processor handles the data. It will only allow programs to compile (with mismatched data types). Hope this helps! Ian

[sduck 0]

Thanks Ian Are there any disadvantages of using FB's as opposed to FC's. The particular logic segmenting I am concerned with is different parts of a sequential machine, IE..Infeed conveyor, drying rack, outfeed conv, etc. Different parts of the machine but not similar. I just want to build the initial architecture in a way to cause the least amount of work later on when we need to edit logic or troubleshoot.

[ianbuckley 0]

The fastest way to program S7 is with FCs and M bits. I was in a huge time crunch the first project where we used the S7, so that is how I went. On later projects, I have been using FBs more and more. Having a global DB for key settings and information is definitely a good idea. Seeing offline data of M variables is complicated, where with DBs, it is easy. Once you have a global DB instead of M bits, you are already using addressing like DB#.DBX.#. It doesn't really matter what # the DB is from that perspective (global or instance). When using FBs, there is an instance data block for every call of the FB. So if you change the declaration for the FB, you must re-create each instance data block. Not hard, but you have to remember to do it since the FB will called from another block. This can get tiresome if you are changing the declaration very often (building the block a bit at a time and testing it). Also, there is a small amount of housekeeping involved in getting the information you want stored into the global DB from each instance DB as appropriate. On the other hand, the instance DBs can keep all of the temporary information (intermediate calculation values, one shot memory bits, etc.) out of the main global DB. And the feature of declaring TON as STAT instead of an instance DB for each timer is very handy if you have more than a few timers in the project. I have to say that the ladder handling of this feature is less than ideal, but it can be done. Of course, if you want to put up with S5 timers, this is not an issue. Keep in mind that calculations to determine the preset or remaining time values of an S5 timer require an extra step or two. I have done some medium sized projects both ways. I tend to think the FBs help program organization in the long run, but that is just my opinion. On a somewhat related note, if you have the time, learning the basics of STL makes a lot of little things easier to do. Simply entering the logic in ladder and switching to STL view is an easy way to figure out the most used commands.

[sduck 0]

Thanks again. I appreciate your taking time to answer my question. I have done as much homework as I can, reading all the manuals, and looking through example programs, but nothing beats real world experience. Steve

[Groo 7]

A couple of things make things easier. 1. Change priority to Symbolic. Right click the blocks folder and go to properties and change to Symbolic. What this will do is make the symbol the default. 2. If you know the types of blocks you want to create and the data format, then create UDT's and embed these in your FB stat areas. Did you know that global DB's and instance DB's are treated exactly the same, the only difference is the fact that you cannot modify the instance DB structure, instead you have to modify the FB io and stat areas. Other than that as far as programming is concerned you can open and access GDB's or IDB's in any other block and read or write into them. You can also nest FB's into the stat areas of other FB's, that way having a master FB where the others are called and they would all share the same IDB. The m,ore you look into what you can do the more wonderous it becomes. Pity poor me who has to convert IP620 code to Masterlogic for my current job (retro all the way)

[ianbuckley 0]

I had not thought of the nesting FB's conecpt. I have been using a structure like OB1 -->FB1, FB2, FB3, etc. where FB# is used to handle a task (machine section, communication interface, etc.). It sounds like it could be OB1--> FB1-->FB2, FB3, etc. I assume you use the empty box to call each FB by symbol like you do for an SFB4? That would make one instance DB for everything. Very nice. I will have to try that. Thanks for the tip!

[Groo 7]

There's actually 2 ways to share the IDB. The first as I mentioned above, put the FB's in the STAT area and you call them in a similar way to the library blocks. The other way is to create FB's with the exact same structure as the main FB (up to where it needs data), then call it from within the FB with the UC instruction. The advantage of the second method is the fact that it can access any STAT data, the first can only access its own STAT data.

[sduck 0]

Good stuff guys, keep it coming...