Rockwell v Tia Portal

cardosocea said:

In Step7, as far as I remember, the function to "cross reference" a variable inside an FB is not really cross referencing, but instead showing you on sequence where the variable is used (Ctrl+****+F and G ??).

I believe that if you cross referenced the address outside (InstanceDB.DBXXX) you'd be able to see the uses of that variable, but not the STAT inside the FB as they are not the same thing. One is a pointer if you will that can point to any instance DB, the other is the actual instance DB.

Although, I found that this was possible in the exact same way... banging my head not understanding what was going on only to, by chance, notice that there were references to the Instance DB and digging up on it.

Click to expand...

Yeah, I can understand why the cross reference tool doesn't get both types of uses together, I just wish it did. In theory (at least in Portal), it's compiling everything anyway, so it isn't like it can't scan the code and check for instances of the DB and local instances in the FB at the same time.





head -> wall story.....



I was on a site last year where someone had previously created an array of bits to use as storage for edge detection inside an FB, but then were using the 2nd half of the bits in the instance outside the block. I'm not sure if they thought the instance DB was global and just named things badly, or if they didn't really know what an instance DB was, or what. Things were running fine that way for awhile, right up until the internal usage expanded enough to start impacting what was used externally.

The site had started adding all kinds of extra code as Black MAGIC, because it might have solved the problem once on accident, and so they just kept going with it without understanding. Guys were trying to tell me that the edge detection instructions were buggy. (NARRATOR: "They weren't.")

Got called back a week later because they were having similar issues with the TON instruction being unreliable, which ended up being solved similarly....

In Studio 5000, I have an digital input_handler ("DI_Handler") AOI that is used to debounce digital inputs. It also has functionality for swapping the polarity of the signal, etc. I can make a udt and have tags in the udt with the data type "DI_Handler". In fact, inside a udt, I can create tags of any AOI type that I create.

Can this not be done in TIA Portal? I've started to try to replicate this with FBs, but it seems like each DB instance I make of that FB has to reside in my tree exposed, or in a folder structure that I make. Ideally, those instances of DI_Handler FB DBs would be nested inside a udt and out of sight.

Because I can't seem to replicate this Studio 5000 strategy, I'm considering using a FC +move command for handling each input. Any thoughts from TIA Portal programmers?

Why not an FB inside an FB?

If your DI_Handler FB sits inside a InputMapping FB, your Instance for all DI_Handler FB's can be declared as part of the STAT variables of the InputMapping FB.

So you end up with one Instance DB which holds all the others inside.

This is called multi instance FB, look it up as my explanation is poorly worded.

Yep. That looks like a great option. Thanks for the help Cardosocea!

JesperMP said:

Generally, yes to what you wrote.
An FB in TIA is similar to an AOI in RSLogix. Difference is that in TIA you can download a modified block at runtime with no issues, as long as you dont change the declaration part.

Generally, data that is expected to be accessed outside the FB should be passed in and out. That includes data that is accessed by an HMI. Unless the data is very simple, always define it by userdefined Data Types.
Data that is being accessed by the FB only should be part of the STAT (static) declaration of the FB.
TEMP (temporary) is data that will be discarded when the FB execution is finished. The data will not be retained. If the data is to be retained it should be part of the STAT declaration.

This is what I do.
If I have an FB "StandardMotor", I call the instances "IDB01_StandardMotor", "IDB02_StandardMotor", "IDB03_StandardMotor" or something like that.
You dont actually access the IDB data outside the FB, so you do not have to think about it being structured or easy to remember.

The data that is passed in and out and via userdefined Data Types, and usually stored in shared DBs, should be well thought out so you have structures that are well organized. I am guessing it is exactly as you would do in RSLogix.

Click to expand...

Hi Jesper,

I'm also a Rockwell guy but tinker with Step7/ TIA from time to time.

Generally, data that is expected to be accessed outside the FB should be passed in and out. That includes data that is accessed by an HMI. Unless the data is very simple, always define it by userdefined Data Types.
Data that is being accessed by the FB only should be part of the STAT (static) declaration of the FB.

