Siemens FB dev mon/mod values in VAT for debug... and other FB dev questions.

I am trying to build an FB as a wrapper for a timer... as any of you know me I am jumping into siemens newly/lately. It is not behaving the way I want want o be able to debug more, on the variables inside the FB. How do you see call them out? Do you need to do it by some DB address like dbxx.abcd or something... is it possible to do it by... FBMYFB#.#internalvariable?

Also... I created this FB as a something meant to be reusable (multi-instance.) I have several questions...
1. I called the FB- FB78... I associated it with a database DB78. So I am assuming this DB has to be deployed whenever you want to use it (well I am basically sure of that.)
2. The thing of it is... if you put the FB in an OB or FC... then you need to create another database for each instance. I am concerned about how these DBs relate... for each instance... is data-integrity ensured because each has instance has it it's own DB.
3. What if you use a memory address like T1 or MD30 inside the FB... it that something that always has to be kept in mind for the entire program? Or is it put in an memory internalized to the FB... and if it is not... lets say you need to use memory addresses... particular like a T address in the FB... how do you do this so that it is attached to the DB... my theory is that the T value is not internalized... and so if you put multiple instances of this in a program there would be a conflict. Let's just say I want to put a SFB in the FB... or a S5TIMER in my FB... it is going to want to be assigned to a T address... this seems problematic.

Sorry if this rambles a bit.

To be re-usable, the FB cannot contain any absolute addresses.

First,
DB = "Data block", not "database"

For inserting variables in VATs, you can use the absolute addresses (DB10.DBW20) or symbolic addresses ("Tank23".FillLevel). Just try, it is easy.

1. I called the FB- FB78... I associated it with a database DB78. So I am assuming this DB has to be deployed whenever you want to use it (well I am basically sure of that.)

Click to expand...

For code INSIDE the FBs where the instance DB is used, you use the declared addresses with the # identifier, i.e. #FillLevel.
For code outside the FB, you have to use the full symbolic name, i.e. "Tank23".FillLevel.
A sidenote: Some people consider it a no-no to access IDB instance outside its associated blocks. I do it all the time though and see no problems with it at all.

2. The thing of it is... if you put the FB in an OB or FC... then you need to create another database for each instance. I am concerned about how these DBs relate... for each instance... is data-integrity ensured because each has instance has it it's own DB.

Click to expand...

Yes, thats the idea of the instance-DBs.

3. What if you use a memory address like T1 or MD30 inside the FB... it that something that always has to be kept in mind for the entire program? Or is it put in an memory internalized to the FB... and if it is not... lets say you need to use memory addresses... particular like a T address in the FB... how do you do this so that it is attached to the DB... my theory is that the T value is not internalized... and so if you put multiple instances of this in a program there would be a conflict. Let's just say I want to put a SFB in the FB... or a S5TIMER in my FB... it is going to want to be assigned to a T address... this seems problematic.

Click to expand...

S5Timers, S5Counters and Merkers are arcaic relics from the old S5 times. It IS possible to use inside FBs, but quite cumbersome. For timers, use the IEC timers.
I only use S5Timers and Merkers for when I need to make some quick-and-dirty code !

I am making some progress... need more help...

