TIA Portal make a muli instance of timers in one global db

dahnuguy

Member
Join Date
Mar 2007
Location
SC
Posts
720
Win10 VM TIA Portal Pro v 15 with WinCC Pro RT

I remember doing this in S7 and I am sure it is simple, but as wonderful as TIA is, it is adding a layer of obstruction.

I want a global DB to contain a series of multi instance FBs.
Hopefully in an array[0..n] of FB.

db_"all my valve data"
FB ValveControl V1
FB ValveControl V2
FB ValveControl V3

some other stuff..

or

FB ValveControl array[1..n] of "FB ValveControl"

some other data

The global db in question would have all the valve FBs in an array of mulit instance and also other data. So not a dedicated db for just this one thing.

I tried declaring the FB as a data type but doesn't like it. Even added it to the type library.

I am using non optimized dbs throughout for several reasons.


Going to try calling it from another fb and see if it will allow the multi instance and then see if it will allow me to copy that into a global db and change the link

I think it would be nice to have all the FB block data in one place and expandable for each project so an array would be easy and then the HMI could point to that area.

Maybe what I am doing is slightly off for this version of Siemens.

Any suggestions?
 
Why do you not want to to use an instance DB?

Why would you want 20 small instance dbs when you could use one?

...all in one place easy to point a screen at etc...

I can nest them in a parent calling FB with no interface and then it will work, so why not do essentially the same thing just in a global DB? I guess that would be the way to do it. Use FBX and put the array or FBy inside FBx in the stat area. With no interface on FBX, it is essentially what I want. Then add the other stuff after the multi instance in the Stat area,

I was just wondering why that would work but not using a global db for the same result. or if it would work and I was just doing it wrong.

I will most likely just use FCs and make an array of udt for each FCs memory structure. Similar result... all in one place, easy to address with an index , easy to make an HMI screen ....etc etc.
 
I think L D[AR2,P#0.0] was referring to the instance DB of the parent calling FB you refer to above... have you considered that option?

Yes, just don't like it.

Would like the option to use a global db without the added empty FB to get the instance db.

Sometimes I can't tell if what I am doing isn't working because it can't work or maybe I am just doing it wrong.

As for the why....It would be nice to be able to just add a small block instance into an existing memory structure.
 
What advantage would you get by using a global DB over an instance DB?

would not need to have the unnecessary parent FB shell.
could add items into an existing DB with other related data.

not a huge issue I guess.
Just make the shell FB and add everything to its STAT area.
I already had several nested layers, didnt want another one.

Maybe next time, I will start out using the parent FB idea.
 
I think it would be nice to have all the FB block data in one place and expandable for each project so an array would be easy and then the HMI could point to that area.

I missed this bit before, but sounds like a recipe for disaster.

I'm using Siemens Open Library and the way they solved this problem is to create a structure that gets added as an InOut Parameter where you can write your inputs and have your HMI Outputs I a place that doesn't open up the possibility of someone writing into a variable used by the internal logic that shouldn't be.
 
I missed this bit before, but sounds like a recipe for disaster.

I'm using Siemens Open Library and the way they solved this problem is to create a structure that gets added as an InOut Parameter where you can write your inputs and have your HMI Outputs I a place that doesn't open up the possibility of someone writing into a variable used by the internal logic that shouldn't be.

I think what you are thinking is not what I am thinking
 
Win10 VM TIA Portal Pro v 15 with WinCC Pro RT

I remember doing this in S7 and I am sure it is simple, but as wonderful as TIA is, it is adding a layer of obstruction.

I want a global DB to contain a series of multi instance FBs.
Hopefully in an array[0..n] of FB.

db_"all my valve data"
FB ValveControl V1
FB ValveControl V2
FB ValveControl V3

some other stuff..

or

FB ValveControl array[1..n] of "FB ValveControl"

some other data

The global db in question would have all the valve FBs in an array of mulit instance and also other data. So not a dedicated db for just this one thing.

I tried declaring the FB as a data type but doesn't like it. Even added it to the type library.

I am using non optimized dbs throughout for several reasons.


Going to try calling it from another fb and see if it will allow the multi instance and then see if it will allow me to copy that into a global db and change the link

I think it would be nice to have all the FB block data in one place and expandable for each project so an array would be easy and then the HMI could point to that area.

Maybe what I am doing is slightly off for this version of Siemens.

Any suggestions?


Portal/1500's really assume you're nesting your FBs within other FBs to maximize the full potential. RESISTANCE IS FUTILE, but I honestly don't know why they need to be so specific sometimes. Presumably the answer is that a big enough customer hasn't demanded the possibility yet....



The alternative would be to switch the blocks with array instances to FCs, and then create a data type that would be passed as an INOUT. Then its just normal data you can do whatever you want with, not a special magic Instance. Downside is that you effectively need to manage the local data of your block externally in the data type editor, which could be a pain.
 
It is a new functionality if TIA allows you to do it like that. In STEP7 Classic you definitely could not do it.

One reason I would not do it in that way, is that you would then have to make a seperate FC or FB, for each "instance". This because you would have to adapt the addressing of the timers manually.
So in that way you will not benefit from the FB or FC being "reusable" in the real sense of the word.

This is my suggestion:
Program the IEC timers as multiple-instance the normal way. The parts of the timers that needs to be changable at runtime, i.e. the setpoint for each timer, transfer that via an IN_OUT (defined by a UDT). Than have these values only stored in a shared DB.
 

Similar Topics

Im trying to create a level indicator for water Tank i have used the ADD function while the pump is on and level increasing everything works...
Replies
14
Views
96
My PLC (S7-1200 with CPU-1212C) has now been delivered to customer site. They've asked me to do some updates to the software. I can do that on my...
Replies
21
Views
330
Does anyone know why the connection interface is greyed out and says why I can only use Teleservice instead of the other options like PN/IE? I am...
Replies
0
Views
44
Hi guys I after a bit of advice on Tia portal graphics, I would like to add a conveyor belt graphic to a hmi and the conveyor in the basic...
Replies
3
Views
130
Hi I used to be able to launch PLCsim without any problem. Now it tells me " STEP 7 Professional Licence is required to simulate this PLC"...
Replies
15
Views
453
Back
Top Bottom