For my standard blocks such as valves,motors,analogs etc I usually make a UDT and pass the entire structure as an In/Out. The only exception is a few temp variables and timers (which I could never figure out how to make members of the UDT. The timers I declare in STAT.

Is there anything wrong with this? I had a Siemens guy explain it like you before many years ago and couldn't grasp it then. Would you mind a quick explanation please?

MorphuisOGrady said:

Hi Jesper,

I'm also a Rockwell guy but tinker with Step7/ TIA from time to time.

Generally, data that is expected to be accessed outside the FB should be passed in and out. That includes data that is accessed by an HMI. Unless the data is very simple, always define it by userdefined Data Types.
Data that is being accessed by the FB only should be part of the STAT (static) declaration of the FB.

For my standard blocks such as valves,motors,analogs etc I usually make a UDT and pass the entire structure as an In/Out. The only exception is a few temp variables and timers (which I could never figure out how to make members of the UDT. The timers I declare in STAT.

Is there anything wrong with this? I had a Siemens guy explain it like you before many years ago and couldn't grasp it then. Would you mind a quick explanation please?

Click to expand...

In a perfect "object oriented" world, you have a Motor block. You pass in any inputs needed, including setpoints/commands from the rest of the program, and feedback from the real world. You pass out any outputs needed, including status to the rest of the program and commands to the actual outputs of the drive. The instance of the FB contains all the information about the drive.



Every system differs from what I'll call the "ideal" by at least a little. The perfect model ends up with a fair bit of duplication of memory in simpler applications, and it doesn't work well when the the data needs to be accessed in many places.


The model works well when the "Object" is something that is controlled in one place. However, often times the "Object" is a part that is process in many places all over the code. For something like this, the In/Out plan is definitely the way to go. I often see systems where there is an In/Out for PARTS, which links back to a giant array of a UDT of all the info for each part, and then the FB just uses the bits that it needs.


Note: I put "object oriented" in quotes because it isn't REAL object oriented programming: no classes, methods, inheritance, etc. But we often try to pretend it is while we program, because it helps us keep things organized.

MorphuisOGrady said:

For my standard blocks such as valves,motors,analogs etc I usually make a UDT and pass the entire structure as an In/Out. The only exception is a few temp variables and timers (which I could never figure out how to make members of the UDT. The timers I declare in STAT.

Is there anything wrong with this? I had a Siemens guy explain it like you before many years ago and couldn't grasp it then. Would you mind a quick explanation please?

Click to expand...

You cannot add an FB to a UDT. So you cannot include for example IEC timers to a UDT since these are SFBs.

Think about it, why do you want to pass everything in and out of an FB ?
There are data that is naturally part of the "internal machinery" that makes the FB work, and there are "interface" data that needs to be accessed elsewhere, by other program blocks or by an HMI for example.
Place the "machinery" parts in the FB so that it becomes part of its IDB.
Place the "interface" parts in one or more shared DBs, and pass these data to and from the FB via in/ut pins. Defining these data via UDTs is the smart structured way. Only exception should be if the data is a very small number of elementary data types.

As for IEC timers, the natural thing is that the "internals" be part of the FB and its IDB. It is easy, just add the IEC timer to the Fbs declaration and you are done.
On the other hand, "external" data such as the setpoint and the actual value could be manipulated or displayed via a shared DB. So you declare in/out variables and assign these to the in/out of the IEC timer.

edit: Writing "reusable" code always have the problem of what happens when you change the declared data. If you change the declaration of an FB, you will have to update all the IDBs of the FB instances, which in turn means the IDBs have to be loaded, and that is a problem on a running system.
By combining the "internal" and "external" data into one shared DB, you increase the likelyhood that a you have to reinitialise all the instances. As far as I know, Rockwell AOIs arent really suited to online changes on a running system.
Split the internal data (IDB) and external data (shared DB), and be careful to setup the declaration of the DB so you dont have to change it later (reserve spare data for just in case, memory is cheap), and you can program online without having to reinitialise the IDBs.

Sorry for the beginner's question, but I was given a fixed structure and several FBs by a customer to use on their job a while back. The method is to have the "library" FB versions for a given operation (valve, motor, etc) used multiple times in a containing FB, with all the library FB instances' data in the single iDB for the containing FB. All Wincc and local HMI connections are via the static members of each library FB's entry in the containing FB's iDB.

As I do very little Siemens work and don't know any better, I've used this method as a template on my one or two TIA projects since, so when I read here about the shortcomings of this method, I wondered if I'm perpetuating a dodgy practice. Do the references (in replies here) to external access via iDBs relate to external equipment, networked PLCs, etc, as I couldn't see a way to access the FB's interface data without using the iDB, for use in the rest of the program.


JesperMP: How do you split the FB's DB allocation? I thought that an FB could only be referenced to one DB. Thanks.

I use DMCInfo's open Library and their approach to this is to have a UDT related to each FB (motor, Valve, etc...) and each of the FB's have an IO parameter of that specific UDT type.

You create these UDT's in a normal DB and link it to the function call. You can then control and get feedback from the UDT's and through some of the outputs on the blocks. Instance DB's should never be accessed from anywhere outside their FB.

The access to an IDB from outside code or from an HMI is considered bad practice by "purists".
I do it however myself on occasion.

Regarding the splitting of data, you only have one IDB for an FB, and that is possibly even a bigger IDB that contains the data from many FBs by multiple instance.
But the data that you pass in and out via IN/OUT pins, you can have as many pins and DBs as you want. You could for example have one DB for configuration data, and another DB for HMI data.

DairyBoy said:

As I do very little Siemens work and don't know any better, I've used this method as a template on my one or two TIA projects since, so when I read here about the shortcomings of this method, I wondered if I'm perpetuating a dodgy practice. Do the references (in replies here) to external access via iDBs relate to external equipment, networked PLCs, etc, as I couldn't see a way to access the FB's interface data without using the iDB, for use in the rest of the program.

Click to expand...

If you want to go half-way, declare them as input or output, but don't link them to global DB, just use them directly from the HMI. That way you don't have to double declare, but it is more obvious that it is expected and safe to be used outside the FB..