So I got my timer wrapper FB working pretty good. The FB itself has the following inputs... (it wraps SFB4 so the interface is similar with some extras, and of course some differences... the intention is to use DINTs on the outside so everything is always in ms.

EN - bool
POWER - bool
PRESET - DINT
NPRESET - DINT - (haven't programmed this yet... originally the idea was to allow someone to use it to update the preset programmatically, but this can be compensated for by a change to the PRESET since it is wrapped... NOTE: none of these are directly tied to the embedded SFB4)
RESET - BOOL - (haven't programmed for this yet either.

outputs are....

ENO - bool
DONE - bool
ACCU - DINT - ms accumulated
ACCR - DINT - ms remaining
ON - bool - internal power is on
ERROR - bool - a basic error flag
CPRESET - DINT - ms - preset that is currently being used (if someone changes PRESET while the timer is running, it will not actually be update until the timer is done...) CPRESET allows someone to know what preset the timer actually is.

Ok so I made this FB78...it sits on DB79. Inside there is an SFB4 that is assigned to DB4. I have it working pretty good right now (according to the way I want it to anyway...) but ultimately the test is... running more than one at once. So during my POC for minimal functionality that would satisfy me... I put one FB78 in OB1 on one rung... so this is all that executes... this is assigned to DB10. Testing it like this... it works like a gem.

If I make another rung (network) in OB1, and add another FB78 assigned to DB11... some really strange things happen. The first timer works almost as expected, and the second one doesn't do anything. Again this is my first FB, and I don't fully understand data blocks. I included a few screen-shots... obviously they dont give the whole picture... but maybe there is something someone can point me to- the screen-shots are just to mainly illustrate what I have narrated.

Actually I won't even go that far... I maybe I can try to explain the problem a little bit more... it really quite simple... I try to set up the timers with different presets, 50000 and 75000... they both share a the same bit to turn them on in the OB1. Then they show different preset values, the one with the lower value counts up to the one set at the higher value. Then it reports done... the two done outputs are set to different bits... when the timers are turned on... for some reason the data is shared (or partially so.) There is really nothing they have in common... the only thing I can think of is the embedded SFB4 in FB78 is assigned to a database... and that is causing this confusion... sound like a good theory? If so how would you work around that?

Actually I will include some screenshots with descriptive file names just to give you something to visualize.

As you have allocated DB4 to SFB4 you can only use this particular call to SFB4 once. DB4 is the storage for all of SFB4's processing.

To use multiple instances, declare the SFB (or FB) in the STAT area and then call the block using the name you allocate:

e.g.

I think I get where you are going here....

Well the example you gave is actually inside the custom FB. There are not multiple SFBs in there... right now I am just trying to put two of my FBs- FB78 in OB1 (OB1 for now for simplicity...) first of all I just want to clear up that I am not trying to have multiple timers in my FB... I am trying to use the FB in a multi-instance style. So in the stat area the datatype I guess would be FB78. If I set up the stat section the way you say in say OB1... or an FC... would that compensate for the fact that my FB, FB78 has an SFB4 instance in it that uses one DB?

I think the critical point here is... I want to make an FB that is reusable (multi-instance) elsewhere... inside this FB I would like to use one SFB4 which requires a DB. When I create multiple instances of this FB in a program... how do I compensate for the fact that there is an SFB (4) inside of it... that points to one database? Is it possible or do I have to actually write rungs to actually do the timing in the FB?

FB78 can be added to another FB's STAT area, just as LAR's example put SFB4 in the STAT area.


The DB is the memory for the FB call, open the IDB and see how it looks, you will find it is the IN, OUT, IN_OUT and STAT areas from the FB its associated with.

If you call the FB multiple times and assign the same DB, this will not work as each and every call will over-write the data stored in the DB.

LAR's example is exactly what multiple instance is, its placing FB's (or SFB's) within the STAT area so that they share the same DB.

If you create a FB like LAR's example and insert a FB into the STAT area and call that FB and assign a IDB, when you open the IDB you will see the all the above plus all what is in the nested FB's IN, OUT, IN_OUT and STAT areas.

An IDB is a DB, just the same as any other DB, the only difference being that you cannot change the data format contents in the edit window, if you modified the FB's IN, OUT, IN_OUT or STAT areas, then you would need to recompile the DB so that it changes to the new FB data.

You can call an IDB anywhere in the program and read and write to it, just the same as any other DB.

You may consider making sure that you are programming in Symbolic mode in case you do update STAT areas or UDT's that are in STAT areas.

So in short you cannot create a FB which you can call multiple times using the same DB. (A slight lie, if your FB contained multiple calls to multiple instance SFB4 and you had some sort of pointer to jump to the one you wanted each time then theoretically you could do that).

PeterW said:

So in short you cannot create a FB which you can call multiple times using the same DB. (A slight lie, if your FB contained multiple calls to multiple instance SFB4 and you had some sort of pointer to jump to the one you wanted each time then theoretically you could do that).

Click to expand...

I really really appreciate the effort here... but I am trying to point out what I think is the critical problem... I am using an SFB inside an FB. The FB is intended for reuse... in an OB or FC. The problem is... first of all I understand that each instance of the FB I am creating needs its own IDB... BUT the SFB inside the FB is assigned to a DB... my question is... well this seems to be the problem... with the SFB inside the FB, which is assigned to a DB (the SFB in the FB...) it doesn't seem that is accounted for. I get that each instance of the FB as I put it in the program needs a separate IDB... but... what about that DB that is assigned to the SFB in the FB... based on what I am hearing, and based on my experience-based theory... that SFB inside the FB, with the assigned DB is not adjusted for... and so each instance of the FB when implemented... will have that SFB with only one DB assigned to it... how does one account for it with multiple instances? Or can it not be done... I like to keep things at a pretty low-level... if need be... I will remove the SFB from the FB, and recreate its behavior using more basic rungs within the FB... I really think this would work... I am just really frustrated with this and that would be a whole other mini-project... but when it is done at least it would work. I can't believe how ridiculous timers are in Siemens... I have read various other threads where people just write their own with no reliance on any SFBs or other timers... perhaps I'll just have to do that.

Nick Birke said:

I really really appreciate the effort here... but I am trying to point out what I think is the critical problem... I am using an SFB inside an FB. The FB is intended for reuse... in an OB or FC. The problem is... first of all I understand that each instance of the FB I am creating needs its own IDB... BUT the SFB inside the FB is assigned to a DB... my question is... well this seems to be the problem... with the SFB inside the FB, which is assigned to a DB (the SFB in the FB...) it doesn't seem that is accounted for. I get that each instance of the FB as I put it in the program needs a separate IDB... but... what about that DB that is assigned to the SFB in the FB... based on what I am hearing, and based on my experience-based theory... that SFB inside the FB, with the assigned DB is not adjusted for... and so each instance of the FB when implemented... will have that SFB with only one DB assigned to it... how does one account for it with multiple instances? Or can it not be done... I like to keep things at a pretty low-level... if need be... I will remove the SFB from the FB, and recreate its behavior using more basic rungs within the FB... I really think this would work... I am just really frustrated with this and that would be a whole other mini-project... but when it is done at least it would work. I can't believe how ridiculous timers are in Siemens... I have read various other threads where people just write their own with no reliance on any SFBs or other timers... perhaps I'll just have to do that.

Click to expand...

Why do you refuse to try out what has been shown to you? SFB is for all intents used like FB. FB can be inserted in STAT of another FB and thus used as multiple instance with it's data in parent FB's DB. When its in STAT, that instance naturally does not need its own DB as its data is in parent FB's DB.

IDB, instance datablock is just a name for datablock that stores some instances data.

Nick Birke said:

I think the critical point here is... I want to make an FB that is reusable (multi-instance) elsewhere... inside this FB I would like to use one SFB4 which requires a DB.

Click to expand...

As already stated, you cannot use an absolute address if you want the FB to be re-usable. Specifying a DB number for the instance DB for SFB4 is using an absolute address.

The terminology "multiple instance" does not mean you have to have many calls to the same FB/SFB, it means you have declared at least one instance of one FB/SFB in the STAT area of another FB. It is this "multiple instance capability" that will allow you to make a re-usable FB

PLC programming

I want to protect motor against excessive heating due to motor stall,I want to use the motion sensor to detect the motion of the motor rotation when it stall i will use the output signal from the sensor and program them so that it will activate the time delay timer in PLC to acumulate up to 60000msec the incorporate it with the stop circuit of the motor to disconnect it from the power supply to avoid overheating of the motor windings. Please help me how to program those voltage pulse from the sensor to perform that operation

Nick, what LD showed you in post #6 is actually multiple instance.
"Multiple instance" is not a good name for what it really is. Better would have been "FB embedding", or "nested embedding" or something like that.
The big point is, FB's that are inserted in another FB's declaration becomes part of that FB. And that you can continue in multiple levels of embedding.
When you create the IDB for an FB that has other FBs embedded in its declaration, the IDB simply contain all the embedded declarations. For example:
"My_IDB".Level1.Level2.Level3.FillLevel.
Level3 is embedded in Level2, and Level2 is embedded in Level1.

Try to create an IDB for an FB with other FBs embedded inside. Then open the IDB in the LAD/FBD/STL editor, and you can see how the data gets formatted.

Hope it makes it a bit clearer.

Just to re-iterate the above few posts, look at LAR's example, when the SFB is embedded in the STAT area, you don't assign a IDB when you use it within the block, because it is part of the main FB's iDB.

So in your case, if you called FB78 10 times and each time you correctly assign a unique DB to each FB78 call, then the SFB4 inside will also share the unique instances, because it is part of FB78's IDB.

Isn't that what you want.


The Eureka moment must come soon