Siemens S7 Tags in DB

Holmux

Lifetime Supporting Member
Join Date
Oct 2013
Location
Aalborg
Posts
279
Dear All

I am fairly new to the Siemens world and have a question.

I am working on a program that later will be integrated into a larger S7 300 PLC system, to avoid any collision with existing tags, how do I do this the best way ?
Do I generate a DB with the tags I need for the FC and call it from the FC or do I write everything in a FB, or am I totally lost and going in the wrong direction ?

Any advice would be great :)

Thanks

Holmux
 
You are on the right track. Everything I say below is in relation to the "ideal" case. Depending how big your code is, and what you are trying to do, it might not be practical. What are you trying to program?

You should probably be utilizing the interface of the FC/FB (the area that says in/out/temp, etc, at above the code) for all of your tags. Inputs and outputs should be used for information that comes from outside your program: either IO or data from other sections of the PLC code. Temps can be used for data that can be forgotten at the end of the program. These can be things like the middle steps of math problems, or a value you are only using once in the next rung. STAT variables are only available in FB's, and the value is stored between scans.

How to choose between FB and FC: If your program state is determined entirely by the inputs, and not on the past, then an FC is good. If you were creating an ADD block, then an FC would be a good choice. If your program needs to remember its state from cycle to cycle, then you should use an FB. If, for example, you wanted to have a running average of a process value, then you would use an FB, and store the previous values as STATs. An FC stores its data in local memory, which is lost at the end of the program. An FB stores all its data (except TEMPs) in its instance DB, to be used next scan.

It is possible to call one FB inside another, and use the same instance DB for everything. This is called "Multi-Instance".

If you program this way, with all tags as internal tags, then it is very easy to simply call the code again later, with different inputs, and effectively double your code in a short time.

Depending on how big your program is, it might not be practical to create 100 or 1000 inputs and outputs for all your real life hardware. In that case, if you want to avoid overlap, creating a DB might make the most sense. You can go back later and change all the DB references to the actual tags you want.

I also typically recommend that you not use the M memory for anything but testing tags, and that you use DB's for most things. If you know that the M memory is almost entirely testing, it makes it very easy later to make sure that all your test bits have been removed.
 
Great Advice from MK42

In addition I would add that your projects should be set up with Symbol priority rather than address priority by right clicking on the blocks folder and looking under properties. This need to be done for both projects and they need to be consistent before merger (right click on blocks folder and select "check block consistency".

In this way, if any addresses are duplicated in both projects then the duplicates can be re-addressed in the symbol table and the project re-compiled to make everything correct.

Nick
 
I am getting better at this :)

But I ran into a small problem shifting data down true a DB using SFC20, well I know I could have used a pointer, but this way I find it easier to fault fine in the system setting up production.

I have 12 data blocks in the DB I would like to shift down every 3 seconds, do I need to have 11 "SFC20" blocks in a row to solve this or is there something i missed ?

Holmux
 
You are correct that a pointer would be a different way to solve the same problem, but is usually considered harder to troubleshoot. In SCL, you could probably use indirect addressing via indexed arrays, but, otherwise, 11 calls of SFC20 is a straightforward method. It is also the only one available in LAD in the S7-300.
 
Well I tryed to squieez my way around it, but I am so far into my code I need to start looking at using indexed addressing.

It has been a long night so excuse me if this is a to simple question:

when I call a FB from a FC, and want to do multiple indexed addressing down true the FC, do I only call the DB one time at the first Network, or Do i call it in every network where I use indexed addressing ?
 
Once you open a db, it stays opened until you open or access another DB. Example below:

Code:
OPN DB1      //DB1 is open
L DBW 0
L DB2.DBW0   //DB2 is now open
OPN DB 1     //DB1 is now open
T DBW 0
 
Thanks LD

This leads me to another question

So if I have a input tag (Scale1) linked to DB1 in my FC interface, and I use "Scale1" somewhere in my code, will this set DB1 as open or is it only called at the start of the FC, regardless how many times I use "Scale1" ?
 
A fully qualified DB variable (DB1.DBD0 for example) is copied to the temp data area of the calling block and a pointer to the temp data is passed to the FC. Each access to the parameter inside the FC refers to the temp data area.
 

Similar Topics

I've got a whole bunch of L8's and a whole bunch of UDTs that use custom string lengths, but can't seem to figure out how to get these to...
Replies
4
Views
524
I've got a bunch of tags in my code & there's a column called "Retain" (by default they were all un-ticked) - see pic. "LaserN mm" is a distance...
Replies
10
Views
1,584
I'm a bit lost. I don't understand why my HMI (Simatic 1200) is not recognising any PLC tags. From the ethernet comms page , all seems OK. Yet...
Replies
15
Views
2,135
Hi, Is there an easy way to limit the input tag by using min and max tags from the PLC? Thanks
Replies
1
Views
1,248
Hi all I'm trying to display an indicator on my Ignition HMI and the source is a Siemens memory output. The output is %M0.4 (it's a bool alarm)...
Replies
10
Views
5,141
Back
Top Bottom